thks !
next step is to define sprites with a bar for hit points and make them die when count =0 , not big deal
and after that define the rounds , just a little more time
finally improve gfx , boring to me
and ultimately add sfx
long way then !
What is the greatest bottleneck in speed on MSX2, the calculations or the actual sprite manipulation? I recall that putsprite is really slow compared to direct VDP commands and vpokes but that problem might as well be optimized already in this example.
regular put sprite is used.
this is turbo basic or xbasic / basic kun
i think calculation are slow , sometimes i use operator like "*2" which could be optimized in asm .
i alsonoticed that at the begining i was using single/doubles forvariablesand using integers speeded
up the execution.
the main loop has two "for" loop with "if then else" , like this:
for monster=1 to 9
for tower =1 to 5
- three if statement
- tower to monster distance test, can be slow
- some gosubs if some condition true
next
next
i use "on key gosub" and "on interval gosub" which may slow down turbo basic ( though i have not noticed it)
You could test if four "pokes" gives you a substantial gain over put sprite. Especially in basic kun this should compile to something that uses nearly no time at all. If that works, then you could use a 128 byte memory buffer for the sprite attribute table and have a small ML routine upload this to vram each vblank (see screen2 upload code on my site for an example implementation).
If it doesn't give you any gain, then you need to optimise other things. Like for instance your distance calculation.
you can do one vpoke and 3 out (&h98,value)
this saves even more
but if you write all spite in sequence you can do one vpoke and a bunch of outs saving a lot of cpu time
