Background Information

Well, 2020 manages to continue to be, well, 57 months long. There are additional shenanigans afoot, but since this time said shenanigans will not have any real effect on what we are doing here, I don’t feel it’s terribly necessary to go on, at length, about them like I may have once upon a time. So let’s push on ahead.

Right, so I have reinstalled the turret type enemies into Paper Zeppelin again. They have an interesting behavior where they will track the player that is nearest to them and rotate to aim at you. It has a rather spooky effect, flying through the air and having a cannon follow your movements. It’s slightly weird just because that behavior is derived from math and not any particular steps that I coded out. I’m a big fan. With those little brutes all set up I made a quick adjustment. Basically they would calculate out their orientation based on the closest player. That worked provided the player was passing through the turret’s AI “range.” But if you popped in the the range from outside, the turret would snap over and that, in the colloquial term we use around these parts – looked like ass.

So I coded up a modification that uses the player’s position as the “optimal” target and then rotate around until the turret gets there, and I tied shooting to correct orientation. Now if you pop in on the other side of the turret, it takes a bit to look at you and then it proceeds to shoot the ever living hell out of you. I like it. The extra tweak means that in single player you can outmaneuver the little brutes to line up safer shots, and in multiplayer it will give teams the option to draw attention to one player and have the other finish the turret off. What started off as a nice adjustment to make something pretty has actually managed to change the gameplay for the better. Wall to wall wins really.

Other than that, for reasons that I couldn’t quite grok at the time, Paper Zeppelin would still continue to occasionally grind to a halt. The frame rate issues reared their stuttery assed head again. It was, well, not great. But it does bring me to the titles. I began by adding a bunch of debugging protocols and the ability to pause the game at any time and look at the current state of the memory and data. I say that, but that just means that my console window just says:

  • Player List: 1
  • Enemy List: 5
  • Sprite List: 87
  • Ground List: 874

…and that’s more or less what it said when my actual frame rate (not the one that the system claimed. Liar) dropped out to 1 frame per whenever. Which got me thinking. At this point the main loops were written to ignore certain kinds of objects. So that Ground List number also included all of the fill ground, even though the system doesn’t do any collision checks on it. But I think that pulling it to look was causing an issue at all, because I did tell the system to see what kind of ground everything is and skip stuff based on exceptions. Still though, it was doing 870+ checks per frame, which is, like, a lot.

This got me to thinking about another issue I was having. Namely that having large static backgrounds is crap. First off, putting a massive picture in the back didn’t work out all too great, getting proper alignment was awful, and when I tried it before and it ran really slowly. Now it’s possible that has more to do with how the loops were running at the time, but I still think it’s the wrong way to go. Instead I feel like the correct avenue to pursue would be to go with parallax backgrounds as much as possible. I can, after all, run them like sprites and do different kinds of “animation” using math.

The problem of course is that there is only a single level data file, and dumping a bunch of clouds and trees and whatever really clogs up the pipes. As is if there are background tiles the system does a bunch of checks on spawn to see if there should be a background tile summoned beneath an enemy. Otherwise it leaves a hole. It is honestly a hack, and I know we can (easily) do better.

This got me to thinking about a non-interactive layer(s) and the data sheet that would go with it. If I make it the same size as the main data file I would be able to line up everything that I want. As a bonus, I could establish a “horizon” to generate the parallax effect. Let’s say that the horizon is at 300 pixels (dead center of the non-upsampled play area). Things that are closest to 300 would have a slower speed than things further away from it. True background objects (things that aren’t supposed to be on the same “plane” as the ground and players) would ignore this effect. But that would make all of the clouds, waves, hills and whatever else look really sharp.

Which gets me back to the slowdown. With a separate list that never has checks run and just does the update and draw loops I have a lot of flexibility in exactly what I want the collision engine to deal with. So now there is a BGList, and fill ground gets dumped into it and never interacts with anything. When I pause the GroundList shows me a maximum number of 100, and the engine purrs.

Next up is to get the rest of the enemy types and sprites cracking along before I start building the shells parts of the game and getting the backgrounds to float on, happy as a cloud.

Leave a Reply

Your email address will not be published. Required fields are marked *