6 replies to this topic

[yuppicide]

Could someone explain cycles to me? I have a game I'm working on. I don't have the game on a real cartridge yet, so I'm only testing in Stella for now.

The game is pretty basic right now.. I've only added one level and it doesn't do anything. The only thing you do is control a tiny fish on the screen. There
is a playfield drawn, pfres of 20 using SC, your little fish who has player graphics for moving left, right, and when you don't move for awhile he has
bubbles coming out his mouth. If you collide with playfield you die.

This is the first time I've paid attention to cycles and have tried to use the debug things. I set debug cyclescore and followed the instructions for that.

When I start up the game a lot of times it will say 1728 in white. It's constantly at that number. The number never changes when I use cyclescore. Sometimes
when you start up the game it will say 2400something in white, but then go down to 1728. Sometimes it will say 8400something in red, and sometimes it will
have a garbled character. Each time the number is fixed.. never changes except in the first case.

I'm not sure what to believe. Just seems like I get random response every time.

If I run the set debug cycles option, the background never changes like it says on the bB Command Reference page.

Do you think I should just wait until I get my EPROM burner and test on real hardware and not worry about this for now?

Edited by yuppicide, Fri Sep 26, 2008 7:27 AM.

[Random Terrain]

I haven't used cyclescore a lot, but when I have, it does change depending on what is happening in the program. Sometimes your program can use more cycles than other times and cyclescore shows that. As it says here, if the score color is white, that's how many cycles are left. If the score is red, you are using too many cycles. If you get garbled characters, you have probably used so may cycles that you have ripped a hole in the space-time continuum.

[yuppicide]

Well, what I am confused about is I have a very basic program so far.

Starts up, displays a playfield, displays a tiny fish. You can move the fish. Fish has two pictures.. one if you are moving right, one if moving left. If you don't move he'll have a few animation frames of bubbles coming out.

When I put on cyclescore it !always! shows me a different number.. Like today I was testing it out after I read your message. Sometimes it'll sit at say 201 in white or 108 or 190 in white. When I kill myself and hit F2 in Stella it'll show like 1728 in white. Other times I kill myself and hit F2 in Stella it shows higher numbers in red. Sometimes garbled.

With all the different readings I'm not sure which one to actually believe.

I think I'm just gonna get ready to burn and test it on a real 2600 and see how it behaves.

[potatohead]

Cycles are the discrete blocks of time consumed by each 6502 machine instruction. bB compiles each statement into one or more of these.

a = a + 1

boils down to something like

lda A
adc #1
sta A

Each of those has a cycle count. That count is usually between 2 and 5 (I think) cycles. There are charts on the net and I probably should look at one. However, the key thing is that statements consume time.

The 2600 does nearly everything with the cpu, meaning you've only got specific amounts of times to do things every frame. When you do the drawscreen, the 2600 draws a picture on the TV. During this time, there is very little time to do anything but that. In between pictures, it takes time for the TV beam to move to the top and begin another frame. That's generally when your bB program runs.

Somebody else is gonna post up the number of cycles available to you during this time. 1700 comes to mind....

There is a timer that counts of blocks of time. It's up to the program to look at it, and decide to quit doing stuff and draw the TV screen. If this fails to happen, the TV image will be late and the TV will then roll the display, or display garbage, or go blue, depending on the TV and how late one really is.

The way I do it is to build the program in little bits, adding functions here and there, using the simplest constructs I can to keep time to a minimum. So, that means things like multiply and divide other than powers of 2 (2, 4, 8, etc...), fixed point math and such consume considerably more time than simple adds do. (subtracts can be done as adds, just so you know).

If the display rolls, then you have consumed too much time.

Other things that take a lot of time are playfield scrolling, and tight loops that do stuff that must complete before the drawscreen can.

If you want to, you can build such a loop, then pack it with instructions until the screen rolls, then multiply the number of instructions times the loops completed to get some idea of how many statements you have left. That will be rough, but likely good enough. That's what I did with Ooze!

If you can break tasks across frames, then you distribute your time demands such that no one frame is gonna break the stream of frames over time.

Updating enemy AI, for example, can happen this way. So can sound loops! You can start a sound on one frame, update it by changing the sound register across many frames, then end it some number of frames later. At any one time, this takes only an instruction or two, so maybe 15 cycles. No big deal.

On the other hand, if you tried to pack the whole sound into one frame, the sound itself would run too long, rolling your display!

That drawscreen needs to execute every single frame on time, or ideally a bit before, or the display will get hosed.

[potatohead]

Just re-read your post.

Sounds to me like when the player dies, there is a lot going on. Betcha that's all getting packed into one frame, instead of being distributed over a number of them.

Use a flag to control game states.

Game states are: Game running, game over, player alive, player dead, etc...

So, say the player alive flag is set. (this is a variable or a bit within a variable set to a value that means player alive)

You run through your game loop, branching to those things that need to get done for the player being alive for that frame.

Now, the player dead flag is set. Perhaps this is just unsetting the player alive flag, which is what I would do.

Now, you run through the loop doing a different set of things! Maybe skip the player movement parts (dead players don't move), and trade those cycles for animation of the death sequence of images and the sound that goes with it.

[yuppicide]

I'm just gonna do testing on real hardware instead. This is too frustrating. My game doesn't even do much for it to use that many cycles.. just draws the screen and player and makes the player move. You touch playfield and die, it reboots. Done.

[potatohead]

Then it's simply not using all that many cycles.

Honestly, if you don't have a lot of tight loops that could prevent a drawscreen from happening in time, you are gonna be fine.

Since you have access to real hardware, it's actually going to be simple to just run your test, then code some stuff, then test from time to time.

A quick look at some of the other programs out there can give you an idea of what can and cannot be done in one frame. Most stuff can.