Erik_
Scope creep is real... even when trying to avoid it.
Wed Oct 26, 2022 5:20pm

I think I'm on track though if I keep working like I have been in the evening.

I've some how managed to already get dangerously close to QB45's memory limits to the point that it started throwing weird error messages. I had one where it said I was trying to pass an invalid parameter type (I wasn't) and another where the error message was just the last variable name it read.

I was able to move things around a bit and fix that issue but I added a free memory text while the game is running so I can see it slowly creep down as I add features. I'm currently hovering just about 1kb free... The good news is that QB71 has much higher memory limits so, if worse comes to worst, I can just switch over to that instead. I noticed some slow down when running the game in QB itself, but as a compiled EXE, it seems to work fine (or in DOSBox, just pumping up the cycles with ctrl+F12)

The to-do list remaining is:
* Add enemies and their visual assets
* Enemy interaction with player weapon projectile and player
* Level end tile & post level screen
* Title screen and all that boring stuff.
* More sprites to help keep the game somewhat interesting to look at.

It sounds like a lot but besides the enemies and actually mapping out the levels, it's not really that bad.



Edit: 10/27
I noticed some slow down when running the game in QB itself, but as a compiled EXE, it seems to work fine (or in DOSBox, just pumping up the cycles with ctrl+F12)
I was able to fix this slowdown by rewriting my code that writes the "changed" screen data. Once I added enemies, it became unplayable even in compiled form. After rewriting it, I'm able to bring the DOSBox cycles down to 600 and it still moves at a "playable" speed so it should currently run on anything that has VGA graphics. I think even an IBM XT would run it.

To fix it, I sort of did a dirty hack. I created a 2d integer array that houses each pixel's current color of the level map. A it's full 1:1 to the display data. When something moves or changes, I just grab the background color data from my cached pixel array and paint it back to the screen where the sprite has a transparency color. No math or calculations needed. Just "grab pixel at x,y and draw it". It's basically just an in memory screen buffer. Other SCREEN modes in QB have displays you can flip between which sort of does something similar, but SCREEN 13 doesn't.

The only downside is that the transitions between screens are a bit slower as it populates that 320x160 array but the game is at least playable again. :)


  • Capcom did that with Zelda - Puckdropper, Fri Oct 21 2022 11:35pm
    They built an engine and released two separate (Oracle of Seasons, Oracle of Time) games. They purposely interrelated them, but it could have been different games and they were both fun. I guess with 10 days left, you should go simple and get things done. Other wise, your game might turn out to... more
    • Scope creep is real... even when trying to avoid it.- Erik_, Wed Oct 26 2022 5:20pm
      • That's very cool. The Excel team used to have a saying - Puckdropper, Sun Nov 27 2022 1:31am
        "Don't save anything you can recalculate." Raymond Chen said they used this philosophy for big performance gains, but here it looks like in this case the calculation is expensive and saving it is much less so. The to-do list remaining is: * Add enemies and their visual assets Class: Make it work... more
"Forces act when not restrained" - Puckdropper