Cycle Count/Scan Lines

[KevKelley]

One thing that throws me off when reading is when people reference cycles or scan lines. I haven't tested my game on real hardware yet and am not quite sure what I need to look at in the Stella debugger.

 

Also curious as to some of the best ways to correct for any overages if some should exist.

[+Random Terrain]

Have you seen this on the bB page:

 

What is a cycle?

 

 

These also might be useful:

 

Cycle Count: Addition

Cycle Count: Bit Operations

Cycle Count: Division

Cycle Count: gosub

Cycle Count: goto

 

 

One thing I see repeatedly is people using gosub when they don't need to. The only reason to use gosub is when your program needs to reuse the same code in different places (to save ROM space). As it says on the bB page, "calling a subroutine and then doing a return takes up more machine cycles than doing a straight goto." Jumping to random code with gosubs just for the heck of it wastes precious time (cycles).

[KevKelley]

I think I had wound up reading that at one time or another early on. So if I understand that correctly, I need to run my program under 255 cycles otherwise I risk it screwing up?

 

So in emulation I noticed in the debugger there is are spots that say things like "frame count" or "frame cycle" or "scan cycle." Which one is the important one to watch?

[+Random Terrain]

I forgot to include this from the Useful AtariAge Links section:

 

Keeping Track of the Scanline Count with Stella

I use The Faster, Easier Way to make Stella stop whenever a work in progress goes over 262.

[KevKelley]

Thanks. That is a big help.

[+Muddyfunster]

One thing that throws me off when reading is when people reference cycles or scan lines. I haven't tested my game on real hardware yet and am not quite sure what I need to look at in the Stella debugger.

 

Also curious as to some of the best ways to correct for any overages if some should exist.

 

RT's notes on how to track and monitor overcycling are really good advice.

 

I was running into overcycle issues on Tyre Trax and my scanlines were going over 262 at certain points.

 

I found that my biggest problem (mostly due to inexperience) was that I was trying to do too much each frame, so I moved things to happen on different frames and this mostly fixed the problem. I learned that you don't need to do everything at once

 

I read some good advice in threads here about moving logic or certain pieces of code that aren't needed every single frame to be run for example on alternate frames.

 

I also found that as I expanded my idea for Tyre Trax and tried new things with bB, my code became better and I stopped doing crazy things (in hindsight ) like defining the whole playfield every frame or defining every sprite on every frame (because...yeah, reasons!...).

 

Defining the playfield every frame I believe devours cylces like a hungry Trex . I also made other optimisations like easing the number of animation "lanes" on the river from 8 to 3. To be honest, because of the other optimsations, I could probably put them back in now.

Edited December 16, 2018 by Muddyfunster

[KevKelley]

How do you specifically designate tasks to happen on different frames? Is it placing certain code after drawscreen to bring the cycle count down?

[ultima]

You can create a variable that increments or decrements after drawscreen is called. If using every other frame you can just use a bit from a variable that is on or off. At the start of the loop set a condition then execute which code you want to run then on the next loop run the rest.

[KevKelley]

Okay. I have been meaning to rework the variables in my programming. I didn't realize some of the limitations when I started and used them up carelessly. My code is very sloppy and as I learned new things I kind of just plugged it in as I went along. I'm sure I can tighten up the code and free up some stuff.

 

I had been reading about turning bits on and off and I think I understand it. I remember it from a response I had regarding movement and ricocheting. I am still fuzzy on how to implement some of the code after reading the sample programs but I think I can figure it out.

 

I was hoping to work on my game during my vacations but everyone (including me) in my house decided to get sick so I have been trying to absorb as much info as possible. I am gonna drag out my laptop tonight and see if I can play around a bit.