Creating new game – drawing, scanline and positioning issues.

[Mikes360]

Hello All;

 

I am a new developer to the 2600 programming scene and I haven’t really got any previous assembly programming experience especially in 6502.

 

I have been working on a game in which the player is a spaceship that can move freely around the playing field and there will be enemies and other things coming down the screen that the ship has to blow up, dodge collect ect..

 

The code I have uploaded is my best effort at putting together a framework to create such a game. However I have stumbled into several issues I feel I need advice from a more seasoned developer.

 

The first issue with the drawing kernel is that I don’t keep track of the player line correctly when jumping to another mini kernel to draw an enemy as well as the player. I was wondering if anyone could look at this code and advise me how the code could be modified to fix this issue.

 

The second issue is that I am struggling to keep a constant scanline count when I add more complex routines after drawing the frame. This is because of loops that can take a varying number of cycles to complete depending on the items on screen and the more branching gets introduced. I have an example of this in my “game field processing routine”

 

And finally to progress the framework further I need to be able to horizontally position the enemy sprites independently. I haven’t even tried this as I feel I need advice on how to do this as the positioning routines I know of all require you to consume two whole scanlines to enable the fine positioning.

 

There is a whole raft of other things I want to add like animation of sprites but I want to get a solid foundation before I progress the game further.

 

Any help would be greatly appreciated!

src.zip

kernel.bin

[Mikes360]

I have managed to get the scanline count to a stable 312 by changing the loops in the game field processing routine to loop a fixed number of times.

 

I still haven't managed to get the player drawing perfectly though... Any ideas?

kernel.bin

src.zip

[bogax]

Haven't taken the time to find my way all through your code.

 

Here's a constant time divide by 15 (reciprocal multiplication)

 

sta temp
lsr
lsr
lsr
lsr
adc temp
ror
lsr
lsr
lsr
adc temp
ror
lsr
lsr
lsr

Edited January 25, 2013 by bogax

[Omegamatrix]

Haven't taken the time to find my way all through your code.

 

Here's a constant time divide by 15 (reciprocal multiplication)

 

sta temp
lsr
lsr
lsr
lsr
adc temp
ror
lsr
lsr
lsr
adc temp
ror
lsr
lsr
lsr

 

 

Here's a more optimized one I developed:

 

;14 bytes, 24 cycles

sta tempOne

lsr

adc #4

lsr

lsr

lsr

adc tempOne

ror

lsr

lsr

lsr

 

For horizontal positioning off screen, most games use a variant of this type of code:

 

HorizPositioning; SUBROUTINE
   sec
   sta    WSYNC
;---------------------------------------
.divideBy15
   sbc    #15
   bcs    .divideBy15
   eor    #7
   asl
   asl
   asl
   asl
   sta    HMP0,X
   sta    RESP0,X
   rts

 

Set X to the object you want (ie. ball = 4, P0 = 0), and load A with the desired pixel position. When positioning while the screen is being drawn then you might want to divide the screen horizontally into different sections, and have 2 or more positioning routines to handle them. That way you can still do stuff while you are repositioning.

[Mikes360]

Hi guys what advantage does the constant positioning routine provide? I assume it will still require two scanlines to complete. The idea of splitting the screen into two sounds interesting are there any examples of this around?

[bogax]

Here's a more optimized one I developed:

;14 bytes, 24 cycles
sta tempOne
lsr
adc #4
lsr
lsr
lsr
adc tempOne
ror
lsr
lsr
lsr

 

Excellent! I 'd forgotten all about that.

 

I'm curious, how you derived that.

Did you have some sort of sytematic approach

or was it just sort of by guess and by golly.

(I never did figure out how to make /5 work

past 179 using a similar adjustment)

 

Ought compile a list of such routines somewhere.

Maybe bump the divide by seven thread.

[Omegamatrix]

Hi guys what advantage does the constant positioning routine provide? I assume it will still require two scanlines to complete. The idea of splitting the screen into two sounds interesting are there any examples of this around?

 

Here is an example done by Darrell Spice (SpiceWare). It is for early Hmoves to hide the "Comb Lines", but the same concepts apply of dividing the screen into horizontal sections. Alternatively if you wanted to do two sections then just load the sprite horizontal postion, subtract half the screen from it, and see if you are in the left or right side.

 

 

 

Excellent! I 'd forgotten all about that.

 

I'm curious, how you derived that.

Did you have some sort of sytematic approach

or was it just sort of by guess and by golly.

(I never did figure out how to make /5 work

past 179 using a similar adjustment)

 

Ought compile a list of such routines somewhere.

Maybe bump the divide by seven thread.

 

I use a numerical analysis... of sorts. Nothing fancy like a high order Runge-Kutta method. I usually lay out each step side by side in an excel sheet to see how far each step is deviating from the correct solution, and then try some permutations to correct it.

 

 

After I wrote all those routines in the divide by seven thread, I wanted to find a faster way to test for solutions. I wrote an Atari 2600 program to specifically test a routine over all possible inputs, with a permutation variable. There is a couple of modes. One mode will break at the first fail, the other will change the variable if it doesn't pass, and run through all possible inputs again.

 

 

Anyhow, that is from memory (how the program works). I wrote it a few years back so it's a little fuzzy.

DivideTest.zip

[Mikes360]

Great advice thanks for the information. Seems like their are so many neat tricks out there!