Platform Masters Title
Platform Masters - Will you be the world's next platform master?

Ronnis - redoing the buildings 3

Date: Feb 1, 2012
Screenshot #271: Stage 4 of the process is merging the sets into one single layer. This is otherwise quick and easy to do... outside a possible positive/negative conflict with memory.

Ronnis - redoing the buildings 4

Date: Feb 1, 2012
Screenshot #272: Positive/negative conflict with memory? That's programming speak for when memory usage gets to 2 GB and goes negative, causing the program to crash, likely from accessing memory normally reserved for something else (such as 0 or VRAM instead of normal RAM). Attempting to merge the layers like shown in this screenshot....

Ronnis - redoing the buildings 5

Date: Feb 1, 2012
Screenshot #273: Don't you just love it when you get this familiar-looking error message? This was a very common problem I had while doing these buildings and it continued until I got to around the 90 for the scaling on the buildings. I have 4 GB of RAM (3.36 GB effective) and if you look at the bottom of the image where the "commit charge" is, you'll see that less than 2 1/4 GB of RAM is being used so I have plenty of RAM left so this isn't an "out of memory" case, far from it. This points to a bug with GIMP, one that I never knew existed before. If it's not the "send error report to Microsoft" message, it's GIMP's own "failed to allocate %d bytes" where %d is an integer that's typically a multiple of 16,384.

Ronnis - redoing the buildings 6

Date: Feb 1, 2012
Screenshot #274: With GIMP crashing like this so frequently, it's not uncommon to see several instances of "script-fu.exe". Once, I had over 10 instances. Here's a case of 4.

Ronnis frame rate test - final results

Date: Feb 1, 2012
Screenshot #275: After having finished all the buildings and updated my game engine accordingly, this is now what I get. The draw count is now so low that even a 2.0 GHz Pentium 4 can handle this and still get 60 fps. There is now otherwise little room for improvement. I even went to the 23 just to be safe. This was a lot more of an improvement than I thought! Now Ronnis will run just fine on almost any computer a decade old at 60 fps.

Ground decals: all. Buildings: all.
Draw count: 1821. Frame rate: about 163 fps.

Jeremy's House tests - control

Date: Feb 2, 2012
Screenshot #276: Like Ronnis, Jeremy's House is also rather high on the draw counts, though not as bad. The fix, however, is pretty much the same - update the ground decals for a greater repeat width and update the houses so that they are fused into a single image. The houses are no where near as bad as Ronnis was, but there's still some room for improvement, saving about 150 or so draws. The ground decals will save considerably more. Let's see how this will come out in later screenshots.

Draw count: 2470. Frame rate: about 120 fps.

Array overflow errors

Date: Feb 2, 2012
Screenshot #277: Array overflow will cause a lot of problems. Program instability, system instability, or worse yet. Thus, I spent 5 hours (could have been 5 minutes if it wasn't for an annoying design with C programming) readjusting my "LoadImageFile" function. Fortunately, I was well aware of some shortcuts to speed this process up nearly triple the speed it would've been. At least this way, I can find and isolate such severe problems. This is an example of such error. Future beta releases may have this. The final product should not but if one goes unnoticed, this will still occur.

In this case, from updating an image (done long ago too), I forgot to adjust or incorrectly calculated the size of the array. In other cases, BMP's padding is often to blame. Width*Height*3 is usually what you'd think for a 24-bit BMP file's file size, at least for the image data. That's not entirely true though. If the number of bytes in the image row is not a multiple of 4, extra bytes are added at the end to make it a multiple of 4. This is why your 3x64 BMP file isn't 576 bytes (or 630 with the 54-byte file header included, of which you'll see with a 64x3 image), but, rather, 768 (822 with the header included). I frequently overlook this aspect of BMP files. At least the fix takes a few seconds. Without malloc, this is something I'll have to deal with regularly.

Jeremy's House tests - decals redone

Date: Feb 3, 2012
Screenshot #278: After dealing with new bugs introduced from the addition of the array overflow check system, and fixing a bug I had I didn't know I had unrelated to it that affected Lake Keveran and Air Taxi, I got the ground decals updated so that they use a different repeat width. The scene looks otherwise exactly identical to screenshot 276 (there may be very slight differences due to scaling differently, but it's hard to tell). Yet, the draw count has dropped by a considerable 558, putting it within a good range.

Note that I added a frame rate indicator on the debug panel. Draws on the debug panel don't count. The frame rate indicator is dependent entirely on the draw count, not CPU or GPU usage. The draw count has the strongest influence on the frame rate.

Redoing the most distant of the houses should get the draw count to 1800 or even lower. The layer from about the 8 and beyond is likely to get redone which means, like the sky scrapers, new random colors will be present. Unlike the 100+ draws from redoing the most distant sky scrapers, the houses only use 16 at the high end. Given the 16,384 CU repeat width they use (that's 8 city blocks or 1/2 Kbl), this means I can save about 13 draws at the far end. That isn't much, but do this with all houses from even just the 20 and that's nearly 90 draws saved. Continue to the 8 and I could probably get about 160 to 200 total draws saved. It's not much, but against what this screenshot shows, it's more than 10%.

Draw count: 1912. Frame rate: about 155 fps.

Jeremy's House tests - final results

Date: Feb 5, 2012
Screenshot #279: With the houses now redone, 132 draws are saved from this position, surprisingly low for what I was thinking. Still, it's a considerable difference that does add up. The layers from 8 and beyond were redone. There is no point in the closer layers because they are already very wide to begin with. At least now Jeremy's House is 100% complete like Ronnis is.

Draw count: 1780. Frame rate: about 167 fps.

Nodera Ice Shelf - unique ground decal setup

Date: Feb 6, 2012
Screenshot #280: The ground decals in Nodera Ice Shelf are quite simple compared to many of the other worlds. However, Nodera Ice Shelf, due to the ice shelf itself, has a unique setup for its ground decals. The need for this arises from a potential problem I noticed. That problem arises from the vertical span needed. From high above, it's not a problem, but, see over the edge, from just above the top of the closest ice burg and you'll see right through. Thus, to get the effect I need, I need to have 2 separate and directly related ground layers. A scenery layer behind these completes the setup.

Normally, each section of ground decals is done separately. Because of this very close relationship, I decided it'd be better if I should just include 2 ground decal layers into a single image and get 2 different zoning layers as needed. As to the end result, look at the next page for future screenshots.