Anyone think Ballblazer is possible on the 2600?

[roland p]

Is this still being worked on? I'd like an update, please, this looks like the best homebrew graphics on the 2600 so far.

 

I'll hope to be able to post an update soon. Next updates will be real 51x21 (or whatever size) checkerboard, collision detection, brakes and deaccelleration. While doing this I hope my subconscious figures out how to map the opponent player on the checkerboard

 

What do you guys think of the following?:

Now I use a velocityX and veloctyY component for indicating speed/direction. Should I use an angle and a speed component indicating speed/direction? That would make more sense because I can freely adjust the speed (for like deaccalleration of players/ball) without affecting the direction.

 

With the velocityX,velocityY method, the maximum speed will be achieved when going in diagonal direction, which is strange. It would be something like 256 x √2

[Thomas Jentzsch]

What do you guys think of the following?:

Now I use a velocityX and veloctyY component for indicating speed/direction. Should I use an angle and a speed component indicating speed/direction? That would make more sense because I can freely adjust the speed (for like deaccalleration of players/ball) without affecting the direction.

 

With the velocityX,velocityY method, the maximum speed will be achieved when going in diagonal direction, which is strange. It would be something like 256 x √2

i am not 100% sure about the physics of the original game. Can players and ball go diagonal. Then both should use the same algorithm.

 

You can limit speed by introducing friction. Maybe you calculate friction combined on both directions, so that diagonal doesn't become faster than vertical or horizontal. Else angle and speed sounds like a good idea.

[Rybags]

I'm not sure how many velocities the original has, or if it's done in an (almost) infinitely variable kind of way by using fractional integer additions.

 

How about a kind of 2 dimensional array which contains all possible X/Y velocity values?

 

Then you can hard-code it such that the resultant angles/speed correpsond such that you don't have that situation you described, where a 45 degree angle of motion would be faster than a 0 or 90 degree angle of motion.

[roland p]

Thanks for your input.

 

I'm using signed 16-bit values now so speed can be +/-32768. Small errors will be unnoticable.

 

Imagine the ships has 4 engines for 4 directions, then the maximum diagonal speed is OK

 

The only problem is to assure that the friction is in exactly the opposite direction of the ship...

[Rybags]

For friction, couldn't you just divide the velocity for each axis by some constant, then subtract it?

 

e.g. shift the high byte right twice, then subtract that from the overall velocity.

[roland p]

For friction, couldn't you just divide the velocity for each axis by some constant, then subtract it?

 

e.g. shift the high byte right twice, then subtract that from the overall velocity.

 

I'll try that.

 

When max velocity is 8192 (high byte is 32 then, so ship moves 32 pixels every frame (one tile is 256 pixels)) and I substract it every frame with velocity/64 the ship will be fully deaccelerated within 367 frames.

[Thomas Jentzsch]

For friction, couldn't you just divide the velocity for each axis by some constant, then subtract it?

 

e.g. shift the high byte right twice, then subtract that from the overall velocity.

Yup, that's exactly how I am doing in my games too. Works pretty nicely.

[jbanes]

Let me just interject that I think this work is incredible! Way to go guys! Especially you roland, and you ZylonBane for getting the music ball rolling. (Random Terrain's last version sounds damn near perfect!)

[roland p]

Let me just interject that I think this work is incredible! Way to go guys! Especially you roland, and you ZylonBane for getting the music ball rolling. (Random Terrain's last version sounds damn near perfect!)

Thanks,

 

Yeah the music is really great, I had to play the original to here the differences!

 

@ZylonBane, Random Terrain, thegoldenband

Great work!

I forgot to thank you. Shame on me

As I completely suck at creating music, I really appriciate the work.

 

I think I first have to add some backswitching before I can include it. I still use a pathetic 4KB of ROM. Is there any assembly code for the music?

[+thegoldenband]

Thanks, roland! Here's the assembly code for my final version (aka "alt7"), which has all the pitches in place but doesn't include Random Terrain's changes:

ballblazer_start_zylon_goldenband_final.asm.txt

Obviously there's a great deal that can be cut -- this is just the raw output from bB. I don't have the .bas for Random Terrain's version handy, but I could compile it tonight if he doesn't upload it first.

Edited November 14, 2008 by thegoldenband

[+Random Terrain]

I don't have the .bas for Random Terrain's version handy, but I could compile it tonight if he doesn't upload it first.

I posted the .bin file and the .bas file:

 

http://www.atariage.com/forums/index.php?s...t&p=1615377

[+thegoldenband]

I don't have the .bas for Random Terrain's version handy, but I could compile it tonight if he doesn't upload it first.

I posted the .bin file and the .bas file:

 

Sorry, I should've been more precise -- "I don't have the .bas for Random Terrain's version handy" really meant "I don't have time right now to find and download the .bas, coax bB (which is occasionally flaky on my system) into working, and compile and upload the .asm". I already had the .asm handy for mine, so...

Edited November 14, 2008 by thegoldenband

[+Random Terrain]

I don't have the .bas for Random Terrain's version handy, but I could compile it tonight if he doesn't upload it first.

I posted the .bin file and the .bas file:

 

Sorry, I should've been more precise -- "I don't have the .bas for Random Terrain's version handy" really meant "I don't have time right now to find and download the .bas, coax bB (which is occasionally flaky on my system) into working, and compile and upload the .asm". I already had the .asm handy for mine, so...

Oh, OK. Thanks. I have the .asm file for my version. I can post it right now:

 

ballblazer_start_zylon_alt_2008y_11m_04d_0426t.txt

[vdub_bobby]

I think the ball can only move in 4 directions; no diagonals.

 

The ships can move in any direction.

[roland p]

Hi all,

 

I was working on the border-collision-detection and discovered some bad design choices that I have to fix first. It does bounce at one border, but ship stops when it bounces at low speed (while there is no friction implemented yet). Ships moves easier in the left direction then in the right direction too. That's because I treat the high byte of a signed 2 byte value as the velocity, which is wrong.

 

So I'm going to increase the precision of ships position so I can use the full 2-byte speed. This allows better behaviour at low speeds too.

 

Roland.

[Thomas Jentzsch]

That's because I treat the high byte of a signed 2 byte value as the velocity, which is wrong.

As long as you use 16 bit signed integers and treat the high byte as 8 bit signed integer too, everthing should be fine. Even for friction you can use signed values, just make sure that you keep the highest bit constant when shifting right.

 

Or where is your problem?

[roland p]

Or where is your problem?

 

When speed is 0001 nothing goes on because I only use the high byte, which is 00 in that case. Ship starts moving when speed is 0100. When speed is FFFF (-0001) ship will move left because the high byte is FF. So +1 is does not do the same as -1.

 

But I could increase the value with 1 if it is negative. A bit ugly.

 

Anyway, the position of the player (posX, posZ) is now stored in 16 bit values. The high byte counts as a tile, the low byte is 1/256th of a tile. I find the lowest speed (1/256 tile per frame, so about 4 seconds to scroll 1 tile further) a bit too high.

 

 

So, increasing precision of the position (3 bytes instead of 2) whould solve both problems.

[Thomas Jentzsch]

When speed is 0001 nothing goes on because I only use the high byte, which is 00 in that case. Ship starts moving when speed is 0100. When speed is FFFF (-0001) ship will move left because the high byte is FF. So +1 is does not do the same as -1.

 

But I could increase the value with 1 if it is negative. A bit ugly.

Understood. I think correct rounding would be adding $80 to the lower byte.

 

Anyway, the position of the player (posX, posZ) is now stored in 16 bit values. The high byte counts as a tile, the low byte is 1/256th of a tile. I find the lowest speed (1/256 tile per frame, so about 4 seconds to scroll 1 tile further) a bit too high.

 

So, increasing precision of the position (3 bytes instead of 2) whould solve both problems.

Or adding the speed not every frame.

[roland p]

When speed is 0001 nothing goes on because I only use the high byte, which is 00 in that case. Ship starts moving when speed is 0100. When speed is FFFF (-0001) ship will move left because the high byte is FF. So +1 is does not do the same as -1.

 

But I could increase the value with 1 if it is negative. A bit ugly.

Understood. I think correct rounding would be adding $80 to the lower byte.

 

Ok, Nice, I'll try that!

[roland p]

Added some collision detection now. Ship bounces back when a border is hit.

There are some glitches but it works pretty well.

Left, right and top borders are implemented now for top player.

Edited November 25, 2008 by roland p

[Impaler_26]

Added some collision detection now. Ship bounces back when a border is hit.

There are some glitches but it works pretty well.

Left, right and top borders are implemented now for top player.

Something is wrong here, the .bin is only 3.5K instead of 4K and doesn't work!

[roland p]

Added some collision detection now. Ship bounces back when a border is hit.

There are some glitches but it works pretty well.

Left, right and top borders are implemented now for top player.

Something is wrong here, the .bin is only 3.5K instead of 4K and doesn't work!

 

woops!

I'll try again.

ballblazer.bin

[mos6507]

It still seems like the maximum speed of your guy is too high. It really gets blindingly fast and uncontrollable.

Edited November 25, 2008 by mos6507

[roland p]

It still seems like the maximum speed of your guy is too high. It really gets blindingly fast and uncontrollable.

 

Yep, there is still a list of things to do:

 

- maximum speed

- friction

- brakes

- non-linear acceleration?

 

But I'm really getting out of ROM space. Lots of code is generated with macro's. Is it OK to change some macro's into subroutines, push some variables to the stack and call the subroutines with JSR?

Brown-border Kernel is now unrolled (the code that generates the brown border when you approach the top). I could turn it into a loop, but then I need precise entry points (the whole thing is based on clockcycles) in the checkerboard kernel.

Or just go for bankswitching... I think I have to focus on that one.

[Ben_Larson]

But I'm really getting out of ROM space. Lots of code is generated with macro's. Is it OK to change some macro's into subroutines, push some variables to the stack and call the subroutines with JSR?

In general there's nothing wrong with changing macros into subroutines...except that it will eat CPU cycles due to the JSR/RTSes and the pushes and pops.

 

Here's a document that shows how to do f8 bankswitching:

 

http://www.qotile.net/minidig/docs/2600_ad..._prog_guide.txt

 

It's not too hard...partitioning the code is really the hardest part.

 

Ben