Jump to content

Photo

Too many cycles?


5 replies to this topic

#1 kdgarris OFFLINE  

kdgarris

    Chopper Commander

  • 212 posts

Posted Sat Aug 12, 2017 7:17 AM

I'm working on an in-between waves debris-dodging sequence in my game, but it is going pas the number of available cycles in overscan.  I know that vertical scrolling is "expensive", but it doesn't seem like it is doing enough else to explain why I'm using so many cycles.  I have pulled out the relevant code into a simplified example.  Any thoughts on why this is happening, or ways to achieve the same effect without using so many cycles?  Thanks in advance for any advice!

 

Attached File  vert.bas   1.38KB   17 downloads

 

Attached File  vert.bas.bin   8KB   23 downloads



#2 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,704 posts
  • Bitnik
  • Location:Canada

Posted Sat Aug 12, 2017 9:54 AM

pfpixel is fairly expensive, and you're doing it exactly at the moment that the playfield does a coarse scroll, which is very expensive.

 

I modified your two "if playfieldpos = 8 ..." lines to use "if playfieldpos = 7 ..." The scanline overage issue goes away and it looks the same to my eye, despite being too early.



#3 SpiceWare ONLINE  

SpiceWare

    Draconian

  • 11,580 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sat Aug 12, 2017 10:11 AM

Yep - doing things on different frames is good advice.  I have to do the same thing in Draconian even though the game logic is running on a 70 MHz ARM.  My routine that decides when stations will fire starts off like this:
for(s=FRAME&1;s<8;s+=2)
 
FRAME is the frame counter, FRAME&1 will be 0 or 1 on alternating frames so that will process stations 0, 2, 4, 6 on even frames and 1, 3, 5, 7 on odd frames.  

As I finish the game (adding in logic for the Spy Ship) the chance for screen jitter/roll will increase, so I have a note there that I may need change the routine to this:
for(s=FRAME&3;s<8;s+=4)
 
which would halve the number of stations processed per frame: 0, 4 on one frame, 1, 5 on the next, 2, 6 the one after that, and finally 3, 7. If I do this I would also need to increase the odds that a station will fire.

Worse case scenario would be changing the routine to use:
S=FRAME&7
 
which would only trigger a new shot from 1 station per frame. Once again I'd need to increase the odds that a station fires to compensate.

#4 kdgarris OFFLINE  

kdgarris

    Chopper Commander

  • Topic Starter
  • 212 posts

Posted Sat Aug 12, 2017 10:22 AM

Thanks!  The playfieldpos=7 trick fixed my little demo.  I'm still having issues in my main code, but I can probably do some smarter frame management then to avoid it.

 

One question - pfpixel is just flipping a bit somewhere in the 4 variables used for the scrolling row, correct?  Would it be at all faster to just do it as a memory operation as opposed to using pfpixel?  Doubtless that's what pfpixel translates to when converted to ASM, but I thought I'd ask to be sure. 



#5 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,704 posts
  • Bitnik
  • Location:Canada

Posted Sat Aug 12, 2017 11:10 AM

It would be faster to do memory operations, assuming you don't need the flexibility of pfpixel and pfhline. (just noticed you're using pfhline to wipe the pf objects at the bottom of the screen).

 

pfhline cycles through a bunch of plotted pixels, because its general purpose and needs to be able to start and stop the drawing on a bit position. You're using it to wipe a line, but that can be done much quicker with 4x playfield memory assignments. Making this change would be a big win, cyclewise.

 

You could easily convert the pfpixel random pixel creation over to playfield memory assignments too, with a look up table. This improvement would be less dramatic than the pfhline replacement, but it's still an improvement.



#6 kdgarris OFFLINE  

kdgarris

    Chopper Commander

  • Topic Starter
  • 212 posts

Posted Sun Aug 13, 2017 11:34 AM

Breaking up the cycles has helped, and clearing out variables instead of using pfhline has helped as well.  Thanks again!

 

I'm having another issue now, but I'll put it on the starfield effect thread, because it's related to that.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users