User Tools

Posts I've Made

Using WM_CHAR will save you a lot of trouble. If you are going to interpret the keystrokes as text (player is entering their name), you should use WM_CHAR. For player actions, use WM_KEYDOWN/UP. Pressing, holding and releasing a key will generate many events. If you press and hold shift-A you will get this:

The problem with polling is you can miss something. If the user presses and releases a key before you get around to polling again, you will completely miss it. Mouse clicks are fast, and if your frame rate stalls for whatever reason (not even your program's fault; maybe the dreaded McAfee just started to do an update in the background...) and you're out of luck.

I get that you want to just poll to check if a key is pressed in your code. I like to do that too. But it's easy to do with events: (Rough pseudocode; haven't done win32 events in a while:

Then, in your code you can do if(keystate[KEY_L_CTRL]) all you want. Or sprite.draw(mousex, mousey).

The above could still suffer from missing presses. If the system slows down, and you call the event loop once per frame, if a keydown AND a keyup press bunch up against each other, then in one frame's processing of events you would set, and unset a single key in the same call to the loop. One way to do that is handle the player's inputs in the event handler itself:

This way the event loop is looking for particular events, and sets those flags in the player object. Each frame, after the event handler is run, when the player's control code is run, it checks it's action flags and does the appropriate action. This way you can't miss a jump or fire event, even if the next event is the queue is releasing the button.

Now, you can't miss an event. If the key was pressed at all since the last frame, keypressed will be '1'. And if its still pressed keystate will be '1'. So now anywhere in your game loop you can do this:

Descent 4 w/ Oculus Rift support. Will probably never happen. It should be bundled with a coupon for free Dramamine.

I would like to see a puzzle game like Portal, but where there's time travel between the portals. The engine sees the trajectory the ball is going to take, and lets it fly out of the 2nd portal a couple seconds before it enters the first one. Self-consistent paradoxes would be the solutions to some of the puzzles. You press a button, and you launch a ball. The ball isn't going to make it to the portal, but right before it would miss, the counterpart ball (from the future) flys out of the 2nd portal and hits the ball into the 1st one, and gives the remaining ball just enough of a nudge that it can reach the button that triggers the exit. If the player tries a non-consistent paradox (like the ball from the future prevents the ball from going in the portal), then there's some severe penalty, like the universe implodes or something.

Your language is very similar to C. I would suggest you write a simple preprocessor that reads your langauge, applies a few tweaks to it, and outputs C. Yes, generating C form a non-C language can be ugly, but generating C from almost-C could just be a matter of some basic text manipulation. Even if you intend to write a full-features compiler, this exercise will be useful because it will allow you to write (and run) functioning programs in your model language, and quickly make changes to it as you discover new features you want to add, or discover that certain features just don't work they way you thought they would. Then when your language design is finished, you can then write a full compiler for it, generate llvm code, or whatever. That's exactly how C++ was made: It started as a C++ to C converter.