[ice 252]

ok so i have heard that you should not mess with the SET "COMMAND" TO X code unless you know what you are doing, I also read that it can slow the game down to a crawl if set to high. so my question is, could you set the COMMAND to X code to a high number just while you load info and then set it back to the defult "30" and would this have any drastic effect on the game? ? ?

Thanks, Ben

[Risu2112]

Yep, increasing "commands" while initializing a board and then dropping it back down would be fine. But I think the default is 40 not 30.

you could raise it several times the default amount and not cause any slowdown on a modern computer, just if you start to get drastic like over 10x you need to be RESPONSIBLE with your cycles and make sure to end them with wait 1's so you don't suck all the juice.

The strict limit on commands per cycle is a safe guard against sloppy code. example:

:loop
if spacepressed "pause"
goto loop

that would cause lots of problems if you set commands too high, there's no need to check for that condition more than once per cycle, the solution is to add in a wait 1 to end the cycle

:loop
if spacepressed "pause"
wait 1
goto loop

The above situation is 99% of the reason why a novice mzxer should be careful when pushing the commands counter too high.

This post has been edited by Risu2112: 24 October 2007 - 12:15 AM

[ice 252]

k sweet thanks a ton, its not used in a loop, just when i load some info and it only has to load once and then its droped, thanks again!

[Wervyn]

For more complex games with code intensive engines, you will have situations where you need commands to be constantly set reasonably high in order for the game to work right. Of course, if you're actually pushing the code to where you need to execute 32767 commands in a cycle, your game is going to be slow with or without a wait 1. So it is possible to set it only up to the number of commands that need to be executed. However, this takes a lot of busywork to figure out, and is subject to change if you change your code, so what most people do when they need to do this is set commands arbitrarily high and then code responsibly.
This is a good skill to learn now, because someday you're probably going to want to write engines that need extra cpu, and being in the habit of coding a wait into all of your non-terminating loops will be to your advantage. I'm not saying you need to always set commands high, because you don't, and you shouldn't when you don't need to. But you should learn to put in appropriate wait 1's even when you don't technically need to, just because it's a good practice.

"Loose loops sink ships! DON'T GOSSIP!"

[nooodl]

Putting wait 1's into code has become some kind of habit for me already... :)

[Kom]

I should have done that in Doom Spire , making commands be set back to 40 after the level generates. But it never played slow for me so I figured that it wouldn't matter that much.

[Pyro1588]

because i'm lazy but rarely forget my "wait" statements, i like to set my commands high and then just code per normal. i guarantee you, i need commands higher than 40, but i have no desire to try to determine how high exactly i need it.

that and most relatively complex globals and such will have enough subroutines so that it's almost impossible to determine what the maximum number of cycles is with the global.

[Risu2112]

I still think we should have a read only counter set to the value of the number of commands executed last cycle, said counter would be a GREAT debugging tool for situations like that.

[Exophase]

Risu2112, on Oct 24 2007, 01:48 PM, said:

I still think we should have a read only counter set to the value of the number of commands executed last cycle, said counter would be a GREAT debugging tool for situations like that.

I don't think so, if it's too many you'll know it. It wouldn't tell you where all those cycles are being spent. Maybe you want a profiler for that.

[Risu2112]

Either one would have greatly sped up the development of my pixel perfect engine, being able to know what cycles there was a surge of commands would have quickly identified some huge inefficiencies that went undetected by me for quite a while. Also having that value displayed while testing would give a reasonably accurate indication of the average commands the board consumes under normal operation, info like that would be great for us mzx'ers with really fast computers, the initial incarnation of my pixel perfect engine ran great on my laptop, but as it turned out it was producing slowdown even on a Pentium 4, 2.26ghz. Duo-core is not a realistic system requirement for a mzx game

This post has been edited by Risu2112: 24 October 2007 - 09:11 PM

[Old-Sckool]

Kom, on Oct 24 2007, 07:26 AM, said:

I should have done that in Doom Spire , making commands be set back to 40 after the level generates. But it never played slow for me so I figured that it wouldn't matter that much.

nah, I didn't have any issues with the game engine itself running too slow (though I never got too far to begin with...). Besides, wouldn't setting your commands back to 40 break your nifty pointy arrow thing?

... anywho, I find that my computer can handle commands set somewhere around 40000/50000 (if you didn't know, that would be written as "(40000)" ) without too much slowdown.

[Risu2112]

the # of commands you can run without slow down does vary widely with what commands are being used, some take considerably more power than others, Also, commands is # of commands per cycle per robot. setting commands to 40,000 with some sloppy coding could potentially cause a lot of slowdown.