roland p

Thomas, I think I'll stay with the 'change the background on the fly' method. It's the only thing that works at the moment. it does checkerboard+brown borders + possibly upgradable to antialiassing. It just takes too much time to start all over again (I'm just a beginner, I've to lookup every opcode/register/dasm feature). Please feel free to experiment yourself. I hope you're not upset, I really appriciate you're enthousiasm on the subject. Roland.

That's because your demo is looking pretty advanced. Thanks!

Can you explain the math behind that? Are you talking about the different possible configurations in each PF row? Yes. Assume the first line has 4 pixels on and 4 pixels of. If you want to store all versions of the line, you would first need 4 versions: 1111000011110000111100001111000011110000 (0) 0111100001111000011110000111100001111000 (1) 0011110000111100001111000011110000111100 (2) 0001111000011110000111100001111000011110 (3) When the playfield is scrolled, the following lines will be displayed: 0 1 2 3 and then with colors inverted again: 0 1 2 3 and then repeat the sequence. I use 6 bytes instead of 5 because of the weird PF0 behaviour. There are only 128 bytes of RAM right? Or can memory be added? I found no way yet to do everything in the kernel, 76 cycles is just not much...

What? Ballblazer isn't finished yet? You suck! Thanks, I'll fix it

Oops. thats right. Another cost reducing feature there ;D I thought about using asymmetric playfield. The grid could be stored into tables. I could use 6 bytes per line for: PF0,PF1,PF2,PF0,PF1,PF2. For storing every version for a line like 11110000111100001111 etc. I would need 4x6 bytes (for 11110000... 011110000... 001111... etc.), flip colors for more versions. for a 20 line grid I need 4x6 + 5x6 + 6x6 .... + 24x6 = 1764 bytes so that would be doable. code could look like LDX OFFSET_LINE0;2 LDA LINE0,X;4 STA PF0;3 INX;2 LDA LINE0,X;4 STA PF1;3 INX;2 LDA LINE0,X;4 STA PF2;3 INX;2 LDA LINE0,X;4 STA PF0;3 INX;2 LDA LINE0,X;4 STA PF1;3 INX;2 LDA LINE0,X;4 STA PF2;3 52 cycles I should give it a try, it definitly will make the code less butt-ugly then the current.

I found the feedback on my first attempts on Ballblazer very positive, so I don't see that problem, at least not on this forum. I hope I can finish the game someday...

Hi Thomas, I think that using 2 missles and 1 ball would make things really smooth. Hi Thomas, how would you do the ceckerboard when using PF graphics? and are the brown borders still possible?

Noone mentioned the blackborders yet . They where needed because the engine got a bit more complicated in order to do something else than just creating a infinite checkerboard. I thought about games like trailblazer. A friend of mine made a spinoff in java:http://www.gagaplay.com/hypblazer/index.html This is indeed a sort of Mode 7 thing. all the tiles can have a unique colors, so it is texture mapped in a rough kind of way. I might add the antialias afterwards. That's looks cool. I did not know basic could be that clever. I want to do the same thing, but first I want to figure out how the math is, so I can do it 'right'. cd-w posted something similar to0. That's what it looks like. I also saw antialiassing between green and brown tiles when you move forward to the border ahead of you. It looks really clever! I've also found a Ballblazer page: http://www.langston.com/LFGames/ Thanks! The speed can be adjusted as Thomas mentioned. The screenupdating is now 60 fps, but it moves in small steps right now.

Small update, there are brown borders left and right! Scroll to the right and you will see. The checkerboard is now 21 tiles wide, just like real ballblazer. I still have to work on complete tiles. ballblazer.bin

Thanx, The checkerboard that I posted a few posts ago, is not the one I'm going to use (Edit, I ment the bin, not the source). It's not possible to create the brown boundaries with that one. The one I use now can do create the boundaries, at the expense of a slightly smaller screen (black borders left/right). I'm now working on the checkerboard and calculations for odd/even tiles. The checkerboard isn't really a playfield but just a routine that alters the backgroundcolor, when scrolling is needed, the routine just waits for one cycle at that line and the rest that follows is scrolled 1 cycle (3 colorclocks). It's even possible to create multicolored tiles, but I won't do that since the original ballblazer hasn't. Using sprites is not possible, because moving sprites requires a WSYNC which makes my method unusable, unfornunatly. I've just discovered that only one sprite at the time is displayed over the checkerboard in the original version. This sort of solves my sprite problem.

I'm no Batari basic programmer, but maybe you could do: x=5+curroom gamemap[x] This probably doesn't make it prettier... BTW. Your game looks very nice!

Doesn't that take more cycles then: ? I've attached my source, so you can see what problems I am going through At line 240 to 287 there are some precalulations of the checkerboard At line 370 the first tile of the checkerboard is drawn, data is taken from ram (fastest) At line 508 I have enough time to get the tile data from rom Between every line you will see SLEEP ... for eating cycles, these can be replaced by sprite-code. At line 1656 you will see PLAYFIELD_DATA for the tiles. The brown tiles will be stored here. (they are all green at this moment) main_bitmapped.zip

Yes, 4 line resolution. The data is zero-page memory and should be filled with the correct value. I precalculate everything. It varies. about 5 to 10 cycles with the current method, very small, but the checkerboard is very cool with >2 colors so I want to keep it.

Ever heard of "K.I.S.S"? Do you mean my way of exmplaning things, or my way of getting ballblazer on the 2600?

I've (hope) just enough time to update 1 sprite/line. And I have 4 sprites to draw. so the kernel could look like this: at line 1 update sprite 1 with data1 at line 2 update sprite 2 with data2 at line 3 update missle with data3 at line 4 update ball with data4 ... ... at line 37 update sprite 1 with data37 at line 38 update sprite 2 with data38 at line 39 update missle with data39 at line 40 update ball with data40 etc. (data1..40 is memory) That could work, but will look funny. because every sprite is drawn on another line. By using pointers, I could change on wich line wich sprite is updated, that would look like this: at line 1 update @pointerA with data1 at line 2 update @pointerB with data2 at line 3 update @pointerC with data3 at line 4 update @pointerD with data4 PointerA would point to sprite 1 at frame 1, and to sprite 2 at frame 2 etc. I hope I'm clear.

Crap! That solved the problem! Thanks! Funny that 'GRP0' does work. Probably the value $1B is stored at that adres?

@vdub_bobby, I get to the backswitching later. I have fixed the issue now by altering some 'org' declarations. Due to extremely short spare time in the checkerboard edges, I've not enough time/memory to update all sprites every line. Therefore I thought of the following: update everyline one sprite, giving a vertical resolution of 4 pixels per sprite, and change the update pattern every frame to get a interlaced like effect. Unfortunatly, it does not work. Can anyone tell me why the following code does not work? LDA GRP1 STA SPRITE_POINTERA LDX #0 LDA #%10101010 STA (SPRITE_POINTERA,X) And why the following code DOES work? LDA GRP0 STA SPRITE_POINTERA LDX #0 LDA #%10101010 STA (SPRITE_POINTERA,X) Maybe I'm doing something very stupid and it is not possible at all...

Wow this is definitly the most hilaric version of jumpman ever! Brilliant!

I got Pacman, my sister got Donkey Kong, and my mum got Frogger

Just some obstacles to jump on/over would be a nice start. Is jumpman aka mario from 8-bit Donkey Kong in the same resolution? Maybe you can copy just that one. The source is also available

Hi there, My 4K is reaching its limits. The code for drawing the lines is a bit big because it's completely based on processor cycles. And besides the code, I use some tables for the horizontal movement wich occupies 207 bytes. The sinus table for vertical movement (which is needed to complete the tiles) is another 69 bytes. This results in >4K of ROM. Now I've tried to calculate the vector in real time to save those 207 bytes. This is possible and takes now about 700 cycles. That's cool, but I'll get into memory problems anway. So what I want to do is: 1. Ditch the vector routine, nothing beats LDA OFFSET_DATA_0_7,X. Don't fix anything that's not broken 2. Add some bankswitching Is this the way to go? When I do bankswitching, I would want to go for the full 32K. What's the best way to do that? Btw. I've downloaded a 6502 simulator to test small parts of code: http://home.pacbell.net/michal_k/6502.html You can exactly see what is going on. Really nice!

Only this would improve things: http://www.ultimarc.com/avgainf.html But not speed-wise. You can connect original arcade monitors to it which is very cool.

Ok, I'll stick to the useful stuff

I've now used a 2 pixel offset every other frame. It looks not bad. I've to change my tables a bit to make it look even better, but now you have REAL antialiassing! ballblazer.bin

mmmh... interesting. by increasing/decreasing horizontal movement by a pixel every other frame. Maybe that looks nice. I've seen in the atari 5200 version that there is a sort of antialiassing in the vertical direction, the 2600 should be able to do that too.