3 replies to this topic

[Hornpipe2]

I'm developing a kernel for my game which is going to have the following stuff on screen at all times. These objects can be independently positioned anywhere, and I want to use the hardware collision detection as well. The on-screen items are:

A single Player0 sprite
A single Player1 sprite
A single ball
A single Missile0 sprite
A single Missile1 sprite
A symmetrical playfield, which needs to change every N lines
A status bar at the top or bottom displaying numeric information. (I think I can figure this out on my own though)

Now my questions:
* Can I cram all this into a 1-line kernel or do I need a 2-line? I may go with the 2-line anyway just because I don't need the vertical resolution of a 1-line kernel. Note that I'm _not_ okay with visual artifacts like cracks in the playfield, black bars on the left side of the screen, flickering, etc.
* Where can I see samples of a 2-line kernel with these items? I don't need anything fancy like multiple sprites, wide sprites, etc. In fact any 2-line kernel source I can look at would probably help me out a ton.

I've been looking for some time and I still don't quite get the hang of the main kernel loop. I think I can write the rest of my game logic no problem if I can just figure out how to get this stuff on screen. I wrote a mockup in bAtari Basic but the produced ASM is really tough to wade through.

Edited by Hornpipe2, Tue May 8, 2007 3:47 PM.

[SeaGtGruff]

Hornpipe2, on Tue May 8, 2007 5:46 PM, said:

A single Player0 sprite
A single Player1 sprite
A single ball
A single Missile0 sprite
A single Missile1 sprite
A symmetrical playfield, which needs to change every N lines

How much you can cram into a 1-line kernel will primarily depend on things like addressing modes, whether or not you're doing anything "fancy" like changing colors from line to line, whether or not you're "unrolling" the kernel, and whether or not you need to check the vertical positions and heights of each object. The fastest LDA/STA instructions use up 5 cycles, and you have only 76 cycles per line, so that means you can update 76/5=15 registers that way per line-- and this assumes that there are no cycles used for incrementing or decrementing indices, performing comparisons, or taking branches. For a typical game, each LDA/STA combination might use up as many as 9 cycles, which would mean you could update 76/9=8 registers that way per line-- and again, this assumes you can use all 76 cycles for LDA/STA combinations, plus it ignores any issues related to the timing of these LDA/STA combinations (i.e., wher the scanning beam is on the scasn line as the instructions are being executed). Fortunately, you don't plan on updating the playfield on every line, and you'll be using a symmetrical playfield, so that will help. But whether you'll need 1 line or 2 lines to update everything else depends on whether you'll be checking their vertical positions and heights to determine whether or not they need to be drawn on the current line.

Michael

[supercat]

Hornpipe2, on Tue May 8, 2007 4:46 PM, said:

* Can I cram all this into a 1-line kernel or do I need a 2-line? I may go with the 2-line anyway just because I don't need the vertical resolution of a 1-line kernel. Note that I'm _not_ okay with visual artifacts like cracks in the playfield, black bars on the left side of the screen, flickering, etc.

It's probably possible to cram all that stuff into one line if you make full use of all available tricks, but your code will almost certainly be simpler and more compact if you content yourself with two-line updates.

For example, you quite reasonably want to avoid nasty 'tearing' artifacts. It will be very hard if not impossible to do all of your updates within horizontal blank, so no single kernel would be able to avoid tearing for all possible object positions. On the other hand, it is possible to have different kernels for different object positions, since in a 1LK it doesn't really matter whether you update an object before or after it's drawn, provided you don't update it while it's drawn. True, updating an object after it's drawn will shift it by a line, but that can be dealt with outside the kernel.

If your game would benefit from a 1LK, don't be afraid to use one. But if it wouldn't benefit, why bother?

[Robert M]

Hornpipe2, on Tue May 8, 2007 3:46 PM, said:

I'm developing a kernel for my game which is going to have the following stuff on screen at all times. These objects can be independently positioned anywhere, and I want to use the hardware collision detection as well. The on-screen items are:

A single Player0 sprite
A single Player1 sprite
A single ball
A single Missile0 sprite
A single Missile1 sprite
A symmetrical playfield, which needs to change every N lines
A status bar at the top or bottom displaying numeric information. (I think I can figure this out on my own though)

Now my questions:
* Can I cram all this into a 1-line kernel or do I need a 2-line? I may go with the 2-line anyway just because I don't need the vertical resolution of a 1-line kernel. Note that I'm _not_ okay with visual artifacts like cracks in the playfield, black bars on the left side of the screen, flickering, etc.
* Where can I see samples of a 2-line kernel with these items? I don't need anything fancy like multiple sprites, wide sprites, etc. In fact any 2-line kernel source I can look at would probably help me out a ton.

I've been looking for some time and I still don't quite get the hang of the main kernel loop. I think I can write the rest of my game logic no problem if I can just figure out how to get this stuff on screen. I wrote a mockup in bAtari Basic but the produced ASM is really tough to wade through.

Yes it can be done. I have attached the source code for my first Atari project "Gravity Ball" which is now aborted. It has a single line kernel that draws all the objects you are interested in in monochrome with no tearing. It does some fancy stuff with the PF graphics to make blocks that slide up and down in the middle, so you will need to work around that which should actually free up cycles. The main kernel you are interested in starts at the label DrawArena, but there are some useful comments about 60 lines above that label in the code. The kernel is actually 4 separate kernels that are switched between depending on if P0 and or P1 are being drawn. Hopefully this code will give you some insight how to manage the timing in a display kernel.

Feel free to asak questions.

 GravityBall013.txt   62.55K   63 downloads

Cheers!
Rob