Infiltrator Part 10

This was a rather fun session for a number of reasons. It was also a rather slow session for a number of reasons, including that one stupid bug(more on that later), my school teacher breaking into my house at night with a baseball bat to see why I wasn't at class, the group of people who appear on my couch during all the holidays, and my webshow fans not liking to be utterly forgotten for a week.

Whatever the case, there's more progress for everyone. This session is about the opposite of number 8, where the changes made were mostly internal, instead making mainly visual changes.

I loaded up my favourite desktop wallpaper to play on top of just for laughs.

As you can see, there's a brand new shiny heads up display. This includes a functional weapon selector/indicator, and shield meter, and an energy indicator. There are separate energy pools for each weapon except for the AIFSA, because it doesn't need energy.

I must admit that you can't really spend energy or lose shields. The only way to change energy/shield levels at the moment is with the debug keys that let you turn them up and down at will. Eventually energy use will be programmed in as well as the ability to take damage, but for now there are higher priorities. Besides, the system is intact, which will make it theoretically smooth to add those features.

Also of note are some new art assets I've thrown together. I'm not doing tiled levels, but it stand to reason that SOME level assets are going to be square-ish.

Now let's delve in and explain that bug that slowed me down, which I've only barely overcome. This should be interesting, but a bit technical. If this looks like greek to you, feel free to skip ahead.


Engage first person non-omniscient present-tense writer mode!

I need to setup the HUD to display weapons. I'll just make five base-HUD images, one for each weapon. I'll load them into RAM, and just set a different image to be drawn depending on which weapon is selected. I draw up the images, setup my program to load them up, and change which image is to be drawn when the player changes weapons.

I compile the program to test it out. It's a little difficult, since the frame-rate is CUT INTO LESS THAN HALF! This can't be a memory usage problem. This can't be a CPU usage problem. This problem doesn't make any sense.

I'm not even drawing the image, or really doing anything but loading it into RAM. Let's do a little math to see of a 1024x768 image, with 4 channel RGBA color should be taking up a big amount of RAM. Let's start by assuming that the developers of SFML are at least mildly intelligent, and use only as much RAM as they could ever possibly need. That means each pixel should take up 8 bits for each channel, meaning values from 0 to 255 for each color channel(standard). With 4 channels, that's 32 bits. We can easily calculate how much RAM this should take up by multiplying this by the number of pixels within the image. The number of pixels total is the width times the height, so RAM = 32 * Width * Height. Width is 1024, height is 768, so it should be taking up 26,148,864 bits max. Let's divide that by 1024 to calculate kilobytes, and then do it again to calculate megabytes. We end up with 24.937 MB.

This makes zero sense. If SFML isn't optimized at all, then each image should be taking up less than 25 MB of ram. It should be taking up a lot less if it is optimized. Then we note that I have 8 GB ripe for the picking, and see that there is no way these images should be bogging the system down by using a lot of system or video RAM. That means the RAM usage isn't the problem unless SFML is broken.

CPU usage isn't the problem, since I've narrowed the code down. I don't even call the variable more than once to load the image. Loading the image should't be causing a RAM or CPU usage problem. Yet, when I monitor the application, the CPU usage is at 100 percent. I double check vsync to make sure it's working.

Now I'm lost. As a last resort, I try moving the image variable into the level class(where it doesn't go.) TaDaa! Everything works! Now I'm twice as lost. But the bug is fixed(for now) I guess, so...yea.

Disable first person non omniscient present tense writer mode!

        --LazerBlade