Tusi / unhuman, thanks for the time invested. I have started a few projects (games) in the past and always either lost interest or got side tracked with life. I am keen to get this one done and have already invested a lot into it, so again – Thanks for the input.
5110 IF M<>1 THEN 5120 :: MN=1 :: MX=5 :: D=13 :: CX=46 :: GOTO 5200
Tursi, yes the alternative ELSE format is to remain compatible with the XB compiler which only likes THEN statements which GOTO line numbers. I found it a bit awkward at the beginning but now I am actually starting to prefer this way of ‘elsing’. J
I agree the interaction between M & T is strange, if not a somewhat cumbersome. My plan was to have additional enemies which would enter the game from the right side of the screen. The processing of these would simply continue on within the same FOR/NEXT loop (not yet written). As I wanted to process each complete caterpillar a chunk at a time this seemed like a good way to achieve both. As things progress further I will re-consider if anything is gained by changing this. I can think of several ways to improve this. Not sure if speed will be impacted, but I agree it could be a lot prettier.
5560 …….. C=EAV(MN)
.That is a leftover from some previous fooling around – good catch!
Yes, the -192 is simply to offset the first 6 rows of the screen which are not part of the grid, and save the memory that G(1-192) would otherwise reserve and never use.
The G & E pairing is supposed to work like this;
-Players bullet encounters a G() value that indicates that something has been hit. I could have used GCHAR to identify a screen character, but would then have to search all enemies and check coordinates to see which enemy has actually been hit. With this approach I can identify instantly which E(enemy) needs to be destroyed/processed.
-Now I know why E having a value <>0 is important, but I can’t for the life of me remember why I decided that it should otherwise hold the grid position. It now seems unnecessary. Having taken some time out I have lost the thought process….. Agree that I can give the added effort to define this value the flick. Woohoo – That’s a saving! J
In regards to some of your other points Tursi, when things started to slow down I removed some code for testing which I always intended to add back in. I had come up with some ideas which might explain some of the strange ways of defining the head direction and the way the variables are treated and displayed.
Currently my character map looks like the photo in the attachment.
I have defined a series of arrays represented by AS(#, counter 1-12). When a caterpillar/enemy is defined it is given a # value. Basically the counter pulls out values such as “0,0,0,0,0,0,0,0,0,0,0,0,” or “8,8,8,8,8,8,8,8,8,8,8,8” or “0,8,16,0,8,16,0,8,16,0,8,16” as the counter moves from 1 to 12. The value retrieved is the amount that the displayed ASCII code will be offset
This approach allows me to individually animate each different “Enemy” and each different segment. Ie, each enemy can have its own colour, can flash all colours, can flash some colours, can be a head facing in any direction, or a body part that might or might not change colour… and yet I only ever have to deal with two characters. 178 is always a head, and 182 is always a body - regardless what it is displayed on the screen.
The same counter was to be used for all non-sprite graphics. For example;. When an enemy was destroyed, EC(##) would change to a value of 160, and then using the same counter I could increase the displayed char value each cycle by increasing the counter. This would have the effect of changing the displayed value from 160, 168 , 176…. Etc moving it through character definitions and character sets.
My plan was to use these counters for displaying/animating everything and my character set was designed to use the values returned with as the counter incremented. By determining the value of AS(#,..) when each enemy was first created, I could determine exactly how every character behaved. I felt it worked extremely well and the time it took to control the counter would be offset when other special things had to happen. When I removed the counters the caterpillar march speed increased by around 10%. I was a little disappointed to find it took this much resources to maintain. I still want to go with this concept but I think I am forced to rethink just how liberally I use this function.
Line 5730 is a leftover. It currently should never be reached and will be deleted.
The whole 5850 / 5890 thing is to fall into line with my Character Set. <16 is always going to be a boundary character. If over >15 it will be something else that requires more processing. It must be confusing trying to make sense of stuff like this when I submitted unfinished code.
Thanks Tursi. Great stuff and good suggestions which I will take fully onboard!
Appreciate the input. I agree that some of the areas you highlighted could be improved. As per earlier comments, I was very pleased with the speed until it came to redrawing/calculating the caterpillar position- This seemed to be the source of the significant slowdown as this is when things took a huge speed hit. However, by milking even minute amounts it will certainly help. I especially like avoiding the math as you put it and didn’t realise there was potential for saving in this regard. This being the case there is possibly several other areas that I could do similar. I need to test it with the compiler and see just how the performance is affected. Thank you!
Again – Thanks guys! JTusi / unhuman, thanks for the time invested.
Edited by Bones-69, Mon Jan 1, 2018 9:51 PM.