Speed

[Opry99er]

Would there be any noticeable difference between the following two scenarios?

 

1) Arcade game loop with all collision detections contained inline

 

2) Arcade game loop with collision detections branched to via GOSUB from within a smaller loop

 

 

My thoughts are that having a tighter overall loop makes cycles faster, but that the GOSUB might cost performance. I am on the road for a few days, so no way to test.

 

Do we already have a benchmark for this?

[Tursi]

Here's an old-school way to measure performance of a function.

 

100 FOR A=1 TO 1000
200 NEXT A

Run this and time it. Because it's 1000 loops, the number of seconds you get is how many milliseconds each loop takes. (IIRC it's around 3).

 

Next, just add whatever you want to measure in the middle. In this case, you are curious what a GOSUB costs, so you can do something like this:

 

100 FOR A=1 TO 1000
150 GOSUB 1000
200 NEXT A

1000 RETURN

Measure the runtime again, and subtract how long just the FOR..NEXT loop takes, and that tells you how long GOSUB..RETURN takes.

 

If a test you run is taking too long, you can change the loop to 100 and just multiply the result by 10.

[Bones-69]

I have always used a similar approach when trying to milk as much speed as possible. It's quite amazing the differences when you start testing. I am now curious how different coding will translate once compiled with the XB compiler....

[1980gamer]

BITD, I would WAIST a little to "speed up" collision detection.

I would FLAG sprites as "hit". So if sprite 3 was shot (hit) I would flag it as 1.

 

Then do something like...

IF HIT3=0 THEN CALL COINC....

 

Assuming... you are not looking for #ALL of course.

 

Then when all "hits" were true, I would LEVEL UP or reset the round or Next wave etc.

 

I was 12, I don't know if it was any faster to have an IF fall through, rather than calling COINC?

 

But it seemed to work better. I would also order my sprite numbers in a distance from shot order.

So, if I was a ship at the bottom of the screen, I would have the closest enemy ship be a lower sprite number,

Then try to time when the 2 sprite could collide with the CALL of the call coinc command. Bottom line... COINC sucked!

 

Something like....

REM Shot Fired

for x=2 to Number of enemy ships+1

IF HIT(x)=1 then SKIP CHECK else call coinc(1,#x) or whatever this syntax is ( been a while... sorry )

Do the coinc check.

If it was a hit, do the explosion stuff ( sound, sprite change, delsprite #x ) But also, increase hit count and update hit array.

 

When hit count is ALL SHIPS, then reset hit count to 0 and the hit array to zeros. ( this all happens during LEVEL UP...etc. )

NEXT x

 

 

I tried to do coinc on ALL sprites and call it a few times in the main loop. But it is not practical, individual sprites are almost always required

 

I think I even tried to do coinc on ALL, if it was true, I then called the LOOP to see which sprites collided, but the TI was just to slow.

 

NOW, I just compile it! So much better on many levels. ( wish I could use IF THEN A=B ELSE A=C in the compiler though )

Edited March 6, 2017 by 1980gamer

[LASooner]

When I saw the title, I thought this was announcing a new game about a bus.

[RXB]

Here's an old-school way to measure performance of a function.

 

100 FOR A=1 TO 1000
200 NEXT A

Run this and time it. Because it's 1000 loops, the number of seconds you get is how many milliseconds each loop takes. (IIRC it's around 3).

 

Next, just add whatever you want to measure in the middle. In this case, you are curious what a GOSUB costs, so you can do something like this:

 

100 FOR A=1 TO 1000
150 GOSUB 1000
200 NEXT A

1000 RETURN

Measure the runtime again, and subtract how long just the FOR..NEXT loop takes, and that tells you how long GOSUB..RETURN takes.

 

If a test you run is taking too long, you can change the loop to 100 and just multiply the result by 10.

 

Would it not make more sense to use a DSR clock?

I mean like:

10 CALL CLOCK GET TIME: S$
100 FOR A=1 TO 1000
150 GOSUB 1000
200 NEXT A
300 CALL CLOCK GET TIME: E$ 
400 PRINT "START:"&S$:"END:"&E$

1000 RETURN

[Opry99er]

The program I am working with requires 6 different CALL POSITION checks for "off-screen", and then a COINC (ALL) for sprite collisions.

 

With all those checks in the main loop, it has a bit of a sluggish response for the CALL JOYST and SPRITE motion.

[+Vorticon]

 

Would it not make more sense to use a DSR clock?

I mean like:

10 CALL CLOCK GET TIME: S$
100 FOR A=1 TO 1000
150 GOSUB 1000
200 NEXT A
300 CALL CLOCK GET TIME: E$ 
400 PRINT "START:"&S$:"END:"&E$

1000 RETURN

 

Wouldn't the CALL CLOCK function itself introduce a delay and skew the result?

[+adamantyr]

So you have seven checks? That's a LOT to do in Extended BASIC. Share your code here if you want some pointers. In the meantime, some tips:

 

1) Make sure everything in your game loop uses straight variables and constants. No "R+Y" or "R < TOP", do "R" and "R < 1". Every added complexity slows down execution of the statement.

 

2) Try to order your IF statements so you are always checking the most likely cases first, so that if the rest don't matter, it can skip them.

 

Also... Never EVER use the DEF function. Seriously. I don't know what TI did when they designed that command but it is so abysmally slow it's not even funny. Even doing a function to round numeric variables up costs so much in time you're better off just embedding the INT(N+.5) into the statement directly.

[Opry99er]

Adam, PM on its way.

[RXB]

 

Wouldn't the CALL CLOCK function itself introduce a delay and skew the result?

Well really it 100% more accurate then a STOP WATCH!

 

I mean do you think a human is as fast as the computer?

[+Vorticon]

You do have a point here

[1980gamer]

Well really it 100% more accurate then a STOP WATCH!

 

I mean do you think a human is as fast as the computer?

"Well really it 100% more accurate then a STOP WATCH!

 

I mean do you think a human is as fast as the computer?"

 

Perception vs reality ...

 

I would argue the reality of your exact time has nothing to do with my perceived slowness of the TI.

LOL

 

Oh wait, the reality is the slowness of the TI. Hmmm Confused again.

[Willsy]

"Time? Don't talk to me about time."

(Marvin the Paranoid Android)

[RXB]

Look if the computer can tell you the time it took for a test loop of a subroutine why would anyone think they could push a stop watch and be more accurate down to a 1/100th of a second?

Edited March 8, 2017 by RXB

[senior_falcon]

Look if the computer can tell you the time it took for a test loop of a subroutine why would anyone think they could push a stop watch and be more accurate down to a 1/100th of a second?

Just be sure to take into account the amount of time it takes to do the CALLs to get the time at the beginning and at the end:

10 CALL CLOCK GET TIME: S$

300 CALL CLOCK GET TIME: E$

400 PRINT "START:"&S$:"END:"&E$

If it takes a minute to loop 1000 times this extra time would be trivial. If the loopt takes one second then it would be more significant.

Another thing is that your method will give the amount of time it takes to do something in RXB but not in plain XB, and the speeds may not be the same.

[+Vorticon]

Yet another feature of RXB that can come in real handy for projects. Pretty nifty feature.

[RXB]

 

Just be sure to take into account the amount of time it takes to do the CALLs to get the time at the beginning and at the end:

10 CALL CLOCK GET TIME: S$

300 CALL CLOCK GET TIME: E$

400 PRINT "START:"&S$:"END:"&E$

If it takes a minute to loop 1000 times this extra time would be trivial. If the loopt takes one second then it would be more significant.

Another thing is that your method will give the amount of time it takes to do something in RXB but not in plain XB, and the speeds may not be the same.

 

Well there is a Clock on my PGRAM I can can access and it is pretty dang fast, and many other cards had a Clock too.

 

And you could use them on RXB or normal XB as the access name was on the Card DSR and works the same way as CALL FILES is on the Disk Controller card.

 

The speed may be slightly different as RXB has more commands then XB, but it would not be humanly noticeable as maybe a few tenths of a second.

 

After all you are only going to access it twice, once to start and once when done.

[Opry99er]

If the goal is to determine if there is a noticeable difference between routines, this works fine... as you are not testing the overall speed of the routines, just clarifying the difference in speed.

[RXB]

If the goal is to determine if there is a noticeable difference between routines, this works fine... as you are not testing the overall speed of the routines, just clarifying the difference in speed.

Yea I suppose if you do a test using the clock to determine the time it takes in the lookup table this is the best way to do that.

 

Use at CPU tied wired switch to Interrupt and a Super Cart program to access the routines to test.

Flip the switch and it starts the loop test first of course to turn off interrupts, than it starts the loop that would tell you after say 24 hours a really good round about time in Milliseconds it takes for Clock access.

 

Of course this would be in Assembly.

[Willsy]

That's a really cool feature of RXB.

 

One can get *reasonably* accurate results with a stopwatch. Just put the thing you are timing in a loop of 10000 and time that and divide the time taken in seconds by 10000. That will give you a quite accurate figure. I do that *all the time* in TurboForth when I'm comparing various techniques.

 

Still, if you're programming in RXB then use the built in features of RXB and save yourself the hassle!