Mikes360 Posted January 23, 2013 Share Posted January 23, 2013 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 Quote Link to comment Share on other sites More sharing options...
Mikes360 Posted January 24, 2013 Author Share Posted January 24, 2013 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 Quote Link to comment Share on other sites More sharing options...
bogax Posted January 25, 2013 Share Posted January 25, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted January 25, 2013 Share Posted January 25, 2013 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. Quote Link to comment Share on other sites More sharing options...
Mikes360 Posted January 25, 2013 Author Share Posted January 25, 2013 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? Quote Link to comment Share on other sites More sharing options...
bogax Posted January 25, 2013 Share Posted January 25, 2013 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. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted January 25, 2013 Share Posted January 25, 2013 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 1 Quote Link to comment Share on other sites More sharing options...
Mikes360 Posted January 29, 2013 Author Share Posted January 29, 2013 Great advice thanks for the information. Seems like their are so many neat tricks out there! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.