Jump to content

Photo

DEV: Ballblazer Techniques


31 replies to this topic

#1 tschak909 OFFLINE  

tschak909

    River Patroller

  • 2,347 posts
  • Location:USA

Posted Wed May 24, 2006 2:40 PM

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

#2 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,774 posts
  • Location:Baden-Württemberg, Germany

Posted Wed May 24, 2006 2:52 PM

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

#3 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,774 posts
  • Location:Baden-Württemberg, Germany

Posted Wed May 24, 2006 2:55 PM

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

#4 Bryan OFFLINE  

Bryan

    Quadrunner

  • 10,920 posts
  • Cruise Elroy = 4DB7
  • Location:Chesaning, MI

Posted Wed May 24, 2006 2:57 PM

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

#5 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,347 posts
  • Location:USA

Posted Wed May 24, 2006 2:59 PM

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

#6 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,347 posts
  • Location:USA

Posted Wed May 24, 2006 4:46 PM

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

#7 Almost Rice OFFLINE  

Almost Rice

    River Patroller

  • 2,086 posts
  • Prius rocks
  • Location:Houston

Posted Wed May 24, 2006 8:23 PM

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.

#8 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,627 posts
  • Location:Australia

Posted Wed May 24, 2006 9:03 PM

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

#9 tschak909 OFFLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,347 posts
  • Location:USA

Posted Wed May 24, 2006 10:00 PM

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?

#10 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,627 posts
  • Location:Australia

Posted Thu May 25, 2006 12:07 AM

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.

#11 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,774 posts
  • Location:Baden-Württemberg, Germany

Posted Thu May 25, 2006 2:11 AM

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

#12 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,774 posts
  • Location:Baden-Württemberg, Germany

Posted Thu May 25, 2006 2:15 AM

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

#13 _The Doctor__ ONLINE  

_The Doctor__

    River Patroller

  • 4,017 posts
  • Location:10-0-11-00:02

Posted Thu Jan 11, 2018 2:22 AM

this should all be rolled or discussed in the current ball blazer frame rate thread...

http://atariage.com/...rate/?p=3932418



#14 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,774 posts
  • Location:Baden-Württemberg, Germany

Posted Thu Jan 11, 2018 4:23 AM

thanks... ;) I am getting old that I already had a look into it :D.



#15 _The Doctor__ ONLINE  

_The Doctor__

    River Patroller

  • 4,017 posts
  • Location:10-0-11-00:02

Posted Thu Jan 11, 2018 4:36 AM

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



#16 8Bitjunkie OFFLINE  

8Bitjunkie

    Moonsweeper

  • 329 posts
  • Location:Germany

Posted Fri Jan 12, 2018 9:26 AM

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


Edited by 8Bitjunkie, Fri Jan 12, 2018 9:27 AM.


#17 VladR OFFLINE  

VladR

    Stargunner

  • 1,319 posts
  • Location:Montana

Posted Fri Jan 12, 2018 12:17 PM

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?

#18 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,774 posts
  • Location:Baden-Württemberg, Germany

Posted Fri Jan 12, 2018 2:13 PM

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

#19 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,774 posts
  • Location:Baden-Württemberg, Germany

Posted Fri Jan 12, 2018 2:13 PM

Re NDA does it still apply??? Just courious... under German Law? And isnt Factor 5 no more?

#20 _The Doctor__ ONLINE  

_The Doctor__

    River Patroller

  • 4,017 posts
  • Location:10-0-11-00:02

Posted Fri Jan 12, 2018 3:03 PM

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



#21 VladR OFFLINE  

VladR

    Stargunner

  • 1,319 posts
  • Location:Montana

Posted Sat Jan 13, 2018 8:51 PM

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 ?



#22 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,774 posts
  • Location:Baden-Württemberg, Germany

Posted Sun Jan 14, 2018 1:17 AM

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

#23 bugbiter OFFLINE  

bugbiter

    Moonsweeper

  • 277 posts
  • Location:Stuttgart, Germany

Posted Fri Feb 2, 2018 3:34 PM

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!



#24 bugbiter OFFLINE  

bugbiter

    Moonsweeper

  • 277 posts
  • Location:Stuttgart, Germany

Posted Sun Feb 4, 2018 5:59 AM

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



#25 ivop ONLINE  

ivop

    Dragonstomper

  • 643 posts
  • Location:The Netherlands

Posted Sun Feb 4, 2018 6:41 AM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users