The Amiga 1000 could of done a game like Wolfenstein in 1985 - shock!

[Samurai_Crow]

He may be talking about prerotating textures at fixed angles and CPU blitting.

[Zetr0]

Originally Posted by DanScott

Yes, the amiga 1000 could probably do the equivalent of that ST wolfenstein, but probably not much more

Of course, there are a few things that you "could" do, to make it run just as fast in a 1x1 pixel screen.. but I will leave it for others to discover (hint, may require a couple of megs of fast ram)

I suspect a whole lot of pre-rendering is the order of the day here

Originally Posted by DanScott

second hint.. you don't need C2P

coupled with index tables

[AndNN]

I'm not sure pre-rendering would work in a practical sense... maybe for a demo. If you take into account a texture is 64x64 and to rotate by a set number of degrees, plus catering for all the sizes it could be. And then you have to consider software blitting on DWORD or WORDS (not sure which size is best) boundaries and pre-shifting to cater for that. This for every texture would be more than a couple of megs worth of data.

You could cut out doing that by per texture by still using the C2P and index lookup the colours in while the pre-defined rotation instruction sequence will know to use BYTE, WORD, or DWORD to plot. But still too much memory.

Are there any known demos that have done this? Might be interesting to see something like that in action.

[DanScott]

Convert your graphics so that they can be vertical XOR filled with the blitter.. what you end up with is some vertical spans...

for each pixel column of the texture, you create code along the lines of:

or.b d0,(a0)
or.b d0,200(a0)
or.b d0,480(a0)
...
...
etc...

then you can vertical fill the whole screen

you will be drawing to one buffer with the processor while the blitter is vertical filling the previous processor drawn buffer

[saimon69]

we could instruct people to physically rotate their monitors

not a programmer, but how processor-intensive is to render horizontal and rotate the buffer 90 degrees? If it can reach 12/17 FPS is still good

[kovacm]

Here is another example of 3D engine for plain 1989. STe by Doug (he also make Quake like engine for stock Falcon030):

[ Show youtube player ]

it is packed with lots of features...
I am not sure what STe hardware was used, maybe it can run on plain ST

[chb]

The Sega Mega Drive, which has a similar CPU speed (68k@7.6Mhz) and also no hardware scaling support, had a number of quite nice 3D games: Duke Nukem 3D, Toy Story (the 3D levels) and Bloodshot. The later two use a nice trick to save computation power: the walls are mirrored vertically in the middle of the screen, so only half the number of pixels has to be drawn. Enemies and objects are drawn as sprites. A similar technique would be possible on the Amiga, too, either by using HW sprites for objects (possibly too limited), dual playfield mode or mirroring with the blitter instead of the bitplane modulos (slower, but most flexible). Some color changes with the copper could further hide the mirroring a bit.
Both run nearly fullscreen at 1x1 aat acceptable (Bloodshed) or very good (Toy Story) speed.

Oh, and then there's a port of Wolfenstein by GASEGA68k, which uses a graphics mode that's a bit weird.

[sandruzzo]

Originally Posted by chb

The Sega Mega Drive, which has a similar CPU speed (68k@7.6Mhz) and also no hardware scaling support, had a number of quite nice 3D games: Duke Nukem 3D, Toy Story (the 3D levels) and Bloodshot. The later two use a nice trick to save computation power: the walls are mirrored vertically in the middle of the screen, so only half the number of pixels has to be drawn. Enemies and objects are drawn as sprites. A similar technique would be possible on the Amiga, too, either by using HW sprites for objects (possibly too limited), dual playfield mode or mirroring with the blitter instead of the bitplane modulos (slower, but most flexible). Some color changes with the copper could further hide the mirroring a bit.
Both run nearly fullscreen at 1x1 aat acceptable (Bloodshed) or very good (Toy Story) speed.

Oh, and then there's a port of Wolfenstein by GASEGA68k, which uses a graphics mode that's a bit weird.

Why don't do an Amiga Demo?

[AndNN]

Originally Posted by DanScott

Convert your graphics so that they can be vertical XOR filled with the blitter.. what you end up with is some vertical spans...

for each pixel column of the texture, you create code along the lines of:

or.b d0,(a0)
or.b d0,200(a0)
or.b d0,480(a0)
...
...
etc...

then you can vertical fill the whole screen

you will be drawing to one buffer with the processor while the blitter is vertical filling the previous processor drawn buffer

I think this technique will suffer from bandwidth issues as well plus the instruction is an Or which is more expensive.

To test the bandwidth I took the worst case for a vertical line and repeated the sequence so that it would fill the whole screen. This test takes the worst case of how many read and writes of a byte can be done in 1 frame. As soon as you know this information you get a good idea on what is possible.

I've come up with an idea where you can draw horizontal and use words to write at the cost of 2 extra blitter passes. If you draw horizontal then each word will contain 2 bytes that can be considered even and odd lines if that horizontal line was rotated 90 degrees. Now if the chunky buffer is scrambled up in a certain way you can use the blitter to swap and merge bytes so we get two areas in memory. One is a block of even and the other a block of odd lines. These two blocks can be processed as one with the C2P conversion. Once the conversion is done then the Copper can rearrange the even and odd areas by interleaving them together by using the bit-plane modulo's. This is a way that can rotate horizontal word sequences of bytes by 90 degrees at a word level.

I have not tested this yet but in theory we can now process 2 pixels at once by writing out words.

I'm still going the do 2x2 pixels because the blitter will not have enough time for for 2x1 pixels with the 2 extra blitter passes. But this extra bandwidth gain means that more things can be done.

[AndNN]

I'm pretty happy with the testing so far. By drawing the spans horizontal you can process 2 pixels at once. If you encode the textures with mipmapping and have 3 copies of texture data:

1. A word holds two colours of the same hue.
2. A word has two seperate hues.
3. A word has the bytes swapped from 2 (the above)

You can read 2 pixels at once and write 2 pixels. This doubles the bandwidth so with the tests I've done it can take just under a frame to process pixels at the cost of using more memory on the textures and by drawing horizontal and using the blitter to rotate 90 degrees (2 extra blitter passes). This leaves a frame and a half to process scaling sprites, ray casting and game logic in fast memory. By using mipmapping will make the game look better as well.

The blitter takes 2 frames to rotate 90 degrees and do the C2P conversion. This is all looking very promising to do Wolfenstein at 17fps, using EHB mode at 2x2 pixels.

I was toying with the idea of doing something original but by doing a conversion of Wolfenstein would be a lot easy to do because code and assets are public domain... which means I would not rely on anybody.

With that in mind I've been researching into how to quantise the original 256 colour graphics into an EHB palette. Nice little problem that

I've also did a little mockup of what it would look like rendering at 2x2 pixels. It looks pretty ok for me and if that was shown in 1985 it would of been outstanding because it would of been the first ever of it's type.

[AndNN]

How do you upload an image correctly in the forum... That is a thumbnail and not the original image. I worked it out

[kovacm]

Atari ST version run at 160*200 pixels (only horizontal doubling of pixels). Maybe you could use ST graphics or ask Ray/tSCc how he remap graphics to only 16 colors?

http://s390174849.online.de/ray.tscc.de/wolf3d.htm

there you will find that he used Mac source code, that he use http://www.ninjaforce.com graphics... check the link!

[AndNN]

Originally Posted by kovacm

Atari ST version run at 160*200 pixels (only horizontal doubling of pixels). Maybe you could use ST graphics or ask Ray/tSCc how he remap graphics to only 16 colors?

http://s390174849.online.de/ray.tscc.de/wolf3d.htm

there you will find that he used Mac source code, that he use http://www.ninjaforce.com graphics... check the link!

Yep, I read that a few years ago which is what made me think it's possible on the OCS Amiga.

The Atari St version actually uses 160x100 pixel resolution. He doubles up the scan lines. If you go onto youtube and search for Atari St wolf you can see this from the videos. At 2x2 pixels it looks ok which is why I think it will be fine on the Amiga.

The Amiga has a lot going for it than the Atari version. It can have 64 colours with EHB mode and with my testing so far it will run at 17fps PAL.

The Atari version uses more memory than what commercially released games used which is why using fast memory on the Amiga does not concern me.

The Amiga OCS machines using fast memory can process, in 2 frames, a whole screen worth of 2x1 pixels. The 68000 is not powerful enough to do 1x1 pixels at 17fps.

The actual bottle neck is the blitter C2P conversion. In realistic terms with EHB mode it can convert a 160X100 screen in over 2 frames. So this means with this into account the CPU can render a whole screen worth of pixels in one frame with code and data in fast memory. It takes 0.5 frame to transfer the chunky screen to chip. That leaves 1.5 frame time to print sprites and game code with assuming worst case wall drawing.

I'm not sure how accurate the Amiga 1200 timings are in winUA but I think it's possible to render at 2x2 pixels on a stock machine at 17fps. You could probably have 256 colours because the blitter will run more quickly because the bit plane fetches run quicker with setting the fetches up properly. On a 1200 with fast memory you could do 2x1 pixels as well. Anyway, must not get distracted with the Amiga 1200 yet.

I do like the idea of getting it to run on a stock 1200 at 2x2 fullscreen at 17fps because that could of been released commercially.

[kovacm]

Originally Posted by AndNN

The Atari St version actually uses 160x100 pixel resolution. He doubles up the scan lines.

Press * and you can switch between 160x100 and 160x200. I attach screenshot to see difference.

Even in 160x200 with smaller screen it is ok. Biggest problem with ST version is that you move in quite rude manner: you have filling like you step only on predefined places. I forgot how original Wolfenstein work on PC but I think that movement should be much smoother...

Anyway, Douglas Little made that demonstration on ST that show how much better raycasting can be achieved than Rays Wolfenstein (although Dougs does not have enemies and game logic)...

Originally Posted by AndNN

I do like the idea of getting it to run on a stock 1200 at 2x2 fullscreen at 17fps because that could of been released commercially.

on a stock Falcon you can play Doom but I am looking forward to see what you will manage to pull from A500 or A1200.

[sandruzzo]

is there any free source code about ray casting on amiga?

[DanScott]

Originally Posted by sandruzzo

is there any free source code about ray casting on amiga?

better to look at the math, and to write your own

[AndNN]

Originally Posted by kovacm

Press * and you can switch between 160x100 and 160x200. I attach screenshot to see difference.

Even in 160x200 with smaller screen it is ok. Biggest problem with ST version is that you move in quite rude manner: you have filling like you step only on predefined places. I forgot how original Wolfenstein work on PC but I think that movement should be much smoother...

Anyway, Douglas Little made that demonstration on ST that show how much better raycasting can be achieved than Rays Wolfenstein (although Dougs does not have enemies and game logic)...



on a stock Falcon you can play Doom but I am looking forward to see what you will manage to pull from A500 or A1200.

I did not realise you could change resolution... I just went by looking at the videos on youtube.

I think I'm more or less happy with the testing now so I guess I can start thinking about the conversion. I'm not sure how long it will take as I only spend a few hours on a Sunday doing this. But I'll give it a go.

[kovacm]

Originally Posted by sandruzzo

is there any free source code about ray casting on amiga?

There is Wolfenstein source for Mac classic.
Also Doug publish source for his 3D bsp engine for ST. Source should be in this thread http://www.atari-forum.com/viewtopic...8e1c&start=375

@andNN 17fps is quite impresive! Rays Wolf on ST run mostly at 8fps...

[Jackoland]

For me it's all about evolution. Game ideas evolve over time, as newer ideas are realised. Same with music, art and film. Changing and developing. To get to doom we had to have wolfenstein and to get to wolfenstein we had to have what came before! No doubt if the idea was realised in 1985 the gaming landscape would have been different, but think of the games we would have missed out on, whilst people made clone after clone of wolfenstein.

Rich

[AndNN]

Originally Posted by kovacm

There is Wolfenstein source for Mac classic.
Also Doug publish source for his 3D bsp engine for ST. Source should be in this thread http://www.atari-forum.com/viewtopic...8e1c&start=375

@andNN 17fps is quite impresive! Rays Wolf on ST run mostly at 8fps...

The Amiga's strong point, if fast memory is used, is that the blitter and code can run as fast as possible at the same time with no DMA contention to slow things down. That's how 17fps is possible... the blitter is effectively co-processing the C2P conversion.

So as I pointed out the blitter is the bottleneck. It can handle 160x100 very easily over 2 frames for 64 colours but beyond that it will struggle with EHB.

It's a real shame Commodore never updated the blitter for the 1200 because some very cool things would become possible. Especially C2P conversion while using low end cpu's...