Putting some pieces together

Well, it’s been a long while since I’ve posted. I went to GDC in San Francisco and had a blast! It was great to meet up with old friends, meet some new friends and learn a lot. I didn’t get the chance to go to that many talks – but when I did I enjoyed noticing how much more I understood than last year. Progress!

Anyway, immediately after GDC I came down with the flu and productivity of any kind at all was out of the question. But now, finally, I’m feeling more like myself again and I can get back to learning (and working).

Before going to GDC I thought I’d try to start putting things together to make sure they worked (though I’ve had no time to write about my changes until now). So I started working the PlayerObject and BulletObject into my GameScreen and removing my old implementations. Amazingly, I didn’t actually have to change very much in my code at all.

The biggest hurdle was spending way too long wondering why I couldn’t see the player drawn to screen. After an hour or so I worked out that the problem was all the way back up in main.cpp. My draw code is now being run from the Update functions of the GameObjects, and these are being called from the Update function in main. In main I was calling glClear, then the (soon to be deleted) draw function, and then calling glSwapBuffers before calling the Update function. Basically that meant I was drawing to the screen, then clearing the screen before posting the screen to the front buffer. Oops.

The only other issue was that my guess for the initial force used to shoot the bullets was way too low. After upping that to 30000 I decided that this was a “magic” number and this should really be passed in as a variable so I can have bullets of different speeds if I want.

As always, you can find my code on github – and the component code is still in a separate branch from master.

On an unrelated note, I’ve been reading a book called “Write Great Code” by Randall Hyde. So far I’ve learned a bit more about how integers and fixed-point variables are stored and manipulated – and how the C/C++ compiler might translate some of my code into assembly. I’m getting better at being able to understand assembly snippets – or at least to use them to better comprehend what is going on behind some higher level code and how that affects memory management and CPU usage.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s