O’erworld, Part II
What I’ve accomplished since the last update:
-
This isn’t totally related to the o’erworld, but as I was fooling round with my program I noticed the game would crash. I love how on the very day I bashed the hell out o’ the most beloved video game on the internet I learn that my own magnum opus is a buggy pile o’ shit — & e’en the cool bugs, like letting you reach the Spirit Temple @ the beginning while still a kid. During my long, in-depth look @ my code I found a bunch o’ memory leaks — some deep into the graphics & game engines & the sprite code. Since I would check my program in valgrind now & then, I don’t see how these managed to stay so long — how I could go so long without realizing that SDL_GetBasePath needs to be freed.
However, I found that what caused the game to crash wasn’t related to that @ all, but the o’erworld ( which ’splains why the crashes hadn’t happened till now ). ’Twas caused by the same problem that constantly strikes me: I forgot to initialize a member o’ a class. To be specific, I forgot to initialize the gfx_ pointer in the OWTile class for tiles that aren’t the animated water tile ( & thus don’t have any animated graphics ). I’m used to unique_ptr, which automatically initializes to nullptr; but these use a raw pointer ’cause the water tiles are s’posed to passively share a unique_ptr owned by OverworldState. Thus, half the time the check for nullptr would fail, e’en though the tile has no real animated graphics, leading to wacky undefined behavior. This ’splains why sometimes the map would become corrupted in random ways, such as when Spiral Island spontaneously flooded once.
&, no, don’t tell me to use shared_ptr for, well, shared pointers, as that’s pointlessly wasteful o’ precious memory & not needed if you just have a designated owner. I need to save my wasted memory on better things, like dynamically loading everything & keeping STD strings everywhere. The true lesson is to check valgrind more oft. Thankfully, I have just now & am assured that there are no memory leaks, nor have I found any random crashes. These are the problems most dire, as they can literally make a game unplayable.
-
Anyway, after all that, I finally got the o’erworld & level-select screens integrated. Now the level-select is accessed through a menu screen in the o’erworld that’s suspiciously similar to the in-level pause screen, as if I just lazily copied & pasted. & now, ’stead o’ giving you a list o’ all the levels, the level-select only shows levels you’ve been to, & selecting a level takes you to that spot on the o’erworld. My inspiration for keeping the level-select as an extra menu & having it warp you to the o’erworld spot was from the GBA remake o’ Super Mario World, wherein this mechanic was immensely convenient.
-
Saving & loading are now compatible with them. All the loading code was cleared out o’ the level-select state, where it wasn’t needed, & ’stead the OverworldState was given it. In addition, I added data for which levels you’ve been to & the most recent level you’ve been to, so that when you reload the game your level-select isn’t glitched out ( “?????” for already-beaten levels, for example ) & so the game places you on the level tile for the last level you’ve been to ’pon loading the game.
The Future
Someday I’ll get round to programming in that shop.
Also, I’m working on a snow level with plenty o’ slopes that’ll hopefully go well. The slope physics are still awkward, though. 1 thing I’ve realized is how odd the speed-capping works: it’s a simple speed cap wherein if you go faster than the cap, your speed is set to the cap with no gradual slow-down ’tween the speeds, & your top speed is based on whether you’re running ( holding the run button ). So if you jump forward while running & then let go o’ the run button, you’ll suddenly go much slower ’cause the halved cap brings your speed suddenly down. This in itself isn’t too bad: after all, you can turn round & move back while in the air, & that’s completely unrealistic. What made Super Mario Bros. so revolutionary was the way it threw ’way all the rules o’ real-world physics to maximize fun. But this also applies to slopes: you’re sliding or falling down a slide, how fast you go relies on whether you’re pressing the run button or not, which, I dunno, feels awkward. That’s a case wherein I think the break from reality went too far.
Also, though I haven’t felt anything jarring ’bout it, I’ve noticed that the ice physics should make everything mo’ wonky than expected. See, all ice physics do is decrease traction so that you slow mo’ slowly when stopping. But this applies to all movement, including upward & downward movement & flying enemies, like the bees that move up & down ( but not the circling bees: their movement is some custom algorithm that completely ignores the typical sprite speed & acceleration variables ).
Download sloppy source code, ¡now with 100% fewer spontaneous segmentation faults!
