Has anyone tried to get a "Mode 7"-style game working on the Amiga?

[saimon69]

Originally Posted by vulture

@saimon69

Yes, isn't it? Many many stuff thrown around and at a very good pace as well! Definitely a good engine for an afterburner/galaxy force game!

Going back in this small OT i did recently took the chance to ask Franck and Yves and have bad news: the unreal Amiga 3d engine sources have been lost

[turrican3]

Originally Posted by saimon69

Going back in this small OT i did recently took the chance to ask Franck and Yves and have bad news: the unreal Amiga 3d engine sources have been lost

shit shit shit !!!!

[Hypex]

Originally Posted by Steril707

Today I saw this and was heavilly impressed:

By the looks of these first two examples they should be possible without invoking any chunky coppers at all. At least going by the rendering just moving forward and scrolling left and right. A few games would have done this, by displaying imagery in 3d perspective and scrolling different lines, to create a 3d sideways scrolling effect.

Not proper rotation no, but effective. And using way less CPU by just programming the copper. I think copper rotation would be possible, but only with a limited size texture, and would need pre-renders along with sliding across to create full rotation effect.

I would have expected by now there would have been games with actual 3d moving backgrounds. Well there are, but they are flat textures, with 2d objects above usually. I think it would be possible to have clouds roll across in 3d as well as mountains in 3d as an example. But frames would need to be pre-rendered so taking up some chip. Then the copper would be used to change frame and scroll offset so a 3d depth is maintained.

Yes I'm talking about proper Amiga accelerated 3d using the copper. Taking into considerations the limitations and features of the chipset. None of copper chunky PC crap. LOL. :-P

[Samurai_Crow]

@hypex

We need to get you a Vampire stand-alone card. ;-) Once Gold3 core is out, that is....

[Hypex]

Originally Posted by Samurai_Crow

We need to get you a Vampire stand-alone card. ;-) Once Gold3 core is out, that is....

:-D

But then, it has that chunky plane, so is all this copper fun needed now? Indeed, can the copper affect the chunky plane? I prefer it to be called packed bitplane over chunky. :-)

[Samurai_Crow]

Originally Posted by Hypex

:-D

But then, it has that chunky plane, so is all this copper fun needed now? Indeed, can the copper affect the chunky plane? I prefer it to be called packed bitplane over chunky. :-)

Chunky native is affected by copper on Gold 3. The problem is P96 doesn't support copper, OS3 doesn't support chunky by itself and AROS doesn't support copper. It's hardware banging season!

[Hypex]

Originally Posted by Samurai_Crow

Chunky native is affected by copper on Gold 3. The problem is P96 doesn't support copper, OS3 doesn't support chunky by itself and AROS doesn't support copper. It's hardware banging season!

That sounds like a cascading failure right there on the end. Well P96 is based on a VGA or standard frame buffer so would have an 8-bit CLUT chunky mode but the palette would be expected to be inside the graphic chip which it would be on a plug in card. Leaving the copper out of reach.

OS3.1 does have some tweaking for RTG. And it is chunky aware. But the main system is still focused on bitplanes. A while back I was examining a chunky bitmap structure. They always set the depth to 1 which didn't make sense and I used to dispute that if it was 8-bits or 16-bits. Or 24. But relative to the Amiga it was correct in the sense that it was actually one bitplane. Because the pixel bits were packed across on one plane. If we compare one screen line of chunky against one line of interleaved planar in 8-bit depth both methods use 320 bytes for each line in sequence for 320 pixel width.

The problem is the use of the word depth which is misleading. The depth is obviously more with an 8-bit chunky map or 16-bit frame buffer. But it describes the bitplane depth. The width isn't stored directly but only in bytes per row. An 8-bit chunky and 8-bit planar bitmap will both have 320 bytes per row in the case above so that will be set accordingly. The bitmap structure in that way was supportive of chunky or forward compatible. Bit they failed to give it any RTG flags. Nor insert a direct width in there.

Now what I'd like to see is is an 8-bit planar chunky mode. That is all 8 bitplanes able to be in an extended pixel width mode, with 8-bits per pixel packed data, overlayed with their own palette if its not too much to ask! :P

It is interesteing to note that HP raster data for pens can be planar or chunky. Or indeed a hybrid mode that I would have expected to be added to the Amiga. The four colour pens are sent on their own planes. So in a planar format, but each plane can be in a chunky format, a byte per colour pen index. For a direct RGB dump, it usually uses one plane, with RGB bytes sent sequentially.

[Tigerskunk]

Originally Posted by Hypex

By the looks of these first two examples they should be possible without invoking any chunky coppers at all. At least going by the rendering just moving forward and scrolling left and right. A few games would have done this, by displaying imagery in 3d perspective and scrolling different lines, to create a 3d sideways scrolling effect.

Not proper rotation no, but effective. And using way less CPU by just programming the copper

Do you have any examples for this?

At the moment I cannot imagine this being a working substitute for a proper tile based floor in a game like that.

[Hypex]

Originally Posted by Steril707

Do you have any examples for this?

At the moment I cannot imagine this being a working substitute for a proper tile based floor in a game like that.

Sure, Elfmania was one of the first and also cutest I noticed that was "special" from just the demo. Look at the timber floor. It moved left and right in 3d perspective. Obviously a copper trick just sliding different lines at different speeds. They could have easily moved it up and down in 3d perspective as well shrinking or expanding it vertically on the graphic. @ 45s.

[ Show youtube player ]

Another would be Lotus. Now I don't know exactly how Lotus renders the screen but if you look at how the road is animated on screen it slides left and right with top most sliding the most as it goes into the screen or down the road. The road also moves up and down on waves so when there is a hill or a or a dip it shrinks or expands on the curve. I imagine the copper could be used to create this effect, sliding across and vertical scaling, with just a few CPU instructions to update the copperlst. Cheap 3d effect using almost no CPU time. That's what the Amiga as made for. Lotus 2 below. @ 185s. I copied the time but it doesn't work here.

[ Show youtube player ]

So not exactly rotation. A glorified italic line routine you could call it. But useful for when you only need to stretch it left, right, up and down. Or in this case sliding left and right or stretching up and down.

About 20 years ago I was developing this technique. Or started some demo code to prove if it could work. At the time I had a bog standard A1200. I was using DPaint and used it to render a 3d road anim of about 16 frames. This was just a simple render of a road moving along. To save space I also created a simple run length compression algorithm to unpack the frames on the fly. It was called Flat IIRC. There was FlattenFile and FattenFile. LOL.The unpacking routine was written to fit inside the 010/020 cache and use fast loop mode. So my idea was for a racing game, the anim would switch every frame. And the copper would be used to slide each line across to move left or right. For up and down it would use the copper to scale the image, by skipping lines to shrink it. For a 3d bump map or wave it would have calculated where to skip lines so the effect was rendered on screen. Nice 3d road moving across and waving vertically. Now the frames would take time to unpack but leaving them in chip would save that time and leave it for other things. As I was working on it I "upgraded" to an 030. Now I don't know what happened. But the "faster" CPU wrecked my routine. On the 14Mhz 020 I had smooth motion. On the 40Mhz 030 I had stuttering. I thought it may have been a cache issue but I never figured it out. A woman entered my life, the Amiga lost popularity, and after that my project stalled and I never finished it to a working stage.

[sandruzzo]

Originally Posted by Hypex

Sure, Elfmania was one of the first and also cutest I noticed that was "special" from just the demo. Look at the timber floor. It moved left and right in 3d perspective. Obviously a copper trick just sliding different lines at different speeds. They could have easily moved it up and down in 3d perspective as well shrinking or expanding it vertically on the graphic. @ 45s.

[ Show youtube player ]

Another would be Lotus. Now I don't know exactly how Lotus renders the screen but if you look at how the road is animated on screen it slides left and right with top most sliding the most as it goes into the screen or down the road. The road also moves up and down on waves so when there is a hill or a or a dip it shrinks or expands on the curve. I imagine the copper could be used to create this effect, sliding across and vertical scaling, with just a few CPU instructions to update the copperlst. Cheap 3d effect using almost no CPU time. That's what the Amiga as made for. Lotus 2 below. @ 185s. I copied the time but it doesn't work here.

[ Show youtube player ]

So not exactly rotation. A glorified italic line routine you could call it. But useful for when you only need to stretch it left, right, up and down. Or in this case sliding left and right or stretching up and down.

About 20 years ago I was developing this technique. Or started some demo code to prove if it could work. At the time I had a bog standard A1200. I was using DPaint and used it to render a 3d road anim of about 16 frames. This was just a simple render of a road moving along. To save space I also created a simple run length compression algorithm to unpack the frames on the fly. It was called Flat IIRC. There was FlattenFile and FattenFile. LOL.The unpacking routine was written to fit inside the 010/020 cache and use fast loop mode. So my idea was for a racing game, the anim would switch every frame. And the copper would be used to slide each line across to move left or right. For up and down it would use the copper to scale the image, by skipping lines to shrink it. For a 3d bump map or wave it would have calculated where to skip lines so the effect was rendered on screen. Nice 3d road moving across and waving vertically. Now the frames would take time to unpack but leaving them in chip would save that time and leave it for other things. As I was working on it I "upgraded" to an 030. Now I don't know what happened. But the "faster" CPU wrecked my routine. On the 14Mhz 020 I had smooth motion. On the 40Mhz 030 I had stuttering. I thought it may have been a cache issue but I never figured it out. A woman entered my life, the Amiga lost popularity, and after that my project stalled and I never finished it to a working stage.

ElfMania used a trick very good. They slide first 10 pixel with either cpu or blitter, were player are placed, and the other lines, only copper slide since no player will act there!

About Lotus, My idea too. To use dual playfield on A1200. One for full texture road, and use only copper to slide lines, and another for cars and other stuffs!

[Hypex]

Originally Posted by sandruzzo

ElfMania used a trick very good. They slide first 10 pixel with either cpu or blitter, were player are placed, and the other lines, only copper slide since no player will act there!

About Lotus, My idea too. To use dual playfield on A1200. One for full texture road, and use only copper to slide lines, and another for cars and other stuffs!

I think you and I think along the same bitplane sandruzzo.

Yes what I was thinking was dual playfield. Reduces colours somewhat but copper can make up for some.And then organising the playfield between the two.

So in the back layer at top have the mountains. In my elaborate case the mountains would be rendered with a few obvious frames in 3d, so when scrolling the graphic would also be changed to create a 3d mountain panning effect. Takes chip but avoids trying to create it in 2d with parallax even if copper can slide lines.

This would meet with the road. Which would then be rendered in similar fashion. A pre-rendered 3d road of enough frames moving forward. Sliding left and right. Then "wave mapped" for Y position of each line. All by copper.

Top layer would have clouds rendered same as mountains. Possibly sprites could also be used to render different frames of same cloud graphic at different positions on screen giving way to plot clouds using same cloud from different 3d scrolling pans. But essentially 3d clouds panning across.

Below this the main action. Trees or other barriers. Cars. The Trees would be pre-renders with 3d panning. But scaled onto screen in realtime, unless a 3d panned in different scales was small enough. Likely using blitter. This would create illusion real 3d depth in trees and other objects. The cars, depending on complexity and time, maybe 3d rendered in realtime as a CLUT and then written to screen in planar. Would most likely adopt same technique as trees, so cars would have proper 3d depth, as they move left and right. And going into screen.

For score panel sprites could be used or a top playfield layer. Could also use sprites for other objects on screen. Parallax layers could be exchanged when and where needed for ease of rendering.

Also have idea in mind for fighting game. Would not need so much action so floor could be static. CPU time could be spent 3d rendering characters. Sprites for superimposing images on screen. Also have idea for 24-bit colour sprites where palette is changed each line before that sprite line appears on screen. Using 15-colour sprites as base object. Taking into account colour clashes and other conflicts.

[ReadOnlyCat]

Originally Posted by Hypex

Yes what I was thinking was dual playfield. Reduces colours somewhat but copper can make up for some.And then organising the playfield between the two.

I like the idea too and I think it would also be viable on an OCS/ECS machine depending on the type of game.

After all, not all driving/road-based games need a lot of colors and the graphics can be made sci-fi or simplified to fit with a reduced number of colors as part of a dedicated art style.

[Samurai_Crow]

On AGA don't forget that you can bank switch all 16 colors in one Copper move thus allowing double buffering of palette changes every row of pixels so you can easily use the visible area of the screen for more palette changes.

[ReadOnlyCat]

Originally Posted by Samurai_Crow

On AGA don't forget that you can bank switch all 16 colors in one Copper move thus allowing double buffering of palette changes every row of pixels so you can easily use the visible area of the screen for more palette changes.

Would this work mid scanline?

If the hardware is designed to update a "pointer" to the current CLUT when switching banks rather than copying the selected CLUT to the current one then mid-line palette switches should be instant and could be very useful.

[Samurai_Crow]

I don't know how often the bank select register updates. If I were designing the chip I'd make it latch in at the end of a line only.

[zero]

Originally Posted by Samurai_Crow

I don't know how often the bank select register updates. If I were designing the chip I'd make it latch in at the end of a line only.

I doubt they did that, everything else on the Amiga is unbuffered and updates instantly.

[Samurai_Crow]

Originally Posted by zero

I doubt they did that, everything else on the Amiga is unbuffered and updates instantly.

Ok. There's one way to find out!

[Toni Wilen]

Bitplane color bank select (8 banks of 32 colors) only affect color register writes, it does not affect output. Sprites have output bank selection registers (16 banks of 16 colors, one for odd and even sprites)

BPLCON4 8 XOR bits are probably what you meant and it has extra 1 hires pixel delay compared to normal color palette register writes. I am not sure if sprite bank selection has same delay.

[ReadOnlyCat]

Originally Posted by Toni Wilen

Bitplane color bank select (8 banks of 32 colors) only affect color register writes, it does not affect output. Sprites have output bank selection registers (16 banks of 16 colors, one for odd and even sprites)

BPLCON4 8 XOR bits are probably what you meant and it has extra 1 hires pixel delay compared to normal color palette register writes. I am not sure if sprite bank selection has same delay.

Yes,

BPLCON4

's

XOR

ing mechanism is more appropriate than the register bank switching indeed.

This is great news, and means that whole palette changes can be simulated almost anywhere. This would be a great way to add colors to dual playfield games for example.

Thanks for the clarification Toni!

[sandruzzo]

Originally Posted by Hypex

I think you and I think along the same bitplane sandruzzo.

Yes what I was thinking was dual playfield. Reduces colours somewhat but copper can make up for some.And then organising the playfield between the two.

So in the back layer at top have the mountains. In my elaborate case the mountains would be rendered with a few obvious frames in 3d, so when scrolling the graphic would also be changed to create a 3d mountain panning effect. Takes chip but avoids trying to create it in 2d with parallax even if copper can slide lines.

This would meet with the road. Which would then be rendered in similar fashion. A pre-rendered 3d road of enough frames moving forward. Sliding left and right. Then "wave mapped" for Y position of each line. All by copper.

Top layer would have clouds rendered same as mountains. Possibly sprites could also be used to render different frames of same cloud graphic at different positions on screen giving way to plot clouds using same cloud from different 3d scrolling pans. But essentially 3d clouds panning across.

Below this the main action. Trees or other barriers. Cars. The Trees would be pre-renders with 3d panning. But scaled onto screen in realtime, unless a 3d panned in different scales was small enough. Likely using blitter. This would create illusion real 3d depth in trees and other objects. The cars, depending on complexity and time, maybe 3d rendered in realtime as a CLUT and then written to screen in planar. Would most likely adopt same technique as trees, so cars would have proper 3d depth, as they move left and right. And going into screen.

For score panel sprites could be used or a top playfield layer. Could also use sprites for other objects on screen. Parallax layers could be exchanged when and where needed for ease of rendering.

Also have idea in mind for fighting game. Would not need so much action so floor could be static. CPU time could be spent 3d rendering characters. Sprites for superimposing images on screen. Also have idea for 24-bit colour sprites where palette is changed each line before that sprite line appears on screen. Using 15-colour sprites as base object. Taking into account colour clashes and other conflicts.

Would be great to do race game with these tricks and a game Like elf mania!!!