Too many cycles?

[+Karl G]

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!

 

vert.bas

 

vert.bas.bin

[RevEng]

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.

[+SpiceWare]

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.

[+Karl G]

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.

[RevEng]

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.

[+Karl G]

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.