Jump to content

Photo

Speed


20 replies to this topic

#1 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,220 posts
  • Location:Cookeville, TN

Posted Sun Mar 5, 2017 9:08 AM

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?

#2 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,597 posts
  • Location:BUR

Posted Sun Mar 5, 2017 4:10 PM

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. ;)

#3 Bones-69 OFFLINE  

Bones-69

    Chopper Commander

  • 164 posts
  • Location:Australia

Posted Sun Mar 5, 2017 7:50 PM

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....



#4 1980gamer OFFLINE  

1980gamer

    Dragonstomper

  • 707 posts
  • Location:Charlton, MA

Posted Sun Mar 5, 2017 8:50 PM

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 by 1980gamer, Sun Mar 5, 2017 8:53 PM.


#5 LASooner ONLINE  

LASooner

    Star Raider

  • 97 posts

Posted Sun Mar 5, 2017 8:52 PM

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

#6 RXB OFFLINE  

RXB

    River Patroller

  • 2,503 posts
  • Location:Vancouver, Washington, USA

Posted Mon Mar 6, 2017 2:59 AM

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


#7 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 8,220 posts
  • Location:Cookeville, TN

Posted Mon Mar 6, 2017 9:14 AM

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.

#8 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,593 posts
  • Location:Eagan, MN, USA

Posted Mon Mar 6, 2017 9:52 AM

 

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?



#9 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,030 posts

Posted Mon Mar 6, 2017 10:29 AM

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.



#10 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 8,220 posts
  • Location:Cookeville, TN

Posted Mon Mar 6, 2017 10:36 AM

Adam, PM on its way.

#11 RXB OFFLINE  

RXB

    River Patroller

  • 2,503 posts
  • Location:Vancouver, Washington, USA

Posted Mon Mar 6, 2017 1:35 PM

 

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?



#12 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,593 posts
  • Location:Eagan, MN, USA

Posted Mon Mar 6, 2017 5:01 PM

You do have a point here :)
  • RXB likes this

#13 1980gamer OFFLINE  

1980gamer

    Dragonstomper

  • 707 posts
  • Location:Charlton, MA

Posted Tue Mar 7, 2017 12:31 PM

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.



#14 Willsy OFFLINE  

Willsy

    River Patroller

  • 2,950 posts
  • Location:Uzbekistan (no, really!)

Posted Tue Mar 7, 2017 1:24 PM

"Time? Don't talk to me about time."
(Marvin the Paranoid Android)

#15 RXB OFFLINE  

RXB

    River Patroller

  • 2,503 posts
  • Location:Vancouver, Washington, USA

Posted Wed Mar 8, 2017 1:41 AM

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 by RXB, Wed Mar 8, 2017 1:41 AM.


#16 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 827 posts
  • Location:Lansing, NY, USA

Posted Wed Mar 8, 2017 5:57 AM

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.


#17 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,593 posts
  • Location:Eagan, MN, USA

Posted Wed Mar 8, 2017 12:30 PM

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



#18 RXB OFFLINE  

RXB

    River Patroller

  • 2,503 posts
  • Location:Vancouver, Washington, USA

Posted Wed Mar 8, 2017 12:32 PM

 

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.



#19 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 8,220 posts
  • Location:Cookeville, TN

Posted Wed Mar 8, 2017 1:36 PM

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.

#20 RXB OFFLINE  

RXB

    River Patroller

  • 2,503 posts
  • Location:Vancouver, Washington, USA

Posted Thu Mar 9, 2017 12:50 AM

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.



#21 Willsy OFFLINE  

Willsy

    River Patroller

  • 2,950 posts
  • Location:Uzbekistan (no, really!)

Posted Thu Mar 9, 2017 5:18 AM

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!




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users