Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Telgin]

Yeah, see my account a few pages back of trying to get a simple Websocket server in C++ working.  Took an entire dang day.  If you're new to C++ programming then it's probably going to be a big hassle.  Coding on Windows makes that a double hassle since most of the free libraries are written on Linux and without a care in the world if it works on Windows.

The theory is that a library gives you a bunch of useful functions you can call without having to write them.  The practice is that you spend just as much time trying to get it to compile and / or link, then figuring out how to use it and lastly working around the fact that it only does 90% of what you needed and in a weird way.

I don't know how to do cursor placement and stuff with Windows' command shell, and knowing the Win32 API, it's probably a big pain in the butt.  The things you'll want to try Googling for would be disabling echoing (to remove user input showing up on the screen) and cursor placement to avoid redrawing entire screens and causing tearing or flickering.  I don't know how you get input without requiring enter, but I think maybe the C standard library getch function does that?  I don't think I've ever used it, to be honest.

Whenever I've coded anything interactive like that on Windows, I coded it as a Win32 subsystem program rather than a console program.  That means writing a Windows message pump, which makes getting input like you want somewhat straightforward.  On the other hand, a Windows message pump is a huge thing to learn if you're new to anything but console applications.  I also don't know if you can attach something like that to a console application, but maybe you can.  I know you can open console windows in such a program, but it's pretty amusing how complicated that is if memory serves.

[alway]

C++ libraries are frigging intense. I ended up going with Python when I wanted to try libtcod.

Oh ho ho, just wait until you try combinations of C++ APIs. OpenCL-D3D11 interop is such a pain that I'm considering starting a programmer blog in large part to document how to use this stuff in one centralized location. I've dug through AMD, NVidia, and Khronos documentation and code to get this stuff to work; and I haven't even started investigating the event system involved in OpenCL which I'm sure I'll need to do to get good performance out of it. On the plus side, today I finally got around to rendering a texture in DirectX11 written in an OpenCL kernel.

Yeah, see my account a few pages back of trying to get a simple Websocket server in C++ working.  Took an entire dang day.  If you're new to C++ programming then it's probably going to be a big hassle.  Coding on Windows makes that a double hassle since most of the free libraries are written on Linux and without a care in the world if it works on Windows.

The theory is that a library gives you a bunch of useful functions you can call without having to write them.  The practice is that you spend just as much time trying to get it to compile and / or link, then figuring out how to use it and lastly working around the fact that it only does 90% of what you needed and in a weird way.

I don't know how to do cursor placement and stuff with Windows' command shell, and knowing the Win32 API, it's probably a big pain in the butt.  The things you'll want to try Googling for would be disabling echoing (to remove user input showing up on the screen) and cursor placement to avoid redrawing entire screens and causing tearing or flickering.  I don't know how you get input without requiring enter, but I think maybe the C standard library getch function does that?  I don't think I've ever used it, to be honest.

Whenever I've coded anything interactive like that on Windows, I coded it as a Win32 subsystem program rather than a console program.  That means writing a Windows message pump, which makes getting input like you want somewhat straightforward.  On the other hand, a Windows message pump is a huge thing to learn if you're new to anything but console applications.  I also don't know if you can attach something like that to a console application, but maybe you can.  I know you can open console windows in such a program, but it's pretty amusing how complicated that is if memory serves.

With C++, you will start to see a day as a very short period of time.

As for Win32 and such, that's actually not too bad simply because there's pretty extensive documentation on its use on MSDN. As for getting raw input in Windows, the current non-deprecated stuff (so far as I know) is Raw Input: http://msdn.microsoft.com/en-us/library/windows/desktop/ms645536(v=vs.85).aspx
Raw Input should let you get raw input messages from basically any input device. It looks like the Using Raw Input section has sample code which should give you a quick start into that, even if you can't be bothered to fully understand it just now.

Which is why I actually generally like programming on windows and microsoft specific stuff: MSDN is pretty much some of the best programming reference material out there, with extensive copy-past'able code.

[Orange Wizard]

I tried porting my simple game loop engine to Pytho, but python's libtcod version doesn't give you access to SDL events. Honestly, libtcod's kinda sucks >___>

For most purposes, why would you need the SDL events? I can understand it may be useful from a technical perspective, but the vast majority of people just want the console_put_char() to do its thing.

[Skyrunner]

That's not events, that's the SDL surface. By events,  I mean the objects created and returned when eg you click or move the mouse or press a key. From a precursory glance, libtcod doesn't imitatethe Sdl event system, does it?

[LoSboccacc]

Anyone knows the restriction for commercial games in the free version of unity?

I only found this: must be a company with less than 100000$ posted revenues

Does the free version support mobiles?

[Parsely]

Welp, I finally got 'round to giving Python a shot. So far it's pretty similar to what I remember of visual basic, except it's case sensitive. Easy enough.

[Telgin]

Which is why I actually generally like programming on windows and microsoft specific stuff: MSDN is pretty much some of the best programming reference material out there, with extensive copy-past'able code.

Now that I can agree with.  I'm still impressed at this whenever I have to look anything up in the MSDN.  I remember back when I was first learning OpenGL programming, I was using Visual C++ 6 with offline documentation installed.  I was pretty surprised and pleased that it had thorough documentation, including code samples, of all of the OpenGL library functions.

[Kirbypowered]

Well...seems like there's a lot to learn! Good thing I don't have silly things like work or studies to distract me for the next couple months, eh? I'm sure I'll have figured something out by then. If I don't get too distracted.

I'll say that I have a tendency to try and understand things from their most basic levels first, and then work my way up, but it seems that, more often than not, the basic level is the most complex. I always end up losing steam (and never actually getting to the part where I code something) when attempting to learn programming stuff because of the millions of unfamiliar terms thrown at me in casual explanations of things I thought were pretty simple. I've taken to just having Google ready to search terms down to their core nowadays. It's mildly successful.

EDIT:
Just remembered the other thing that kills my attempts at programming, trying to figure out IDEs. How do I even IDE? I set up codelite and thought I was doing well, but when I tried to test it with a simple program, I had some cryptic build error involving a 'recipe' (I didn't know I was cooking). There's just too much that means nothing to me in all the options and buttons. ;-;

[MorleyDev]

C++ IDE's can be a bit tricker to set-up, since they have to be written to work with a gajilion different compilers. It should 'just work' if you download the version with a compiler (keyword: should), and if you download the one without it should want you to point it to the compilers. Any more specific information?

[Kirbypowered]

I went without mingw, since I already have it installed (it'd work the same thing, right?). The C++ compiler seems to be pointing to the right thing (C:\MinGW\bin\g++.exe) too.

It can actually compile the file, but fails to build it?

[MorleyDev]

I went without mingw, since I already have it installed (it'd work the same thing, right?). The C++ compiler seems to be pointing to the right thing (C:\MinGW\bin\g++.exe) too.

It can actually compile the file, but fails to build it?

Is it pointing at the correct make program? Because there's some distributions that come with "make" (which is the name of the program in GNU tools), whilst most come with "mingw32-make". This can confuse some tools that expected mingw32-make or vice-versa (mingw32-make is the correct one for mingw, I believe, but some seem to like the consistency of it being make regardless of Unix or Windows enough to ignore that).

[Kirbypowered]

The make program it is pointing at is mingw32-make.exe in mingw's binaries. There's an odd -j8 after it, but I've tested it with and without it, but I get the same error either way. Currently (carefully) fiddling around with some options.

In other news, I've found a little tutorial for making C++ roguelikes with libtcod. It has so far given me some basic ideas about how to use external libraries, which is nice.

EDIT:
Well, using the same command codelite did via the console, I got the same error. In case it's less cryptic to someone else, here it is:

Code: [Select]

C:\Program Files (x86)\CodeLite>C:/MinGW/bin/mingw32-make.exe -j8 -e -f Makefile

----------Building project:[ test - Debug ]----------
mingw32-make[1]: Entering directory 'c:/Program Files (x86)/CodeLite/test'
/usr/bin/sh: C:MinGWbing++.exe: command not found/usr/bin/sh: makedir: command n
ot found

test.mk:85: recipe for target 'Debug/.d' failed
mingw32-make[1]: *** [Debug/.d] Error 127
mingw32-make[1]: *** Waiting for unfinished jobs....
test.mk:96: recipe for target 'Debug/main.cpp.o.d' failed
mingw32-make[1]: *** [Debug/main.cpp.o.d] Error 127
mingw32-make[1]: Leaving directory 'c:/Program Files (x86)/CodeLite/test'
Makefile:4: recipe for target 'All' failed
mingw32-make.exe: *** [All] Error 2
      *extra lines given by codelite specifically*
Makefile:4: recipe for target 'All' failed
1 errors, 0 warnings
There seem to be a few points of error in there, as far as I can tell.

[Mego]

It looks like it's supposed to be setting a temporary variable (makedir) in the makefile, but screwing up.

I need to read better. As MorleyDev said below, yeah, looks like it's trying to use UNIX paths and utilities.

[MorleyDev]

Does codelite bundle a shell with itself? :S You're on windows but /usr/bin/sh is Linux. It could be generating cygwin-specific makefiles and getting confused.

[Kirbypowered]

I...don't know. I can't find the directory you mentioned anywhere though. Ohhh, I see what you're saying. It's trying to be UNIX.

Err, how might I go about fixing this? Is there a place I can go to redirect it to the right directories?