After having a background load, the game jumps into its main loop, which contains player and enemy states. You run 1 state each and cycle on till one dies. The thing is, that either player or enemy will always be at a single state, so having the fast states is important. A state is a player/enemy action/condition, say 1 is standing, 2 is walking, 3 is low kick, 4 is being hit, etc. I intend a complete character, like the hero, to have about 8 states, it is also safe to say the minimum amount of state a character may have is 4, where 6 is an average. So, another important point is the size of a state, the smaller the better. If a state costs 500 bytes, a full 8 states character will cost 4K.
By now you have probably noticed I´m re writing the code, specifically the code inside states.
So, after having the background in at 569 bytes, time to look at standing and walking states for the player and enemy.
And this is very tricky. I can tell you that these 2 states are the most important ones.
The stand state, while light in animation, has a lot of control requests, it gets heavy.
The walking stand is animation heavy as it has to delete pixels, but most importantly, those two states are the ones the characters will be at 75% of the game time, they are fundamental. The performance I get when 2 players are walking at the same time is the mark 0 to balance all the other states and it will dictate the game speed.
I adapted Allen Huffman timer routine inside the game loop, tried for the most simple stand and walk states I could think of ,and here is what I have:
keep in mind the game runs considerably faster when the timer routine is off.
Notice both standing peak at 9 and both walking right peak at 15.
The game performance will be great if I can keep that number at 20 and below. 10-15 would be ACE!
The stand state is up to grow as I add more control calls for other moves so it might go over 10. Gotta keep an eye on it as there isen´t much I can do to fasten up but to mess with the control scheme, which directly messes with the gameplay. I could only draw the character once to get some speed back in case this goes too high.
The walk state is noticeably faster when both are walking left. Their order of check in game must be fixed in a way walking forward is faster. Even after this fix, it will peak at 14, which is noticeable against 9 of the stand...this will make the player speed change too much whether the other character is still or walking
I also added routines to limit movements, when bumping each other or moving off screen, the later being dynamic as per scene.
These two states are also very flat and done very minimally. I got 250 bytes per state, which could picture a 2k 8 states full single character. It would be perfect!
Before advancing, I need to super fine tune these states. I have ideas for getting it faster and shorter but also have to think hard about the visuals. Being the most seen graphics during the game, it counts if they are rich.
Annnnd before getting back to shape those states, I got feedback from the background code from the last post.
Chaps from discord shared a few hint lists that were great to read and even helps other part not directly related.
George Phillips there also said
It's not much, but CHR$(26) is 2 bytes shorter than CHR$(&H1A)Yep it is, there will be a bunch of calls like that and the combined bytes will eventually amount to some space, say, from some 10 images. Every byte matters, it can only be sacrificed if for performance.
Erik Gavriluk had this to say:
That call will bring back about 4.5k of memory to use in basic.
If running Disk Extended Color Basic, that 27k figure is probably the highest memory space I will be able to use in BASIC while keeping compatibility with all systems.
Simon Jonassen proposed using ASM to deal those background images. If I understood correctly, he transformed the coded image in compressed data, then, a decompressor deals the image back on request from BASIC. Whatever dark magic there goes, he got it to a 202b size. That is around a third of the size I got!
I think from the vertical slice it will be clear to scope the project and think how/where ASM injections could bring great benefits.