Wolf3d: more ideas.

[AndNN]

I see the other thread got derailed that I started and was locked. Anyway a new thread to discuss some ideas to make Wolfenstein on the Amiga.

For months I've been thinking of a new approach that would allow 2x1 pixels instead of 2x2 pixels. Even though it's possible to do Wolf3d with 2x2 pixels using fast memory I was never happy with that resolution. 1x1 pixels are not possible but I have some thoughts on how to get 2x1 pixels.

My initial idea was to use half bright mode to get around 64 colours used for the game. Those bit-planes eat into DMA cycles when writing the chunky graphics to chip memory so it's not possible to transfer a screen of 160x176 to chip memory in under a frame.

So I did some tests with 4 bit-planes and things speed up dramatically to transfer that data over to chip memory.

That means we are stuck with 16 colours which sucks really. Then about a month ago I came across these web pages to gain extra colour by swapping colours every 50/60 fps.

http://www.aaronbell.com/secret-colo...-commodore-64/
http://www.leonik.net/dml/sec_crypto.py

So long as colour intensities are the same then 2 colours will blend seamlessly without strobing effects. So in theory that should gain the required colours needed. This will probably look crap on emulators but on CRTs will work perfectly.

Because we are using 4 bits per colour you can encode 2 screens worth into a Byte element per screen size so the copy to chip does not double in bandwidth and size. So all well there.

Then I thought why use bit-planes. Attached sprites can be 16 colours and have the advantage of been 16 in width and the height of the screen. With bit-planes disabled you could multiplex sprites across the screen by changing the x pos and still have time to change the dma data pointers. This has the advantage of a screen laid out vertically which is great for drawing vertical strips.

Now if you are willing to burn off memory for texture storage then you could generate a mip-map chain of possible combinations of the scaling pixels that would transfer Words instead of Bytes vertically that would give the correct colours with scaling. So you would just process in vertical slices for each column.

Because we are now dealing with WORDS we might as well transfer directly to chip memory across the 16 bit bus and avoid the copy code. This brings the question of how sprites can be dealt with? For each column you would process wall and sprites together by clipping them so you only draw 1 pixel only with no overdraw. This could be done by patching the pre-calculated scale code and jump around to different scales with new data pointers for the textures.

If you were willing to use heaps of memory for textures then you could process using DWORDS.

But the idea here is we are processing vertical strips which are ideal for sprites while using colour swapping on the refresh to get the required colours.

Sorry, I have not been updating on this lately... family and life get in the way but rest assured I've been thinking about this a lot.

I'm not really thinking about the Amiga 1200 here but it may be possible for this to work on a standard 2meg of chip ram setup with no fast memory.

[AndNN]

I've been looking at sprite multiplexing. I managed to do it in the early 90s but my memory of it was different to what it is.

What I've learned about it now is that to change a sprite on the horizontal you need 6 slots of the copper per attached sprites to update Pos and Data and that leaves 2 slots for CPU and blitter. This is with the bit planes disabled. It looks like the Copper will hog most of the DMA time on the blitter and CPU side of things.

I'm I correct in this assumption? If so then it's best to use 4 bit planes instead, which means one extra blitter pass. I'll have to do some timings on this to see what blitter time I have with 4 bit planes.

I thought by removing bit planes I could gain extra DMA time back for the blitter but I think the Copper will hog more with sprite multiplexing.

Does anybody from experience with sprite multiplexing know if this is still viable to use a sprite screen?

Edit: Can the Copper use odd cycles or is it always stuck on the even side. I know the blitter will use even and odd of available DMA slots.

Edit again: After reading up on this I see the HW reference manual is wrong about even and odd cycles - the CPU will also take any free DMA slots as well. So the Copper will hog one side and the Blitter and CPU will take any available slots.

[Samurai_Crow]

I would not recommend using sprites for anything more than the gun and hands in a Wolf3D clone. You get overlay transparency free and that is all.

Sent from my Prism II using Tapatalk

[AndNN]

Originally Posted by Samurai_Crow

I would not recommend using sprites for anything more than the gun and hands in a Wolf3D clone. You get overlay transparency free and that is all.

Sent from my Prism II using Tapatalk

Yep, you are right... using a sprite screen is a bad idea. It's slower than 4 bit planes.

2x1 pixels are not possible on an OCS screen. I've really put a lot of thought into how the best way to go about rendering, and how to write the data to chip memory using the minimum bandwidth as possible. To the point where I could transfer a screen size of 160x176 to chip memory with plenty of time for other things to run. The thing that lets it down is the blitter cannot convert that data to planer at 17fps (I really want to achieve that fps). It can at 8.5 fps but that rate is crap really. I am talking about PAL here.

So back to 2x2 pixels again. I'm still going to use that colour swapping method to gain more colours, though.

Then from the locked thread (the other wolf thread I started) I saw this video:

[ Show youtube player ]

That demo is obviously using 16 colours and 2x2 pixels, plus it's a normal Amiga with no fast memory. It's actually very impressive and I wondered how my code would run without fast memory. So I did some tests.

With 4 bit planes I can convert to planer in 2 frames, which leaves one frame without the blitter running. While the blitter is running I can write the chunky data out. I'm thinking now it's possible to do this without fast memory... I just need to work out if it can be done with 1 MB of RAM. This is actually in the realms of possible.

[zero]

Have you considered rendering only half the screen and mirroring it? As long as the camera stays level and your walls are carefully designed to be vertically mirrored it basically saves you 50% of the work.

The trick is to find a way to make a game with this limitation. See Toy Story on the Megadrive for an example of this technique, where they mirrored everything including the objects and ceiling/floor.

[roondar]

@zero that is an interesting technique.

Two other variations of the same spring to mind:

1) Only draw half of the lines and leave the rest black or gray (this is famously done by a rather impressive Atari 800 'doom' demo). You could even opt to disable bitplane DMA altogether during these lines to get more raster time to work with.
2) Use the copper to line double every line, which doesn't give back DMA time but does halve the rendering cost.

[AndNN]

If I don't use that colour swapping idea but instead dither the 16 colours and go back to using fast memory then the blitter has time to convert a 160*176 screen to give a resolution of 2x1 pixels. That is definitely possible and I have tested it.

The chunky pixel will give a bytes worth of data holding a dither pattern:

10101010 This is a byte with dither encoded in.

The idea is to draw the spans linear in memory which has the effect of rotating the screen by 90 degrees. A Word will store even and odd scan lines:

EOEOEOEO... and so on

The first pass of the blitter swaps the bytes so we get 2 sections of even and odd scan lines.

EEEEEEEEEEEEEEEE... and so on
OOOOOOOOOOOOO... and so on

This merge produces 4 pixels worth of planer data. The copper is used to interleave even and odd lines back to where they should be.

The next blitter pass will produce 8 pixels worth of planer data.

And the last blitter pass will produce 16 pixels worth of planer data. The timings for the blitter on 4 bit planes is 3 frames at 17fps pal.

This produces a dithered pattern like:

1010101010101010 of 1 bit plane and the next scan line would be:
1010101010101010

Which is dithered like the megadrive version. It would be nice to produce a dither pattern like this:

1010101010101010
0101010101010101

That would be a much better blend pattern on a CRT monitor to gain the extra colours.

This can be achieved through the texture mipmap scheme I have in mind. Because we are drawing horizontal for each span we can read two pixels worth of data for even and odd lines together. This scheme wastes memory on the texture map encoding. I won't go into this detail here at the moment but this means we can process 2 pixels at once.

The 68000 instructions to make wall/sprite span.

move.w 16(a0), d0 read from fast memory
swap d0
move.w 20(a0), d0 read from fast memory
move.l d0,(a1)+ write to chip memory

This sequence has processed 4 pixels.

Writing directly to chip memory using Dwords saves writing to fast for the chunky storage then a copy to chip. This complicates things with sprites and a scan buffer management scheme would have to be implemented to process with no overdraw. That's what I'm thinking about now at the moment.

So that's how it can be done with fast memory, 4 bit planes, a dither pattern to get extra colours, 2x1 pixels, and at 17fps.

Ok, I won't go into here but the timings for 2x2 pixels can work on a machine without fast memory. I need to look if it is possible to make that work with 1MB of memory. The original PC version used 600k so it may be possible.

My wish is to get a version working using 2x2 pixels with 1MB of memory and if fast memory is detected it will switch to 2x1 pixels. That will keep the Amiga purists happy with not using fast memory but if it's there you get the enhanced version.

The secret for this to work was to use 4 bit planes and differ to gain colours instead of wasting DMA cycles on EHB mode for 64 colours. I think differing on CRT monitors will look good (at the time there was no such thing as flat screens) so to me dithering is acceptable for the time the Amiga was released.

[zero]

I wonder if you could use a blitter vertical fill somehow. Like the old scrollers did... But with a cleverly selected palette and wall texture. Obviously no good for a Doom port but for something original perhaps...