[hseiken]

When using bound sprites in the MSDOS version of MZX, what is the 'general tradeoff' of commands processed per sprite? Is that measurable on my end with some robotic code to get frame rate or some other kind of useable readout for this sort of performance tracking? I'm not even going to try unbound sprites.

As well, is there a board tile limit that begins to impact performance? I recall the older DOS-ONLY MZX had a board size limit, so removing that limit surely can have an impact in terms of memory access? Again, if there's some code snippet to plug into a robot that gives some kind of performance feedback would be maybe most useful? At least when using the newer features like sprites...I haven't seen any performance issues with having 255 robots making a disco out of a board yet..but just a few bound sprites and it crawls...

Maybe I'm not understanding out a frameupdate is determined and that can help with optimizing sprites, too? But again, i don't even know how to code a frame report gadget...gah...

I hope this line of questioning makes sense as to what I'm trying to ask very poorly. I didn't put this in robotic talk as I felt it sort of overlaps into general MZX operation with regards to the the difference of just executing robotic vs. executing robotic AND splashing a sprite onto the screen. Apologies if this isn't the place for clumsily worded post.

[Lachesis]

hseiken, on 25 November 2024 - 09:28 PM, said:

When using bound sprites in the MSDOS version of MZX, what is the 'general tradeoff' of commands processed per sprite? [...] I'm not even going to try unbound sprites.

Classic sprites do not incur a significant performance impact and they can be used just fine with the EGA renderer. A lot of them may slow things down on very very old machines, but you are likely to run into Robotic performance limits long before that becomes a problem.

If you do end up using unbound sprites, you need to switch to the SVGA renderer, which will incur a performance impact (as it is software rendered). Additionally, each unbound sprite needs to be rendered in a separate pass. That said, games like Pandemonium Buster run fine on my 2004 Celeron (aside from the menu starfield effect, which is caused by Robotic...), so even then you might not run into serious performance degradation. The software renderer has been receiving regular performance upgrades and is quite fast now, I should note.

Quote

As well, is there a board tile limit that begins to impact performance? I recall the older DOS-ONLY MZX had a board size limit, so removing that limit surely can have an impact in terms of memory access?

Yes, though I can't give you a hard number here! I recommend experimenting with board sizes filling them with something like ice/fire (with fire burns forever)/lava to see when things start to slow down.

If you want to be as safe as possible you can stick to the DOS maximum board sizes, which were:

• 66x166
  
• 80x125
  
• 100x100
  
• 200x50
  
• 400x25

edit: if you choose to use the vlayer for sprite graphics references, its size does not significantly affect performance at all. I have ran into thrashing problems caused by ridiculously huge ones (like the one Bloodlands accidentally sets), but normal sizes shouldn't affect anything. Unlike the board, the vlayer doesn't have any objects/robots/whatever that need to update.

Quote

Is that measurable on my end with some robotic code to get frame rate or some other kind of useable readout for this sort of performance tracking?
Again, if there's some code snippet to plug into a robot that gives some kind of performance feedback would be maybe most useful? At least when using the newer features like sprites...I haven't seen any performance issues with having 255 robots making a disco out of a board yet..but just a few bound sprites and it crawls...
But again, i don't even know how to code a frame report gadget...gah...

This isn't perfect, but it might be helpful:

. "@FPS"
: "t"
set "$h" to "0&TIME_HOURS&"
set "$m" to "0&TIME_MINUTES&"
set "$s" to "0&TIME_SECONDS&"
set "$t" to "&$h+('$h.length'-2)&:&$m+('$m.length'-2)&:&$s+('$s.length'-2)&"
: "l"
* "~f&local29& :: &$t&"
loop start
inc "local&local31&" by 1
cycle 1
loop for 4
if "local30" = "TIME_SECONDS" then "l"
set "local26" to "(1000000000)"
set "local27" to "(-1000000000)"
set "local28" to 0
loop start
inc "local28" by "local&loopcount&"
if "local26" < "local&loopcount&" then "min"
set "local26" to "local&loopcount&"
: "min"
if "local27" > "local&loopcount&" then "max"
set "local27" to "local&loopcount&"
: "max"
loop for 9
set "local29" to "('local28'-'local26'-'local27'/8)"
set "local30" to "TIME_SECONDS"
set "local31" to "('local31'+1%10)"
set "local&local31&" to 0
goto "t"

edit: this expects speed 1. If you use it at normal speeds the "loop for 4" should probably be removed.

This post has been edited by Lachesis: 26 November 2024 - 05:01 AM

[hseiken]

Lachesis, on 25 November 2024 - 11:44 PM, said:

Classic sprites do not incur a significant performance impact and they can be used just fine with the EGA renderer. A lot of them may slow things down on very very old machines, but you are likely to run into Robotic performance limits long before that becomes a problem.

If you do end up using unbound sprites, you need to switch to the SVGA renderer, which will incur a performance impact (as it is software rendered). Additionally, each unbound sprite needs to be rendered in a separate pass. That said, games like Pandemonium Buster run fine on my 2004 Celeron (aside from the menu starfield effect, which is caused by Robotic...), so even then you might not run into serious performance degradation. The software renderer has been receiving regular performance upgrades and is quite fast now, I should note.


Yes, though I can't give you a hard number here! I recommend experimenting with board sizes filling them with something like ice/fire (with fire burns forever)/lava to see when things start to slow down.

Thanks a lot for the info. I've been playing around with my 'fast modern machine' and moving things I think aren't all that 'deviously computationally expensive' and being surprised on the dosbox machine to find performance being all over the place. Thanks for the snippet of code, I'll see if that helps me figure out where I'm probably doing something wrong.

[hseiken]

I did some more testing and it seems the biggest effect on the setup I'm using was board size. And specifically vertical size. Horizontal would hiccup when scrolling past 80-100 columns (felt like it was loading in more of the board or something? just for a tick..) but when adding verticality to the board, once a certain height was hit, it permanently kept the frame halved. This seems to be what affected the things I was trying...as soon as I shrunk the board, suddenly the sprites were zipping around as expected. This might be useful for folks to note.

Oh also I noticed my system dropped in frame rate if I didn't properly cycle 1 out of short but constant check loops. I shoved a cycle 1 into a couple of those and got some frames back.

[Lachesis]

hseiken, on 29 November 2024 - 01:15 PM, said:

I did some more testing and it seems the biggest effect on the setup I'm using was board size. And specifically vertical size. Horizontal would hiccup when scrolling past 80-100 columns (felt like it was loading in more of the board or something? just for a tick..) but when adding verticality to the board, once a certain height was hit, it permanently kept the frame halved. This seems to be what affected the things I was trying...as soon as I shrunk the board, suddenly the sprites were zipping around as expected. This might be useful for folks to note.

I don't know that there's anything special about making the board taller that would have made things worse—that might just be because the viewport is 80x25, so boards tend to be wider than they are tall by default and extra height grows the size faster than extra width.

Quote

Oh also I noticed my system dropped in frame rate if I didn't properly cycle 1 out of short but constant check loops. I shoved a cycle 1 into a couple of those and got some frames back.

Yeah, there's a WAIT 1 thread somewhere around here, and though Wait 1 Theory gets ragged on a little, the advice it gives is correct—if you don't add a WAIT 1 or CYCLE 1 to yield a loop, robots will just execute the loop over and over until they hit the current commands limit.

A quick demonstration of this:

: "l"
inc "local" by 1
* "&local&"
goto "l"

: "l"
inc "local" by 1
* "&local&"
wait for 1
goto "l"

The first example will increment by 13-14 every cycle at the default commands/cycle limit (40), and the second example will increment by 1 every cycle. This gets worse as you increase the COMMANDS counter.

If you're still having issues with sprite performance and haven't tried increasing the COMMANDS counter yet, I do recommend doing so (after you've made sure every loop is yielding). Sprites can be fairly Robotic-heavy and that might be part of the issue. (Though Robotic is just slower on old machines and in DOSBox, too.)

This post has been edited by Lachesis: 14 December 2024 - 08:53 PM