So here’s a fun fact – enemies are back online again. Well, at the very least the dive bombing enemies that try to crash into you are back online. But more specifically, the game state interactions of enemies are back online again. So they crash into you, and deal damage, and you can shoot them down, and they turn into little balls of fire that fall out of the sky and can damage you and…you know what? It looks an awful lot like the design doc says it should. It’s nice. Somewhere along the way while I was doing a test I realized that the dive bombers were the first enemy that I originally got installed, and now they are the first ones in the Monogame port. Then I began to think about how many of these little brutes I’ve shot down over the years, and how many of them had crashed into a player zeppelin. Sometimes the titles just write themselves.
What it brought to the forefront though, was that it can be difficult to do a thing when you have other things that are trying to end you. For whatever reason, the Bomb icon and pickup really isn’t working. If you touch it, you just crash into it and destroy it. I think that somewhere in the code it’s being treated as Destructible Ground. Or at least, that’s my current theory. But going to pick up the icon to test that it’s working is a little bit difficult because those newly online dive bomber enemies. Grr.
Previously I talked about the system being, well, slow. I found some interesting tools inside of Visual Studio that allows me to see a downright sexy report (reports are sexy – I Will Accept NO Counterargument) that shows me what functions are eating the most processor time, and much to my amazement – it’s not the collision detection function or the list comparison functions. C#, it seems, doesn’t care if I compare the lists of multiple sprites a 1000 times per cycle. Can I optimize it? Yes, yes I can. In fact at some point I will, but in the interim, that wasn’t really why Paper Zeppelin was running so slowly.
The truly confounding thing is that Paper Zeppelin ran great on my previous hardware, which was not nearly as powerful as my current setup. So I went digging into the options for my compiler and it turned out that it was creating a build for X86, which my computer is 64 bit. Now I am not an expert by any means on the differences in CPU and memory configurations, but after telling the system to compile for bit systems, it went back to being silky smooth.
For the most part anyway. I’m still getting occasional slowdown. I have a theory though. I am not sure at this juncture if when I create an instance of a class with an image, if the system creates a copy of that image, or if it has a pointer for that image and just references it when it’s time to draw. If it’s the former, that would create a reasonable memory hit if I have a 1000 things on the screen at once (since there would be 1000 images floating in memory). If it’s the latter, well that would mean that I need to figure something else out. Let us find out together.