For once the layout & programming took mo’ time than the graphics — probably ’cause much o’ the graphics are reused from other “pirate” themed level. & for once this is actually pirate themed & not a beach or bathtub.
It’s hard for me to get difficulty right ( or I fail to get it right ), since I’m bad @ games, so I can’t tell if I made a level too ridiculous or if I just suck. ¿Does dodging some o’ these anchor bullets require luck or just sharp eyes & reflexes? I considered lengthening the minimum shoot delay, since it seems like the most seemingly unfair hits were when it shot just after shooting, but decided not to, since I figured I was just reacting too slowly.
Anyway, the gem & time scores are lenient & I’m quite sure all o’ the trouble I had gathering the footage for this day’s video was due to sloppy playing. The time video here particularly shows that off, as after near flawless playing through the 1st half I flop round as if my fingers were covered in butter & hesitate as if I developed Alzheimer’s & still make the time score — though right on the last second.
The ladder shafts & the final stair climb are so saturated with anchor bullet sprites that it caused slowdown, so I had to fiddle together some optimization tricks. The 1st 1 I did had nothing to do with sprites, but eased the level’s run load so much that it made up for it: many o’ the tiles are background tiles, & I noticed that none o’ those tiles animated or changed. I’ve realized for a while that drawing all these li’l blocks is probably 1 o’ the most inefficient things this game does, since it calls the SDL_RenderCopyEx function for each block, which valgrind has consistently told me is slow. ( This is what led me to realize many updates ago that loading a small image & tiling it for a background is slower than manually tiling it into a large image & just loading & drawing that large image once per frame ). So I created a branch o’ the background tile code & created ’nother version that @ the beginning creates a texture o’ all the level’s background tiles & just draws the portion o’ that that’s on the screen every frame, turning what could be o’er 200 SDL_RenderCopyEx calls per frame into just 1 per frame.
That seemed to get rid o’ the slowdown. But I still wasn’t sure or satisfied, so I made 1 other quick & easy optimization that was actually relevant to sprites & I should’ve fixed a while ago. When a sprite is killed off, it’s simply erased from the vector o’ sprites. I’ve read on the internet that vector’s erase method shifts all entries after the deleted entry backward to fill the space & still maintain the order o’ entries. Unfortunately, I don’t care ’bout sprite order — it’s arbitrary, anyway, based on whatever order the map reader finds them, which isn’t tied to the order the player is likely to find them. Moreo’er, this is slow — I believe worst-case O(n). So I changed it so that it now just replaces the data o’ the sprite to be deleted with the final sprite’s data & then just pop off the final sprite.
I must confess I didn’t come up with this idea myself, but learned it from this chapter on “Object Pools” o’ the book Game Programming Patterns. In fact, I’ve known ’bout it for years & used it in earlier programs I’ve made, which is why I said I should’ve used it earlier.
As an extra maybe-optimization that didn’t hurt is I set the sprites vector to reserve 50 spots @ the beginning to hopefully avoid going past the size o’ the vector & having to slowly reallocate memory, move the data, & delete the ol’ data. When considering this optimization, I considered changing the vector to a classic C array, since I wasn’t sure if vector e’en allowed you to delete any entry without automatically shifting other entries; but realized it didn’t matter, since the sprites are held as unique pointers, so I could just release the last entry’s data & reset the unique pointer o’ the sprite to be deleted to that data. I decided to stay with vector for the greater size flexibility it gives. I prefer the balance o’ safety & speed I can get by having a vector with a moderate # o’ space reserved so that having to enlarge the vector is unlikely, but still gives me the chance to enlarge the vector if absolutely needed, for some rare outcome that I can’t predict.
’Course, the fact that sprites are held as pointers & not data itself means that this vector can’t take advantage o’ data locality, — which I also, coincidentally, 1st learned ’bout from a chapter o’ Game Programming Patterns — which is also a rather big inefficiency. However, fixing that would take a lot mo’ work — I would basically have to refactor all sprite code so that it uses discriminating unions — which are both racist & socialist, so neither side o’ the political spectrum likes them — ’stead o’ polymorphic sprites. In hindsight, I would’ve preferred using discriminating unions for this & a few other reasons, but it’s too late; so we’re stuck with slow & stupid polymorphic classes. I could think o’ many other optimizations I could make, some big & some so small it’d be a waste o’ time — & some big, but would require me to reprogram large parts o’ the game’s integral code. This isn’t so much “fix all inefficiencies I can think o’”, which would make this project take decades to finish, but “fix inefficiencies that are obvious & ridiculously easy to do”. I’ll save these bigger ideas for the sequel, where I can start from scratch. Now I want to just get this sloppy mess finished & out o’ my sight.
Anyway, these optimizations not only seemed to clear all slowdown in “Good Ship Lifestyle”, they also seemed to fix the slowdown that has been in “Value Valhalla” for probably o’er a year. ( Didn’t fix most o’ the sprites disappearing after a loop, though ). Why this happens, I can’t understand, since this level has neither any background tile layers nor sprites that are deleted.
& I must say, this level’s music is a true banger. This time it isn’t by Kevin McLeod, but by a band called Blue Wave Theory, found on Free Music Archive, released under Creative Commons ( & thus OK for me to use ). It’s surprising how much high quality music you can find for free — which is great for people like me with absolutely no musical talent.
Final Fun Game: Try & find the minor graphical ( technically, level-design ) flaw I made & didn’t notice till after I already recorded the video this time.
Here Is Where the Bad Polymorphic Classes Can Be Found
