[Action RPG] Display Kernal Lite
I've been wracking my brain in hopes of having a new way to do Action RPG's display kernal to save space. Manually counting up the the byte requirements, the display kernal requires about 689 bytes. Could be a bit more. Could be a bit less. But 689 is a lot, especially when you consider it's a 5-stage display kernal. I wanted to find a way to reduce that, hopefully drastically. If I could get it to fit in 512 or less bytes I'd be happy. But that means I needed to find a way to drop some of the stages.
At first I considered using a modified SwitchDraw to determine when to turn the player on and off but I was a couple cycles short. That's when a google search ended up reminding me of Banked Draw from here.
Banked Draw is slightly faster but has it's own limitations and of course requires the large rom table. When you're trying to reduce rom used, adding a large rom table is counterproductive. So Banked Draw wasn't useful. However it did get me wondering how to use a similar technique to trigger the player's ENAM.
To make a long story short, while working on this twisted attempt to drop rom use to 2.5 stages, I realized I would have to reduce myself to using only 1 missile for the player.
So if I was going to do that, I decided I can probably cut out a couple stages in the existing routine without much change and achieve the same effect. So that's what I've done so far. I had to sacrifice one of the missile sprites for this but that's fine for now. I tried adding the second missile back in afterwards just to see what would happen (We'd have the striped player back instead of the box) but found it would occationally take up too many cycles and cause the screen to jitter as an extra line is added. Doing a few cycle counts, it looks like at least one branch is using EXACTLY 76 cycles. But at least one of it's branches in the line is crossing a page boundary in some conditions :!:
So, there's a small chance I might be able to add that missile back in before version 0.013 is finished. I just have to examine the code under a microscope and see if I can reposition the code so that no page boundaries cross. (I'm way too tired for that right now at 3:30am)
I'm too tired to do a manual count of the bytes used in the new routine as well. However by counting the first stage, knowing that all 3 stages are similar in size, it looks like the final routine is somewhere in the range of 450 bytes. If that's accurate then I've met my <512 byte goal!
Beta for 0.013 is below and a screenshot. Yeah, I know not much change from the last many versions. I'll see about adding some extra functionality to this thing before 0.013 is completed. (Hopefully by the weekend if I can stay focused!)
And for the love of binary will somebody take my commas away from me. I'm after going back up and removing over 17 unnecessary commas from this post while previewing.
2 Comments
Recommended Comments