[roland p]

Quote

Then we would not have any color left for the other player's ship. So 1 player, its missile and the ball are the way to go here.

Oops. thats right. Another cost reducing feature there ;D

Quote

I thought about a reflected PF, maybe using PF1 and PF2 only. Though I am not sure which solution will be better combinable with smoothing.

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

Quote

Not sure here too. Maybe a combined solution (2 color writes and 4-6 PF writes per scanline).

I should give it a try, it definitly will make the code less butt-ugly then the current.

This post has been edited by roland p: Sun Sep 21, 2008 1:41 PM

[Cybergoth]

Thomas Jentzsch, on Sun Sep 21, 2008 8:23 PM, said:

I found out by now. The other version was done by some people called Crackman Crew.

Just a bunch of lame crackers that broke it while toying with PAL/NTSC conversion. Get the "Remember" crack to see how it's supposed to be

[Thomas Jentzsch]

Cybergoth, on Sun Sep 21, 2008 9:43 PM, said:

Just a bunch of lame crackers that broke it while toying with PAL/NTSC conversion. Get the "Remember" crack to see how it's supposed to be

I got both and they are completely different. Looks like Crackmen Crew tried to make their own version.

[Thomas Jentzsch]

roland p, on Sun Sep 21, 2008 9:38 PM, said:

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.

Can you explain the math behind that? Are you talking about the different possible configurations in each PF row?

I don't think ROM tables will work here, especially when we also consider the higher resolution required for smoothing. So either we calculate on-the-fly inside the kernel or we precalculate into RAM outside.

BTW: The original Atari 5200 game displayes 47 rows for the board. The topmost grid is 16 pixel wide, increasing two pixel each row and using a total screen width of 168 pixel. So in the upmost row, 11 squares are displayed, at the bottom only 2 or 3.

[roland p]

Thomas Jentzsch, on Sun Sep 21, 2008 10:12 PM, said:

roland p, on Sun Sep 21, 2008 9:38 PM, said:

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.

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.

Thomas Jentzsch, on Sun Sep 21, 2008 10:12 PM, said:

I don't think ROM tables will work here, especially when we also consider the higher resolution required for smoothing. So either we calculate on-the-fly inside the kernel or we precalculate into RAM outside.

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...

[Thomas Jentzsch]

roland p, on Sun Sep 21, 2008 10:38 PM, said:

...
I use 6 bytes instead of 5 because of the weird PF0 behaviour.

Understood.

Quote

There are only 128 bytes of RAM right? Or can memory be added?

Currently no boards with additional RAM exist, but there is one in the pipeline. Also one could use the Supercharger, which offers a lot of additional RAM.

Anyway, I would prefer doing the game inside the usual 128 bytes limitation. Especially new boards with more RAM seem like cheating to me. And when using the Supercharger, you cannot make carts.

Quote

I found no way yet to do everything in the kernel, 76 cycles is just not much...

That's part of the fun! Finding the necessary cycles.

[Thomas Jentzsch]

Some further brainstorming:

Original 5200 version: 168x47 pixel board, topmost square 16 pixels wide -> 11 squares horizontally, bottom square 16+(47-1)*2 = 108 pixel wide. 21 squares horizontally in total.

Converted into an Atari 2600 screen with 152 pixel (8 pixel lost due to HMOVE blanks), the topmost square would have to be ~15 pixel wide. Then we would get 11 squares horizonally too. And the bottom square would be maybe 101 pixel wide. And the screen would be 44 pixel tall.

Displaying 11 squares in the topmost row seems almost impossible now. So either we cheat there (so that nobody notices) or we increase the square size.

For cheating, we could split the kernel into 2 (or more) parts, which are drawn differently. E.g. at the very top (~25%), at the left and right corners, we "simulate" the pattern with a combination of repeated objects and PF graphics. And below we switch to a (more) correct representation. So that maybe 10% of the screen are cheated and the other 90% are correct.

Or, if we increase the square size to e.g. 24 pixel (7 squares) for the topmost row. To maintain the same scope from the total game area visible, we would reduce the 21 horizontal squares to e.g. 14 (21*16/24).

[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.

[Thomas Jentzsch]

roland p, on Mon Sep 22, 2008 10:06 PM, said:

I hope you're not upset, I really appriciate you're enthousiasm on the subject.

I am not upset, not at all. Actually I had (and still have!) a lot of fun with this. I hope you don't mind, if I continue working on this too?

BTW: Should I open my own thread for this? That way I won't disturb your project.

[roland p]

Thomas Jentzsch, on Mon Sep 22, 2008 11:05 PM, said:

I am not upset, not at all. Actually I had (and still have!) a lot of fun with this. I hope you don't mind, if I continue working on this too?

No problem! I don't remember having the exclusive rights on homebrewing Ballblazer

Thomas Jentzsch, on Mon Sep 22, 2008 11:05 PM, said:

BTW: Should I open my own thread for this? That way I won't disturb your project.

Well, this isn't actually my thread too. But seperating the two will keep things easier to follow I guess.

[mos6507]

Thomas Jentzsch, on Mon Sep 22, 2008 1:05 PM, said:

BTW: Should I open my own thread for this? That way I won't disturb your project.

You should make your own game called The Nazca Lines.

This post has been edited by mos6507: Mon Sep 22, 2008 10:56 PM

[Thomas Jentzsch]

mos6507, on Tue Sep 23, 2008 6:56 AM, said:

You should make your own game called The Nazca Lines.

Hehe!

[Andrew Davie]

roland p, on Mon Sep 22, 2008 4:19 AM, said:

Hi Thomas,

I think that using 2 missles and 1 ball would make things really smooth.

Quote

a) PF graphics (slightly lower resolution, but easier to handle)

Hi Thomas, how would you do the ceckerboard when using PF graphics? and are the brown borders still possible?

I really think these discussions on higher-resolution grids are kind of unnecessary. I'd rather see work put into making the chequerboard functional, with inertia/acceleration, and put some sprites up for the ship/ball. I truly think the resolution is nice AS IS. In fact, I kind of like the slight chunkiness, it adds character. Better to spend the time making it somewhat playable than fiddling about with arcane techniques for line smoothing. Those sorts of things can come later, IF cycles are available.

My 2c.

[roland p]

Back on track. Changes so far:

- left/right Accelaration is now possible! Be careful, no collision detects yet.
- Increased internal horizontal resolution to 256 pixels per tile. This makes the calculations (acceleration, positions of players etc.) a lot easier. Hint: Try to move slow, it looks very cool.
- Vectors for moving the checkerboard are now calculated on the fly, in the overscan, as it would consume now 1K of rom if precalculated.
- Vectors are pretty accurate now, only a glitch when you cross a tile.

I've the feeling that the checkerboard which runs at 60fps is much faster than the 5200 version, which looks like it runs at 30fps.

Attached File(s)

•  ballblazer.bin (4K)
  Number of downloads: 181

This post has been edited by roland p: Wed Sep 24, 2008 6:24 AM

[Andrew Davie]

roland p, on Wed Sep 24, 2008 10:21 PM, said:

Back on track. Changes so far:

- left/right Accelaration is now possible! Be careful, no collision detects yet.
- Increased internal horizontal resolution to 256 pixels per tile. This makes the calculations (acceleration, positions of players etc.) a lot easier. Hint: Try to move slow, it looks very cool.
- Vectors for moving the checkerboard are now calculated on the fly, in the overscan, as it would consume now 1K of rom if precalculated.
- Vectors are pretty accurate now, only a glitch when you cross a tile.

I've the feeling that the checkerboard which runs at 60fps is much faster than the 5200 version, which looks like it runs at 30fps.

This works as well as I hoped/expected it would. Well done, you've already done a remarkable job. The inertia/acceleration is good. Now it's time to get the checkerboard in, no?

Cheers
A

[roland p]

Andrew Davie, on Wed Sep 24, 2008 2:43 PM, said:

This works as well as I hoped/expected it would. Well done, you've already done a remarkable job. The inertia/acceleration is good. Now it's time to get the checkerboard in, no?

Yes, checkerboard would be nice now. I still have to find a way how to calculate the tiles in the distance.

[Thomas Jentzsch]

Excellent! I also would like to see the checkerboard soon.

But while you are are stuck, how about adding friction? Reduce speed by a constant or speed based (e.g by 1/(2^n) of the current speed). This should be easy to implement and work very well.

[roland p]

Thomas Jentzsch, on Wed Sep 24, 2008 6:50 PM, said:

Excellent! I also would like to see the checkerboard soon.

But while you are are stuck, how about adding friction? Reduce speed by a constant or speed based (e.g by 1/(2^n) of the current speed). This should be easy to implement and work very well.

Nothing has been easy so far
I checked Ballblazer for the 5200 again. It looks like:
- Ship's acceleration is lesser at higher speed, until accelleration reaches 0
- Ship's de-acceleration (Brakes) is very high.
- The friction is lower at low speeds. Ship keeps moving slowly after deacceleration

[Thomas Jentzsch]

roland p, on Wed Sep 24, 2008 10:31 PM, said:

Nothing has been easy so far

Easy as an Atari 2600 category.

Quote

I checked Ballblazer for the 5200 again. It looks like:
- Ship's acceleration is lesser at higher speed, until accelleration reaches 0
- Ship's de-acceleration (Brakes) is very high.
- The friction is lower at low speeds. Ship keeps moving slowly after deacceleration

That sounds like some speed related friction as I described above.

[mos6507]

Thomas Jentzsch, on Wed Sep 24, 2008 8:50 AM, said:

Excellent! I also would like to see the checkerboard soon.

Evne if nothing came of this besides a checkerboard kernel, it would make for an impressive demo along the lines of the Amiga bouncing ball demo. I can't wait.

[roland p]

We now have a checkerboard!

Attached File(s)

•  ballblazer.bin (4K)
  Number of downloads: 184

[TrekMD]

Cool....

[Thomas Jentzsch]

Wow!

[cd-w]

roland p, on Mon Sep 29, 2008 10:03 PM, said:

We now have a checkerboard!

Excellent work - that looks awesome! I'm amazed at what you have been able to accomplish using just playfield colouring and delays.

I notice that the checkerboard actually extends underneath the playfield at the edges (Alt-N in Stella). I don't suppose it would be possible to make it slightly wider?

Chris

[Nathan Strum]

Thomas Jentzsch, on Mon Sep 29, 2008 2:16 PM, said:

Wow!

Indeed!