So how did they code...

[Cymric]

So let's try to talk about something serious again (apparently, my contributions were slacking a bit of late...)

Ever since I saw and played games on the old Amiga, I wondered how certain effects were achieved. Take for example the faster-than-the-eye-can-follow, move-every-which-way-you-damned-well-please type-of scrolling found in games such as Zool, James Pond, or Turrican 2. Certain popular magazines offered an oversized bitmap as explanation, but that is of course limited to perhaps three or four times the visible screen size, and with those games I mentioned you had to battle through tens, even hundreds of separate screens. So that won't work.

I vaguely recall an article in a magazine (Amiga Format?) written by the programmer of Blood Money who used a neato trick to create a horizontal scroller. It boiled down to having only two screens in memory, and using some simple manipulation via the Copper to shift the 'view' slowly from left to right. However, at the same time you were building up a copy of the screen you were scrolling into in the part of the screen which wasn't visible, so by the time you reached the border of the right screen, you could reset the pointers to the left one, and start anew. The author encouragingly stated that other scrollers were just a matter of sitting down with pencil and paper and working out the details. Well, try as I might, I never got something elegant to work in the 2D-variant. Can someone explain how that was done?

The second thing which always bugged me were letter transformation tricks in the greetings of demos (and of course, cracks). Letters would be positioned along a sine wave, or bump, stretch and be mangled in various other ways. Nowadays, I would just define the letter as a 3D-shape and let the 3D API of my gfx-card handle it; CPU power is cheap. However, in those days we just had a 68000 and a Blitter. (And a Copper). How do you do a sine scroller with that kind of hardware?

Pseudo-M68K code is allowed in your answer, but if you resort to $DFF000-addresses make sure to indicate what these babies where all about. I forgot what most of them did, save for $DFF096 :-).

[Kronos]

Not that I had much expeience in HW-banging, but .....

What you describe in the 3rd paragraph was pretty much what came to my mind when I read your 1st question in the 2nd paragraph  :-D
And yes, getting that right would be  nightmare,l but once you have figured it it would be easy.

The scroll-texts were offcourse vektorized fonts (most I remeber only consisted out of a few points), all you had to do was move these points based on a static sine-table.

Remember that resolution was rather low, so having one value for every 5° would still look smooth. Add some obscure shifting and bit-rolling to replace those slow divs/muls and your set.

[Karlos]

A bit off topic, but it sort of relates to HW banging....

I recently found a way to make my amiga's gfx card accelerate voxel rendering. Not true perspective (although it might work), but axonometric (or orthogonal/isometric - take your pick). Early days but still, it could be a lot of fun for 2D strategy games.

[bloodline]

Karlos wrote:
A bit off topic, but it sort of relates to HW banging....

I recently found a way to make my amiga's gfx card accelerate voxel rendering. Not true perspective (although it might work), but axonometric (or orthogonal/isometric - take your pick). Early days but still, it could be a lot of fun for 2D strategy games.

Or you could use a 3D grphics chip :-P

[Karlos]

bloodline wrote:

Karlos wrote:
A bit off topic, but it sort of relates to HW banging....

I recently found a way to make my amiga's gfx card accelerate voxel rendering. Not true perspective (although it might work), but axonometric (or orthogonal/isometric - take your pick). Early days but still, it could be a lot of fun for 2D strategy games.

Or you could use a 3D grphics chip :-P

Who said I'm not? I'm not talking about big, fat ugly 8-bit rectangles here ;-)

[jdiffend]

Cymric wrote:

Can someone explain how that was done?

The programmer's description was pretty accurate.
Take a couple pieces of paper.   Draw an image on one in pencil.  Now set the 2nd piece to the right of the first.  Draw the continuation of that image on the next piece of paper.  Now slide them to the left until the 2nd one is sitting where the first one was.  Now erase the picture on the first piece of paper, set it to the right of the other piece and draw a continuation of what is on the 2nd piece.

That's a simple way of showing what is going on.
However, on the computer you start drawing once a part of the displayed image is offscreen so you don't have to draw the entire thing at once.

The difficulty is calculating when you can start drawing to the image that is onscreen, updating the copper list, etc.

You have to use a consistant timer to trigger the copper list update for smooth scrolling.  Probably an interrupt driven counter.  The interrupt handler updates the copper list and a counter telling the rest of the game where the screen is.  It could also update sprites for clouds or whatever but the handler needs to be small.

I'd say the counter is used as an index into a table for updating the copper list and you just copy from the table into the copper list or point to a new copper list.

When the screen gets scrolled to a certain point you can draw a porting of the screen.  Usually just blits of blocks or sections in a list of what goes on the screen horizontally.  For example, if the screen is split up so that it is 16 blocks high, the dataset will have 16 numbers telling the draw routine what image is to go into each of those blocks.  The block could be an image of a brick, metal plate, piece of sky, mountain, Tree, whatever.  The program just loops through the data blitting the appropriate block into each place from top to bottom.

It's just repeated over and over as you go and once you get to a screen is no longer visible you update the copper list to place it to the right.

Lots of looping and swapping pointers to things around for what screen is on the left or right.

Any objects that do more than scroll or appear over the backdrow are sprites so you don't have to update the buffer... the sprites just overlay it and can be moved on their own or you can have a more complex copper list that uses a split screen top and bottom.  However, there are limitations to that (2 scan lines have to be blank or something like that between top an bottom sections)

Once you get the hang of it it's not bad.
You just have to calculate where or when every event takes place.  Draw blocks, update copper, swap screens left-right, etc.

You have to calculate:
How many copper moves between drawing to the screen. (if copper moves > width of blocks then scrollposition++;
When to swap the screens (If scrollposition > width of screen then temp =left; left = right; right = temp; scrollposition = 0; whatever)
Where blits are on a screen for a specific scollposition (a table).  
What to draw... you can start with simple blocks and create a data set to scroll through in an endless loop just to get the scrolling working.
How to draw. (
for(i=0; i<16: i++) Drawblock( Screenmap(scrollposition, i), scrollposition, i)
Something like that where Screenmap is the data set telling what is displayed at any point along the way and it is 16 blocks high.

Once you get the hang of it you can increase the complexity by adding more data and having stages.  Once you get to a certain point you load a new set of image blocks to display and the data telling which ones go where.

I think there's actually code on Aminet that does this.  At least there used to be.  Probably a game that includes source.
 

The second thing which always bugged me were letter transformation tricks in the greetings of demos (and of course, cracks). Letters would be positioned along a sine wave, or bump, stretch and be mangled in various other ways. Nowadays, I would just define the letter as a 3D-shape and let the 3D API of my gfx-card handle it; CPU power is cheap. However, in those days we just had a 68000 and a Blitter. (And a Copper). How do you do a sine scroller with that kind of hardware?

Look at some of the demo source code... I know there is some out there that does this because I modified it for a store demo.
Keep in mind that demo's rarely do things in a system friendly way and don't work on all machines.

[Georg]

I vaguely recall an article in a magazine (Amiga Format?) written by the programmer of Blood Money who used a neato trick to create a horizontal scroller. It boiled down to having only two screens in memory, and using some simple manipulation via the Copper to shift the 'view' slowly from left to right. However, at the same time you were building up a copy of the screen you were scrolling into in the part of the screen which wasn't visible, so by the time you reached the border of the right screen, you could reset the pointers to the left one, and start anew. The author encouragingly stated that other scrollers were just a matter of sitting down with pencil and paper and working out the details. Well, try as I might, I never got something elegant to work in the 2D-variant. Can someone explain how that was done?

Bah! That technique sucks. Can be done much better. Faster, too. For a X-only scroller on 320x256 screenmode you need a "screen" whose byte size is about:

(320 x 256 / * numplanes +
(320 / * number_of_screens_of_map +
a handful more bytes (depends on size of tiles)

For any-direction scroller only a few more bytes are needed. Have a look at ScrollingTrick.lha on Aminet. It explains how it works and has example source in C.

[MiAmigo]

This is intriguing. I used to be a programmer. I was partial to Assembler for 68k machines. Using Windows was insidious - it changed me from a code writer, who wrote created his own code for whatever job needed doing, to a point-and-click 'user'! I wanna get back into programming (in assembler, of course). What are some good tools, and tutorials, (and libraries) for doing this. Maybe I'll even get back into writing my own retro-style games...

[Hattig]

IIRC if you have a 320x256 screen at memory location X, if you scroll 1 pixel right, the (320,0) pixel of the top line of the display is actually the 321st pixel of the screen, i.e., the pixel that was previously at (0,1). The last pixel of the display should be what was previously at (0,0). Well, err, this is how some 8 bit computers work, heh, I never did much Amiga programming, although I did a horizontal scroll using the 2-screen width display method as described in an earlier post, but that was in Blitz Basic.

Of course, writing 16 pixels at once was much easier than updating a single pixel every time you scroll by 1 pixel, because of the Amiga's bitplane display.

So you set up a 320x256 display onto a 336x256 display (for horizontal scrolling only). The right 16 pixels are hidden. Of course, that still requires the game to be able to update 256*16/8*bitplanes bytes of memory every time you scroll. Better to have a 352x256 display. Scroll right into the 16 pixels next to the screen, and with 1px/frame scrolling, you only have to update 1/16th of the update buffer each frame (with 2px/frame scrolling, that'd be 1/8th). A much more even balance of work per frame, and much friendlier for variable speed scrolls too I suppose.

The C64 had a 40 column tiled mode. For scrolling in this mode, you could hide the left and rightmost column of tiles to make it 38 columns displayed. Then you'd have the offscreen 'update buffer' for your game.

[jdiffend]

Bah! That technique sucks. Can be done much better. Faster, too. For a X-only scroller on 320x256 screenmode you need a "screen" whose byte size is about:

(320 x 256 / * numplanes +
(320 / * number_of_screens_of_map +
a handful more bytes (depends on size of tiles)

For any-direction scroller only a few more bytes are needed. Have a look at ScrollingTrick.lha on Aminet. It explains how it works and has example source in C.

That works just fine and does require less code to handle the screen since you aren't swapping screen pointers and such.  That also makes it faster.  For a map that scrolls in any direction it's a *lot* easier.  The drawback is it eats chip RAM.  For really large levels with lots of GFX blocks to choose from, swapping screens is better.  But what you save in chip RAM you make up for in CPU time and additional code to manipulate everything.  On a slow machine it also takes some carefull planning to keep it running smooth with everything going in the final game.

[Malkier]

You don't "need" to have it in Chip these days due to the very nice C2P-routines available together with for example BlazeWCP which lets you keep you gfx in Fast. The scrolling can easily be extended to allow for 4-way scrolling in the same way one does a 2-way scroller.
This does require some more Fast-mem but i think that should not pose a problem today with almost every a1200 being expanded - correct me if you're still using a vanilla-machine :-)
Greets from Sweden

[Cymric]

Many thanks to all who replied, that Aminet-file was indeed the thing I was looking for. It's so simple once you see it... But that is usually the case. The guys who developed this way back when must have felt like a million dollars when their first game/demo came out employing these techniques. (And unless I'm mistaken, it made sure that John Carmack can now drive around in Ferrari's and has the luxury to create games which are done when he thinks they are done.)

However, one thing still intruiges me: Karlos, what are voxels? At some point, in the early 90's, German magazines were aflame with them. They would be the Next Big Thing, but apart from two games, the concept never took off. I know a pixel---picture element---and the texel---texture element, usually triangular. Voxel implies something with volume, but volume rendering is a slow and painstaking process. (At leaat, on the data visualisation programs I use.) Could you be so kind as to elaborate?

[Georg]

The drawback is it eats chip RAM.

It's possible to make any-direction scrolling routine where map size can be unlimited big, but screen size stays fixed at:

width: (visible_width + tile_width * 2)
height: (visible_height + tile_height * 2)

btw, another trick: do not just use two screens (for double buffering). Instead use three screens. The third screen is scrolled like the others, but you don't blit any bobs/objects into it. This way it's always empty. So you can use it as restore-buffer. And can skip the backup-parts-of-screen-which-bob-will-overpaint part for game objects. Big speedup as scrolling is so fast anyway.

[bloodline]

However, one thing still intruiges me: Karlos, what are voxels? At some point, in the early 90's, German magazines were aflame with them. They would be the Next Big Thing, but apart from two games, the concept never took off. I know a pixel---picture element---and the texel---texture element, usually triangular. Voxel implies something with volume, but volume rendering is a slow and painstaking process. (At leaat, on the data visualisation programs I use.) Could you be so kind as to elaborate?

I don't know much about them, but I do know that DeltaForce (1 and 2) used a Voxel engine, which actually gave very good results. DetalForce 3 used a standard Polygon engine, so that it could use DX/GL... the graphics didn't look so good them.

[Karlos]

Cymric wrote:

However, one thing still intruiges me: Karlos, what are voxels? At some point, in the early 90's, German magazines were aflame with them. They would be the Next Big Thing, but apart from two games, the concept never took off. I know a pixel---picture element---and the texel---texture element, usually triangular. Voxel implies something with volume, but volume rendering is a slow and painstaking process. (At leaat, on the data visualisation programs I use.) Could you be so kind as to elaborate?

A Voxel is, as you describe, a volume cell. They are traditionally rather slow to render and for true 3D (ie perspective) are not so great, especially when a voxel is close to the point of view. It turns into a huge block of solid colour (shaded if you are lucky).

However, for isometric style projections, voxels can give very nice results, far better than polygons on pre-bumpmapping hardware like my trusty Permedia2...

-edit-

Hmm, that wasn't much of an elaboration, was it?

If you imagine you have a bumpy surface, you could create an image in which each 'pixel' represented the height of the surface at that point. This is a simple elevation map.

If you project that surface in 3D, and account for the physical width of these pixels (as well as their height) you can create a solid reconstruction of that surface.

Principal problems with voxels in 3D are that they look startlingly blocky up close and tend to involve a fair bit of overdraw (depending on the algorithms used to render them). Generally, they are not catered for by 3D hardware either, so you have to render them totally in software.

However, as I hinted, I have found a way to overcome that last part (albeit not really suited for perspective 3D) :-)