Newcomer with some questions

[dhalsimrocks]

Hey, first post here. Just a little background on me... I have a degree in computer science, graduated in 2002, have done a fair bit of programming in C. So I'm not totally new to programming. I've been doing it for over 10 years. Just... not in assembly.

 

A month or so ago I decided it would probably be fun to write a game for the VCS and started devouring all the tutorials and 101's I could find, including a lot of documentation here. It has been extremely helpful getting me started and I already understand a lot about the VCS, 6502, the TIA, etc. I'm going to be using assembly because a) I'm not afraid of it and b) I've been wanting to learn it for years and this is definitely facilitating that, and rapidly. I've come a long way in just a month.

 

My game is a vertical scrolling shooter, by the way.

 

Nonetheless, I'm finding myself with some questions. I would like to eventually "complete" this game and have it as an ongoing project. So I'd like to make some good design decisions right now. So on to my questions:

 

1 line kernel vs 2 line kernel

 

My impression here is that a 2 line kernel keeps the TIA's state the same for two scanlines, thereby giving an additional scanline's worth of cycles for whatever you need (setting an asymmetric playfield or something), and also having the effect of lowering the vertical resolution (which seems to me could also reduce graphic sizes since it effectively turns an 8 byte graphic into 16 visual).

 

So is my impression correct? Also, I'd love to see a good example of a 2 line kernel in case that's what I should be considering.

 

Asymmetric Playfield

 

I understand exactly how this works and I've implemented it myself in practice projects. I also realize it's very expensive to do. Is it something I could realistically do in a vertical scrolling shooter? Since asymmetric playfields have to be done in the display kernel, would having a 2 line kernel be the best way to go about this?

 

Code Arrangement

 

Ok, so I know that vertical blank, horizontal blank and overscan are great opportunities for calculations, sprite positioning, collision detection and such. Is there any convention for what is typically done during those different non-display periods? Or is it really just preference?

 

Symbols that begin with a dot/period

 

I've read some source code that have symbols that start with a dot/period. What is the reasoning behind this? My text editor (vim) even displays them in different highlighting color. It looks something like the following:

 

lda #$83
sta someVariable
cmp otherVariable
bne .doSomething
; other stuff
.doSomething
; more stuff

 

What can I realistically do?

 

In playing other VCS games, I've seen 3 different ways of displaying a ship's gunfire. I see the ball used, P0 and P1 missiles and in Solaris, I noticed Neubauer was actually using the player graphic. Demon Attack does the same thing with the enemy fire, AND I like Demon attack's multiple rounds/bullets/beams. I like that VERY much. I'd like to have as much gunfire on screen as possible, both from the player's ship and the enemies. I know there's going to be a limit, but I do want to go as far as I can with it.

 

Ideally, I'd like to be able to fire more than just one ball or missile at a time and it seems like the player graphic is the way to go about it, but I'm guessing that would come with a sacrifice. Is it possible to duplicate the missile without also duplicating the player?

 

One thing I do NOT want is the missile (if I use it) to track the position of the player ship, such as with Megamania or River Raid. Is that a matter of writing to the proper TIA register?

 

Ok, that should be good enough to start. There will be more I'm sure.

[yllawwally]

The TIA won't be in identical states on each line even in a 2 line kernel. The 2 line kernel, allows you to do the work for one sprite on one line and the other sprite on the second line. This was built into the TIA, via delay graphics commands. This is also helpful for single line kernels. Allowing you to update one set of graphics at any point during the scan line, and then display the new graphics at the proper time on the next line. Asymmetrical playfields are expensive in several. It takes a great deal of RAM or ROM to hold the playfield data. 192 lines with 5 bytes per line, is a lot of data. Also the playfield must be written at certain times, also increases the difficulty. It doesn't matter much what calculations are done during each section. It is whatever makes sense to you, for the particular game you are writing at that time. The period before names, is to make local names, versus global names.

[+SpiceWare]

2600 coding is all about tradeoffs. It's difficult for others to decide those tradeoffs for you so you'll basically need to dive in and figure it out what you can do vs what you wish to do.

 

Have you found MiniDig yet? There's numerous disassemblies that may help you figure out what to do. Older 2K games like Air Sea Battle and Indy 500 would be ones to look at for examples of 2LK.

 

There's no set code arrangement.

 

Symbols with a . are "local labels". They work hand-in-hand with dasm's SUBROUTINE pseudo-op. Read dasm's help file (dasm.txt) for more info.

 

As far as "What can I realistically do?", it's all about the tradeoffs - which only you can decide on for your game.

Edited June 24, 2013 by SpiceWare

[+Gemintronic]

2600 coding is all about tradeoffs. It's difficult for others to decide those tradeoffs for you so you'll basically need to dive in and figure it out what you can do vs what you wish to do.

 

Have you found MiniDig yet? There's numerous disassemblies that may help you figure out what to do. Older 2K games like Air Sea Battle and Indy 500 would be ones to look at for examples of 2LK.

 

There's no set code arrangement.

 

Symbols with a . are "local labels". They work hand-in-hand with dasm's SUBROUTINE pseudo-op. Read dasm's help file (dasm.txt) for more info.

 

As far as "What can I realistically do?", it's all about the tradeoffs - which only you can decide on for your game.

 

I can write my kernel with no hmove bars

No hmove bars

No hmove bars

I can write my kernel with no hmove bars

No hmove bars

No hmove bars

 

Look at me, look at me

Hands in the asm like its good to be

Alive and I'm a famous developer

Even when indexes cross a page boundary

I can show how to save a cycle or three

I can show how to scratch a RAM location

I can take apart the source control

And I can almost put it back together

I can tie a NOP on a priority system

I can tell you about Larry Kaplan

I know all the labels to "Air-Sea Battle"

And "I'm proud to be an Atari Fan"

Me and my friends play Plaque Attack

Me and my friends play Cosmic Ark

And guess how long it took

I can sudo anything that I want 'cause look

[RevEng]

Missiles don't need to track the corresponding players. They have their own position registers.

 

The answer to most of your other questions is "depends on the requirements of your game", so its difficult for anybody to give a general answer without a more complete context. For example, asymmetric playfield might be too expensive to do if you're also drawing 2 players and 2 missiles, but maybe you don't need those elements. Maybe you can draw the playfield every other line, or every 4th line, and that might satisfy the game requirements. Or maybe your game design will work with a partially asymmetric playfield.

 

Don't sweat what the convention are for doing stuff in overscan or vblank or anywhere else, as there are none. Don't get hung up on conventions. Writting a game for the 2600 is the most unconventional thing you'll do in your programming experience. You will write spaghetti code. You will heavily reuse variables. You will throw away a routine you thought was clever and elegant because the brute force method winds up being more efficient in every way.

 

You won't come up with the perfect design on paper and implement it as planned. A 2600 game is an organic thing that starts with a rough plan and a simple kernel, and grows into a game bit by bit. Sections of code will get done and redone in the scoffolding of the old code.

 

My recommendation for you is to just try writing a 1 line kernel and start adding stuff into it. Changing a 1 line kernel into a 2 line kernel isn't a big deal once you start to understand how screen updates need to be organized to avoid stepping on them as the scanline is drawing those same elements.

 

Also realize that you will probably throw away these fledgling efforts when you've learned from them. Nobody writes the great american novel in their first creative writing attempt. The same is true for 2600 games.

[dhalsimrocks]

Thanks for all the answers/replies. I had a feeling much of what I was asking was dependent upon my particular project, but I wanted to make sure. I don't like to make assumptions.

 

I'll definitely check out a lot of source on Minidig. RiverRaid will be particularly useful.

 

Also realize that you will probably throw away these fledgling efforts when you've learned from them. Nobody writes the great american novel in their first creative writing attempt. The same is true for 2600 games.

 

Haha... that's already happened to me like three times. I'm expecting more.

 

I'm almost certain I'll forgo the asymmetrical playfield. I think I can still do what I want without it.

 

I intend this to be an ongoing project, something that may take years or not get finished at all. However, I've had so much fun thus far that I can see myself coming back to it regularly as I learn more or figure out new things. Thanks again, and I'll probably have more questions soon enough.

[+SpiceWare]

I'm almost certain I'll forgo the asymmetrical playfield. I think I can still do what I want without it.

 

You might be able to get by with a smaller asymmetrical playfield. Normally asymmetrical playfields are done using repeated mode so the playfield registers are output as PF0 PF1 PF2 PF0 PF1 PF2. You can use reflected mode (PF0 PF1 PF2 PF2 PF1 PF0) and just not update PF0. PF0 is the "short" register, as only the upper nybble (4 bits) of it are used, so dropping it has limited repercussions.

 

When I started work on Stay Frosty it was going to use the normal repeated asymmetrical playfield:

 

But I changed it to reflected due to lack of RAM and cycles. PF0 is only updated in the horizon and for the bottom most platform.

 

Another one of the changes that happened early on was Frosty lost his nose:

 

It was drawn using missile 1, which takes on the color of the fireballs drawn using player 1.

Edited June 25, 2013 by SpiceWare