Jump to content
tschak909

DEV: Ballblazer Techniques

Recommended Posts

I have always been curious, ever since I started playing it many years ago, the graphics rendering techniques used in Ballblazer. They really did some nifty DLI techniques. The screen seems to be implemented using the monochrome GTIA mode, but how was the rotofoil perspective rendering done, or the perspective rendering? .... I am going to try disassembling it soon, but I was wondering if someone else has dissected this game.

 

-Thom

Share this post


Link to post
Share on other sites

i would assume simply by looking at the screenshots...

 

antic e + DLIs

antic 4 for the score

player/missles for ball and the ships... nothing special here imho...

 

let us see what atari8winmonitor shows when looking at the dlist

 

antic e which are 256 bytes long scanlines plus hscrol activated for the perspective scrolling... nice...so they used atari specific stuff... ;)

 

and the zooming etc is nicely precalculated and simulated with the x2,x4 sizep0 registers... you can check that by looking at the gtia registers...

 

 

 

i do not know what you mean by monochrome gtia mode...

Share this post


Link to post
Share on other sites

the perspective moving is precalculated animation as the angle of the "checkboard" you are looking at is fix...so you can do the colour changes by DLI or you can have a cycle of prerendered gfx in ram and you move the gfx by changing the dlist...

 

games with this technique... dimension x, trailblazer...rainbow walker and others...

Share this post


Link to post
Share on other sites

I am pretty sure the screen is done completely with dlist tricks. Basically, each line is wider than the screen and is scrolled right or left (by differing amounts on each line to give the perspective), and the color assignments are shifted up and down to simulate forward/reverse movement. I'm guessing it was much easier to do on the Atari than on other platforms.

 

-Bry

Share this post


Link to post
Share on other sites

nice. I'm just trying to get back into the swing of thinking like an atari 8-bit computer :-) and it's starting to come back to me bit by bit...

Share this post


Link to post
Share on other sites

it is worth noting that Ballblazer was done on the Atari FIRST, then ported. (Lucasfilm Games felt that the Atari 800 was the most powerful computer at the time.) :-D

Share this post


Link to post
Share on other sites
it is worth noting that Ballblazer was done on the Atari FIRST, then ported. (Lucasfilm Games felt that the Atari 800 was the most powerful computer at the time.) :-D

 

You won't get any disagreement here. As a user at the time, I always wondered why Apple 2s and C64s were so popular.

  • Like 1

Share this post


Link to post
Share on other sites

It looks like it uses a Kernal within the DLIs. The DLIs occur at the start of each checkerboard.

Share this post


Link to post
Share on other sites

so basically it's doing something like this on each horizontal line?

 

wait for a bit,

set new colour values into registers

wait for a bit longer,

set new colour values into registers...

etc?

Share this post


Link to post
Share on other sites

I haven't looked too deeply into it. It seems to have a table lookup for colours.

 

Each line is offset around 256 from the last... maybe to make the programming easier? The background is a repetitive set of data, they probably could have represented it using a lot less RAM... but chances are it's generated by the program rather than loaded from disk anyway.

Share this post


Link to post
Share on other sites

the colours are not set honrizontal "on the fly" but for each scanline ones...

 

so...you have a table of precalculated ofsets for hscrol and the scanline offsets (remember each scanline is 256 bytes long)

 

so now assume that you have in a prerendered checkboard... now you simply change the colours of the checkboards one scanline earlier... what is happening? you "move" the checkboard...

 

i guess as well that the 256 scanlines (which is 1024 pixel in antic e) are used because the whole playfield in ballblazer is 1024x1024 pixel?

 

and when i started to code trackball (which later become Boinxx) it was a 3d type of game like ballblazer or trailblazer... unfortunatly i lost all source codes when i lost my usb stick on a business tripp... the basic was the same... a prerendered "checkboard" with 3d perspective, a precalculated lookup table for the perspective correct moving of the DLIs and voila...you had a nice moving 3d checkboard done by a simple DLI with less cpu usage... ;)

Share this post


Link to post
Share on other sites

ah...i forgot to mention... you just need to precalculate the movment of one largest checbboard... after that you can simply switch the colours in reverse order and do that moving again... the human eye is so easy to fool and thanks to the maths...

 

what is more interesting in ballblazer is that they used antialising (no... it's not artifacting... ;)) and the zooming of the players and the ball..which i wanted to do for years as well... a nice prerendered sprite data with different zoom status plus combination of the "hardware" zooming of GTIA...

 

so... the they really used great atari specific hardware techniques...so the easiest thing to port on c64 was the soundtrack i guess... ;)

Share this post


Link to post
Share on other sites

thats okay I re discovered not to change the width of the checkerboard....it's as good as it gets....and laughably it's the same thing we've all toyed with before...

 

. I don't remember, I don't recall, I've got no memory, of anything at all.... I'm not that old really.... now if the car keys are in the fridge......

Share this post


Link to post
Share on other sites

Well, the answer is in the sourcecode ;-)

As the person, who done the offical Amiga port ("masterblazer") i do have the full 8bit source code - but i have signed not to show anyone...

and, even worse: unfortunatly for us, the game was developed using cross assembly terchniques on a mainframe with heavy use of a self-written macro assembler. :-(

post-38160-0-18578700-1515770508_thumb.jpg post-38160-0-83373500-1515770509_thumb.jpg post-38160-0-47294300-1515770511_thumb.jpg

Edited by 8Bitjunkie
  • Like 10

Share this post


Link to post
Share on other sites

Well, the answer is in the sourcecode ;-)

 

As the person, who done the offical Amiga port ("masterblazer") i do have the full 8bit source code - but i have signed not to show anyone...

and, even worse: unfortunatly for us, the game was developed using cross assembly terchniques on a mainframe with heavy use of a self-written macro assembler. :-(

 

DSC03204.JPG DSC03205.JPG DSC03206.JPG

I don't want to put you into uncomfortable position, and I presume you signed a fat NDA, but can you at least discuss techniques/ algorithms used?

Share this post


Link to post
Share on other sites

You know I am more interested in the Amiga source for the fractal flight intro ;)

You sure ? Considering the architectural, clock and performance difference between Amiga & 6502, that fractal landscape - while very nice - looks like it could have another ~2 rounds of optimization. I bet, though, there was no time for that stuff during development (never is).

 

That's not the whole source, it'll be fine... lol

I take it you never experienced a young, new lawyer, willing to launch a third world war [over inconsequential nonsense], just to prove his sh*t's worth to the company ?

Share this post


Link to post
Share on other sites

Vladr

 

Its my holly grail... ;)

 

Over the years we collected a lot of information about ROFL but thats another thread...

 

But I am referring to:

 

 

And I already have a complete disassembly of the game in MADS format to play with.... ;)

  • Like 2

Share this post


Link to post
Share on other sites

Well, the answer is in the sourcecode ;-)

 

As the person, who done the offical Amiga port ("masterblazer") i do have the full 8bit source code - but i have signed not to show anyone...

and, even worse: unfortunatly for us, the game was developed using cross assembly terchniques on a mainframe with heavy use of a self-written macro assembler. :-(

 

attachicon.gifDSC03204.JPG attachicon.gifDSC03205.JPG attachicon.gifDSC03206.JPG

Boy, I would read that through all the way!

Share this post


Link to post
Share on other sites

Well, the answer is in the sourcecode ;-)

 

As the person, who done the offical Amiga port ("masterblazer") i do have the full 8bit source code - but i have signed not to show anyone...

and, even worse: unfortunatly for us, the game was developed using cross assembly terchniques on a mainframe with heavy use of a self-written macro assembler. :-(

 

attachicon.gifDSC03204.JPG attachicon.gifDSC03205.JPG attachicon.gifDSC03206.JPG

The filename on the source says graphics.a65

is that a known format? I guess it isn't the A65 Atari assembler..

But surely it should be possible for us to translate that Lucasfilm code into a usable assembler format??

Share this post


Link to post
Share on other sites

The filename on the source says graphics.a65

is that a known format? I guess it isn't the A65 Atari assembler..

But surely it should be possible for us to translate that Lucasfilm code into a usable assembler format??

 

It looks a lot like lisp.

Share this post


Link to post
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...