BallBlazer framerate

[emkay]

Ouch! I like you emkay, but you're busting my balls twice in a row now for the same post?

I was just curious.

As the definition points to some "easy" thingy for everyone.

 

How about this definition:

 

The Chessboard is build upon a line depending blitting engine. Every line is stored in Memory. The pointer is set so the position of the depending vertical position, rotating the value till the edge of the field is reached. Line by line.

To have the chessboard look, in ranges, the color of two playfield colors get swapped.

The 3D effect is a result of the used line , pointer setting per line and used pre shifted graphics data for that line.

[IronWorks]

I would`nt use the term "blitting engine" as no memory gets moved. It`s just Horizontally scrolled.

[emkay]

I would`nt use the term "blitting engine" as no memory gets moved. It`s just Horizontally scrolled.

If you're doing "just scrolling", you don't get the iso 3d effect.

 

[Heaven/TQA]

Emkay...

 

Ironworks means that not 1 scanline gets "moved" by "blitting". it's scrolled by hardware. Blitting in computer terms means "copy/paste data from source a to source b" which does not happen.

 

in my turbo basic example I am "blitting" as my TB code "blits" a each line to screen from memory. BB does no copy.

 

TB: move texture+scanline*256+xpos,dpeek(88)+scanline*40,40

[Heaven/TQA]

as my Altirra screenshot showed

 

the display list shows

 

$de,texture+line1*256+xoffset1

$de,texture+line2*256+xoffset1

$de,texture+line3*256+xoffset2

$de,texture+line4*256+xoffset3

$de,texture+line5*256+xoffset5

 

and BB sets in VBL those xoffsets based on that "speed" of that particular scanline.

...

Edited January 19, 2018 by Heaven/TQA

[jmccorm]

> If you're doing "just scrolling", you don't get the iso 3d effect.

 

You're missing the trick! I should record a video for you.

 

1. Pick a stripe in the middle that gives a good vanishing point perspective (isometric 3d effect).

2. Scroll over just that one stripe. Ballblazer does not scroll over what we perceive as the entire playfield (as shown in the video). It just repeats the same single stripe, over and over.

3. When you reach the edge of your stripe, jump back to the beginning of that stripe, and reverse the colors. If you do this correctly, and swap colors, it will give the illusion that you're moving from one stripe and onto an opposite-colored stripe.

4. Continue to scroll through the stripe as described in #2.

 

You are constantly "in the middle".

 

VIDEO:

bb-mid.mp4

 

Drawn pixels fill most of the the screen, and are in grayscale. Color changes (via DLIs) are represented on the left.

 

...aaaaaand, as it turns out, there is an edge case [figuratively and literally]. I don't know how I managed to miss it earlier.

 

When you approach the edge, starting in the distance and working towards the player, it is drawing squares (with pixels) on the playfield. But I'm having trouble figuring out why. At first, I latched onto your topic of preserving an isometric perspective, but they don't seem to be using it to change the perspective -- the perspective lines look like they same. Perhaps someone can help me understand why they're carving out boxes with actual pixels, in addition to the DLIs? (And are they changing the anti-aliasing, while they're at it?)

 

PLAYFIELD EDGE VIDEO:

bb-edge.mp4

 

In this video, we start out with Player 1 mid-playfield and Player 2 near the edge. The perspective lines appear identical, but Player 2 has squares painted on the playfield (and colors changed in the display list). As you move away from the edge (as Player 2), the drawn boxes go away, starting with the ones closes to the player. All boxes are removed and we just have stripes when the player is away from the edge (but still far away from the center). As the player moves back towards the edge, the boxes are redrawn from far to near.

 

Why did they actually draw the pixels? They don't seem to change what they were doing with just DLIs, or what they could do with DLIs. I don't see them using it to alter the perspective, but are they? Is this just deprecated code that they forgot to remove? [EDIT: Oh! This may be necessary, in part, to correctly render the background color with the edge of the playfield!]

 

EDIT: If the jumps in the video make it hard to follow, concentrate on the dark stripe portion in the middle. This shouldn't be a bad recording. The on-screen pixels are literally scrolling through the same stripe and jumping back to its beginning, over and over. Color swapping gives the illusion that the player is moving through multiple sections.

Edited January 19, 2018 by jmccorm

[emkay]

Emkay...

 

Ironworks means that not 1 scanline gets "moved" by "blitting". it's scrolled by hardware. Blitting in computer terms means "copy/paste data from source a to source b" which does not happen.

 

 

Copy RAM bytewise to ANTIC RAM/Buffer plus bit shifting for the display.

 

 

 

hehe... so you do blitting by the CPU for some "easy" just scrolling effect

[Heaven/TQA]

we call such thing "smoke and mirror"

[Heaven/TQA]

 

Emkay...

 

Ironworks means that not 1 scanline gets "moved" by "blitting". it's scrolled by hardware. Blitting in computer terms means "copy/paste data from source a to source b" which does not happen.

 

 

Copy RAM bytewise to ANTIC RAM/Buffer plus bit shifting for the display.

 

 

 

hehe... so you do blitting by the CPU for some "easy" just scrolling effect

 

 

sure because it was the fastest thing before I build a proper "proto" ... and my aim was to show the "unaltered" texture in memory...

[emkay]

You're missing the trick! I should record a video for you.

Thanks for you post, but...

 

No, I don't miss the "trick". I know, the field is cycling, and as I wrote above, it ends when the field ends.

 

What you still seem to miss is the focal point of the depth lines. They move in a 3D correct field of depth. In a normal scrolling, you get a parallax effect in the best cause.

You only get that effect , if every scanline of the field has it's own related speed , to get the depth lines always aligned correctly.

[jmccorm]

Thanks for you post, but...

 

No, I don't miss the "trick". I know, the field is cycling, and as I wrote above, it ends when the field ends.

 

What you still seem to miss is the focal point of the depth lines. They move in a 3D correct field of depth. In a normal scrolling, you get a parallax effect in the best cause.

You only get that effect , if every scanline of the field has it's own related speed , to get the depth lines always aligned correctly.

 

I think there is a language barrier? I'm just not following.

 

If we're talking about the game Ballblazer, the game is repeating the same mid-playfield stripe (and its perspective) over-and-over and not changing the focal point (vanishing point) of the perspective. If you are talking about correct or ideal, that's fine and I don't have an argument either way. I'm just concentrating on describing what Ballblazer is doing.

[emkay]

If we're talking about the game Ballblazer, the game is repeating the same mid-playfield stripe (and its perspective) over-and-over and not changing the focal point (vanishing point) of the perspective.

Which is NOT possible with just scrolling. The game needs to change the screen content.

And, YES it is done, using the "scrolling defined" feature of the Atari, but in that case no one could name it "just easy horizontal scrolling" . The term is wrong , and programming starters will get it wrong in a result.

[jmccorm]

Which is NOT possible with just scrolling. The game needs to change the screen content.

And, YES it is done, using the "scrolling defined" feature of the Atari, but in that case no one could name it "just easy horizontal scrolling" . The term is wrong , and programming starters will get it wrong in a result.

 

Here's what I originally said:

 

Related, here is Altirra's representation of the display colors and the pixels for an active game of Ballblazer.

 

The playfield is painted with pixels of three colors (area color 0, border line color, area color 1).

The playfield is only striped in one direction.

Moving forward/backwards is complete display list color work, and the screen pixels are not repainted/redrawn.

Moving left/right looks like horizontal scrolling plus display list dark/light color swapping (to save on stored image space).

 

Super easy for those sneaky Lucasfilm guys.

 

Ballblazer's technique is more than just horizontal scrolling. I think that we agree. If not, then at this point, anyone who carefully reads this thread should be painfully aware of this.

[Heaven/TQA]

I am confused... we all know how B.B. does the fake fx.

 

Its the same fake later Street Fighter 2 floor did.

 

The depths is baked into the texture (wide angle shot). And depths is done again by baking the depths in the gfx.

 

And to get the right impression of movement in z the color cycling is done correct and in x, too (by changing speed of scrolling by scanline).

[Heaven/TQA]

http://www.extentofthejam.com/pseudo/

[emkay]

Moving left/right looks like horizontal scrolling plus display list dark/light color swapping (to save on stored image space).

It is actually a complex routine by software to handle the "scrolling" line by line" . It's not like in much bigger machines with Megabytes of RAM where just a field of graphics could be re-rolled. It's just a 4K machine and the package has only 22K ...

 

Ballblazer's technique is more than just horizontal scrolling. I think that we agree. If not, then at this point, anyone who carefully reads this thread should be painfully aware of this.

They managed at least to have that clean animated "ISO 3D" looking field with the Anti-Aliasing effect . Running smooth and professional.

And, well, it's a game, released back in the 80s .... and so on.

[roland p]

It is actually a complex routine by software to handle the "scrolling" line by line" . It's not like in much bigger machines with Megabytes of RAM where just a field of graphics could be re-rolled. It's just a 4K machine and the package has only 22K ...

 

 

I can't believe that, the horizontal scrolling / skewing of the playfield can be done with a simple Bresenham like I did. It's like drawing one line with a certain angle.

[Kr0tki]

When you approach the edge, starting in the distance and working towards the player, it is drawing squares (with pixels) on the playfield. But I'm having trouble figuring out why. At first, I latched onto your topic of preserving an isometric perspective, but they don't seem to be using it to change the perspective -- the perspective lines look like they same. Perhaps someone can help me understand why they're carving out boxes with actual pixels, in addition to the DLIs? (And are they changing the anti-aliasing, while they're at it?)

I don't see any square drawing. I see instead the playfield divided horizontally into several sections, which are scrolled by a different amount - some by one box width, some by two box widths - and this creates an illusion of a grid. Everything is done by horizontal scrolling, no grid graphics appears to be redrawn here.

[emkay]

I don't see any square drawing. I see instead the playfield divided horizontally into several sections, which are scrolled by a different amount - some by one box width, some by two box widths - and this creates an illusion of a grid. Everything is done by horizontal scrolling, no grid graphics appears to be redrawn here.

Sometimes I like errors in Software. Altirra shows the bitshift nicely to the right side....

 

[Kr0tki]

More like errors in hardware; those artifacts are not Lucasfilm devs' fault.

[_The Doctor__]

It's an emulator.... but whatever... sigh, please disregard whatever interviews and writings that exist about ballblazer and how it was done ok? also bash everything you can about it, and while your at it try to pick on the Atari as well, I'm completely surprised with how it's the best of the offerings, and was such a success. In fact it's the point of endless discussion for such a terrible-non-this-no way-that piece of software on such a hapless machine so broken..... ohhh

 

Get a grip, this was pretty d*mn good software back then and even now as is the hardware. Can we discuss the software now, how to improve it, and how it was done, rather than it's all fake and possibly poo on a dorito chip... It clearly broke some ground in many aspects, let's focus on doing the same.

Edited January 19, 2018 by _The Doctor__

[emkay]

Get a grip, this was pretty d*mn good software back then and even now as is the hardware. Can we discuss the software now, how to improve it, and how it was done, rather than it's all fake and possibly poo on a dorito chip... It clearly broke some ground in many aspects, let's focus on doing the same.

Ballblazer was the only Atari game by Lucasfilm Games that was available at local stores here in Germany. I never did regret for the money. But, on the other hand, I wasn't really aware of HOW advanced the game was for it's time.

 

If only others did follow that road of development ...

 

The team from Lucasfilm games did "just use ordinary" features of the Atari, like DLI , LMS and Scrolling, and presented a game with a proper isometric playfield with added technical specs of the next decade, just as a side effect.

Edited January 19, 2018 by emkay

[Heaven/TQA]

Ballblazer was the only Atari game by Lucasfilm Games that was available at local stores here in Germany. I never did regret for the money. But, on the other hand, I wasn't really aware of HOW advanced the game was for it's time.

 

If only others did follow that road of development ...

 

The team from Lucasfilm games did "just use ordinary" features of the Atari, like DLI , LMS and Scrolling, and presented a game with a proper isometric playfield with added technical specs of the next decade, just as a side effect.

 

 

it definitly helped to be banked by Lucas' money... having modern dev tools (mainframes/c/cross compilers etc you find on the net explanations of their modern dev tools, networks, shared code, even emulators).

 

then it was not a mistake to have ILM next door... and having Carpenter in da house who is 3d guru... so they could pull off Ballblazer, Rescue on Fractalus. then having Lucasfilm on the range, too... they knew how to entertain and present stuff to the audience...

[VladR]

It is actually a complex routine by software to handle the "scrolling" line by line" . .

No it's not:

- you have 48 scanlines

- each scrolls by a different amount of pixels per second:

- Let's say - as an example - that the game scrolls 1 quad per second

- The top scanline (the most "distant" one), which is 11 pixels wide, thus scrolls 11 pixels per second

- The Bottom scanline (the most "near" one), which is 105 pixels wide, thus scrolls 105 pixels per second

- all the other scanlines in between scroll roughly linearly in between those 2 speeds (as long as the perspective matches the linear approximation!, you don't want two different coordinate spaces)

- you could come up with a fixed-point equation, where you just will be adding fixedpoint delta in a loop and it will be very fast

- or, you could use a simple look-up table of size 105*48 = ~5 KB

 

I am implementing the 6502 approach, without HScroll and DLIs, as I want to use it for my flatshader, where the applications are endless, once you are not limited by DLIs...

 

Plus, this approach doesn't actually exclude DLIs, so there's always an option to bring more colors to the table, if the cycle budget allows...

[Heaven/TQA]

Vladr...

 

yeah... I took different values and it seems my calculations are wrong...

 

 

btw... there is another tweak in code I see in BB...

 

dlist right at start (so when you are looking straight towards the texture and in middle)

 

you would assume that this is the "0" positon... but when looking at the display list you see like

 

line0+1+0*256

line1+2+1*256

line2+2+2*256

line3+2+3*256

line4+2+4*256

line5+3+5*256

line6+3+6*256

line6+3+7*256

line6+3+8*256

line6+4+9*256

line6+4+10*256

...