Jump to content
IGNORED

Anyone think Ballblazer is possible on the 2600?


Recommended Posts

Cool! :thumbsup:

 

I implemented the same masking for Chun Li as well. Works great for single sized sprites, and while it looked odd at first for double and quad sprites, it is much better than the wrap-around graphics or having sprites disappear as soon as they touch the edge of the screen.

Chun Li? Can I download that somewhere? :)

 

 

This is cool. I'm pretty sure there's not enough raster time left for this, but maybe you might use the M0/M1 to overlap the 0..3 clipped pixels at position 0.33 and 156..159. This would work at least in case there is no transparent area inside the rotofoil.

I want to use M0 and M1 for the goal-beams, so this would only be possible when the goals are not visible.

 

I decided not to keep it the way it is now, remove the glitches and improve the speed so I can get the goalbeams in.

 

The current code takes about 660 cycles, so enough left for the other objects I think/hope since I expect the rotofoil to be the hardest...

Edited by roland p
Link to comment
Share on other sites

I implemented the same masking for Chun Li as well. Works great for single sized sprites, and while it looked odd at first for double and quad sprites, it is much better than the wrap-around graphics or having sprites disappear as soon as they touch the edge of the screen.

Chun Li? Can I download that somewhere? :)

Not yet. That's a code name for an as-yet unannounced homebrew Darrell's working on.

Link to comment
Share on other sites

Chun Li? Can I download that somewhere? :)

Not yet. That's a code name for an as-yet unannounced homebrew Darrell's working on.

I jumped forward in time, recorded some video of it and brought it back so you guys could have a preview:

 

http://www.youtube.com/watch?v=CX8jdKNO4t8&rel=0&fmt=35&showinfo=0&start=10

Link to comment
Share on other sites

I just read all 30 pages worth of this, and I have to say... I am utterly blown away.

 

Not just by the game itself, but just by watching this entire thing unfold.

 

It starts off with some guy wondering if something is possible. Another curious fellow nods, scratches his chin, and tries it.

 

Said individual gets addicted to his finding that he otherwise would have never tried, and with his basic knowledge of the language at the time becomes a legend over time.

 

Then you got tons of people coming in and making suggestions and all showing their support towards a project wanting to see the end result, and responding in a really cheerful manner when progress is made on a project thought to be impossible..

 

Just the history behind the creation of this work in progress is amazing, and I absolutely love reading all about this project. It's also INCREDIBLY fun to pop every updated ROM into my emulator and watch the game unfold step by step into an end result.

 

 

So on that note, I'll add my own input on this project: This is looking absolutely fantastic, and I really really anticipate seeing the end result. I am VERY excited, and congratulations on your accomplishments. You are awesome, and definitely have inspired me GREATLY just from this to get back into learning how to code for this thing.

 

I am very happy. Thank you.

Edited by Yart
  • Like 3
Link to comment
Share on other sites

Yart,

 

Thank you for your kind words. It's the nice atariage community that kept me going, the beauty of the 2600, and ofcourse the fun of trying to code it. Sometimes I slow down, but they have endless patience as it seems (3 years now) :)

 

Sometimes I look back at the first pages of this thread and I laugh a bit at the sub-optimal solutions I invented :D

Link to comment
Share on other sites

  • 3 weeks later...
  • 3 weeks later...

The 64 version just feels klunky- probably because it's done with characters instead of sliding scan lines.

Some trivia about C64 ballblazer, programmed by Chuck Sommerville, who did Chip's challenge for the Atari Lynx:

Dear C=Hacking,

 

I wrote a few games for the C64 a while back. Reading your stuff about the

C64 brought back some fond memories. I thought I pushed that machine to

its limits back when I worked for EPYX. I see There was still some room to

do some other wierd stuff. The worst this I ever did was the raster code

for Ball Blazer, which had to figure out whether there were 63, 64, or 65

cycles on the scan line, and run 8 different pieces of interrupt code

depending on how close to the 40 lost cycles it was. The problem was that

I had to write to 2 color registers on two consecutive lines. This is a

problem if you have to do it on the bad line. I had to get the timing down

to the cycle, syncronized by a timer tuned to the horizontal rate. It

actually had to lose the 40 cycles in the middle of a particular

instruction. You should have seen the jury rigged logic analyser we built

to see the timing!

 

Well, I probably don't have time to read all the back issues of C= hacking,

but it is fun to see this is still a topic of discussion.

 

Sincerely,

 

Chuck Sommerville.

 

(I have no idea what he is talking about! :? )

Link to comment
Share on other sites

Some trivia about C64 ballblazer, programmed by Chuck Sommerville, who did Chip's challenge for the Atari Lynx:

Dear C=Hacking,

... section removed for space ...

Sincerely,

Chuck Sommerville.

(I have no idea what he is talking about! :? )

To have an idea what he is talking about... well, when you are finished Ballblazer. ;-) Go check out this talk. http://www.pagetable.com/?p=53 There is a video somewhere there as well. Ah just go check it out. Also the 6502 talk http://www.pagetable.com/?p=517

Edited by djmips
Link to comment
Share on other sites

  • 3 weeks later...

Hi,

it is about special timings on C64.

There are three (pal, ntsc, other ntsc) versions with different number of cpu cycles per rasterline (63,64,65).

Every 8th rasterline is a so-called badline in which the VIC (gfx chip) halts the CPU to fetch char (=bitmap) and/or sprite data.

The cpu is stun for 40-43 cycles. PLUS the rest of the cycles of the opcode that was being executed during badline start which are 0-7 cycles.

So everything becomes much less predictable than for vcs 2600.

Also there is no such thing as WSYNC for C64 unfortunately.

Without modern emulators/equipment/knowledge, Ballblazer must have been a real pain ;-)

Much of this information was not available at the time.

But well, same for vcs considering strange timings/behavior.

I did quite some coding for the C64 and diving into VCS 2600 now.

Working on a little demo - we shall see if it finds its way into public some day.

The so far Ballblazer engine really impresses me!

Please continue.

I can imagine that it will be very hard to implement a proper AI and gameplay?

But as I understand you (had to) use an enhanced cart-format already?

Cheers,

enthusi

  • Like 1
Link to comment
Share on other sites

  • 1 month later...
The so far Ballblazer engine really impresses me!

Please continue.

I can imagine that it will be very hard to implement a proper AI and gameplay?

Thanks,

 

About the game logic, I wanted to run that code during the overscan area, but since this new version uses more screen real estate and less overscan, the overscan area doesn't have enough time to run the game logic. (current version makes the tv screen roll when you hit the border).

Then there is the vblank, which contains some more space for the cpu. But I'm going to need that for calculating where the rotofoils/goalbeams/plasmorb have to be displayed...

 

So I have to pick one or more of the folloowing optimisations:

- reduce gamelogic (which makes movement of the rotofoil probably less natural)

- reduce updates of one or more of the objects (rotofoil etc.) to 30fps.

- reduce all updates to 30fps. So gamelogic runs during one frame, the screen-setup during the other frame.

 

But as I understand you (had to) use an enhanced cart-format already?

It's now 32Kb + superchip memory.

 

I a ARM approach with the harmony card could prorably solve the cpu-time problems, but that somehow feels (altough it's probably not easy too) like cheating to me...

Finding a way to deal with the vcs' limitations is a part of the fun too.

  • Like 1
Link to comment
Share on other sites

I now use 650 cycles, I think there area about 2700/2800 so that's about 25%.

This is used for the rotofoil. determining its place on the screen, and masking it out when it hits the borders.

The rotofoil should be calculated once, if it's shown on both viewports, its position will be the same! :)

 

The most time consuming part is the calculation of the 2d coordinates. That uses about 400 cycles.

 

There are 2 goalbeams and 1 plasborm for each screen.

So 6 more objects to calculate...

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...