Optimizing Wolf3D-style rendering

[britelite]

Originally Posted by LaBodilsen

I took a stab at doing that manually (disassembling the generated scalarcode, and changing 822 MOVE.W to 411 MOVE.L by hand)

and the result was an average of 9 rasterlines gained. best case from the stream gained 7 rasterline, and worst case gained 11 raster lines.

Nice, in that case I think I'll have a go at updating the code generator.

[LaBodilsen]

Originally Posted by Samurai_Crow

According to the pictures, you're testing on an emulated A1200 instead of an A500 so the longwords might represent an unfair advantage on AGA.

The picture is taken from my "coding setup", running fullspeed emulation with immediate blits, as that makes for a much faster programing workflow. But the testing was done with an A600 cycle exact setup (68000, ECS etc.)

I'm coding using the fast setup as Asm-pro in 8 colors, is extremly slow on 68000/ECS.

[AndNN]

I don't think I'll ever get time to do this myself now... It's filed under projects when I retire in 5 years time. But from a thread I started last year here are some initial ideas I had which included 90 degree rotation and dither pattern ideas to gain more colours. You are welcome to use any of these ideas so long as I get credit, where due, for initially thinking up those techniques:

*************************************

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 dither 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.

[AndNN]

Very interesting reading this thread... I started some threads in 2016 and 2017 discussing pretty much these ideas. People are welcome to use the techniques I came up with but what I did not like at the time was personal PMs that called me a crackpot and basically told me I was talking crap. Shame on the people in this community that did that to me. This thread proves that my ideas were sound and those people were wrong.

Sorry to derail the thread but that had to be said.

[rothers]

I think making this work is one of the last great Amiga achievements.

I suspect it would get some coverage from the major UK tech sites if it happened just because it would be such a nice/impressive retro story.

It is surprising it has not happened yet, especially when you have raycasters running on the Spectrum etc.

[britelite]

Originally Posted by AndNN

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

At least on 68000 it's faster to do
move.w 16(a0),(a1)+
move.w 20(a0),(a1)+

[AndNN]

Originally Posted by rothers

I think making this work is one of the last great Amiga achievements.

I suspect it would get some coverage from the major UK tech sites if it happened just because it would be such a nice/impressive retro story.

It is surprising it has not happened yet, especially when you have raycasters running on the Spectrum etc.

That's pretty much true about coverage if this happens.

I hoped that I could find time to do this myself but real life work and family keep getting in the way. It's pretty obvious, not taking away what the original poster of this thread has achieved, but a lot of my ideas were used - which I don't mind but it would of been nice to be given credit for some of the ideas. I wrote this on the 16 Nov 2016 in the first thread I started:

**************************

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.

**************************

If you actually look into that first thread I started a lot of people that have posted in this thread posted in mine. If anyone can prove they came up with the idea of rotating the screen 90 degrees before 16 Nov 2016 for a Wolf 3D ray caster then so be it. If not then I should be credited for that idea. Also, the mip-mapping idea which I came up with in the second thread to help with word reads from the texture.

As I said before, I got some pretty not so nice PMs that called me a crack pot. I think I should of released a demo at the time but I was holding back until I worked out the best way to plot sprites. Anyway, I'm glad my ideas influenced someone to release a pretty good demo.

[britelite]

Originally Posted by AndNN

It's pretty obvious, not taking away what the original poster of this thread has achieved, but a lot of my ideas were used - which I don't mind but it would of been nice to be given credit for some of the ideas.

Which of your ideas exactly did I use without credit? To be honest, this is the first time I've even read any of them

[AndNN]

Originally Posted by britelite

At least on 68000 it's faster to do
move.w 16(a0),(a1)+
move.w 20(a0),(a1)+

Yes and no. It all depends on repeated colours.

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
move.l d0,(a1)+ write to chip memory

That will end up quicker. My span code looked for sequences of repeated colour and if that happened stored to registers. And if not used sequences like yours.

[britelite]

Originally Posted by AndNN

If anyone can prove they came up with the idea of rotating the screen 90 degrees before 16 Nov 2016 for a Wolf 3D ray caster then so be it.

Can't prove it, but I already toyed with the idea in 2010 after I released my first wolf3d-renderer in an A500-demo. So no credits for this

Also, the mip-mapping idea which I came up with in the second thread to help with word reads from the texture.

Sorry, but you didn't invent mip-mapping, so no credits here either

So I'm sorry to say that your past posts didn't influence me when making my demo, even you'd like to believe so.

[AndNN]

Originally Posted by britelite

Which of your ideas exactly did I use without credit? To be honest, this is the first time I've even read any of them

I'm happy someone is actually doing this. But in your first post in this thread you wrote:

One idea I had would be to rotate the whole chunkybuffer 90 degrees, which would let me draw to the buffer with the destination using (a0)+ instead of offset(a0), saving a lot of cycles. That would of course require rewriting the c2p-routine.

And in my original thread on the 16th of Nov 2016 I discussed that very idea. And I presumed you read it because you commented in that thread on the 14 July 2017, 10:21.

As I said I'm glad someone read those threads but be honest and give due credit. I'm pretty touchy about this because I had some very not so nice PMs telling me I was talking crap at the time.

[britelite]

Originally Posted by AndNN

As I said I'm glad someone read those threads but be honest and give due credit. I'm pretty touchy about this because I had some very not so nice PMs telling me I was talking crap at the time.

Yes, I do give credit when it's due, but this time it's not.

And it's a shame about those PM's, that kind of behaviour is unacceptable.

[AndNN]

Originally Posted by britelite

Can't prove it, but I already toyed with the idea in 2010 after I released my first wolf3d-renderer in an A500-demo. So no credits for this

Sorry, but you didn't invent mip-mapping, so no credits here either

So I'm sorry to say that your past posts didn't influence me when making my demo, even you'd like to believe so.

I know I did not invent mip-mapping but the idea of using it to read 2 bytes at the same time to process word reads was a way to save cycles - which I came up with.

I don't want to be argue with you. I'm pleased this is happening and I have some really good ideas on how sprites should be processed because to be honest I'll never have time to actually do this myself now - my life is too busy.

[britelite]

Originally Posted by AndNN

I know I did not invent mip-mapping but the idea of using it to read 2 bytes at the same time to process word reads was a way to save cycles - which I came up with.

Okay, but that's not what I'm doing in my routine though. I'm rather using chb's (who will actually get credited if I ever release a full game) idea to have the upper and lower half of the texture interleaved, so that I can read+write two pixels at a time. I only use mip-mapping so I can remove all offsets in the render loop, and only use post-increment instead.

So no, I'm not using your idea here either

[AndNN]

Originally Posted by britelite

Okay, but that's not what I'm doing in my routine though. I'm rather using chb's (who will actually get credited if I ever release a full game) idea to have the upper and lower half of the texture interleaved, so that I can read+write two pixels at a time. I only use mip-mapping so I can remove all offsets in the render loop, and only use post-increment instead.

So no, I'm not using your idea here either

Fair enough

You really should use my idea because, just read my first post in this thread (hopefully you can get the gist of what I'm on about), you can get dithering working and gain more colours that way. On CRT monitors it will look awesome

[britelite]

Originally Posted by AndNN

You really should use my idea because, just read my first post in this thread (hopefully you can get the gist of what I'm on about), you can get dithering working and gain more colours that way. On CRT monitors it will look awesome

I already have dithering in the demo (even if the current textures don't make good use of it), so no change needed there

[AndNN]

Originally Posted by britelite

I already have dithering in the demo (even if the current textures don't make good use of it), so no change needed there

You know what I think we have a race on here I'm going to find some time and get my version up and running with sprites working. It's pretty obvious you read my threads because you commented in them.

If you have not tackled sprites yet then good luck because that's a tough one to crack. I've pretty much worked out that problem and I just need to sit down and code it.

Let's see who makes the best version

[britelite]

Originally Posted by AndNN

It's pretty obvious you read my threads because you commented in them.

Does it really matter? Point is, I had no recollection of your earlier posts and had anyway toyed around with most of the ideas since 2010.

If you have not tackled sprites yet then good luck because that's a tough one to crack. I've pretty much worked out that problem and I just need to sit down and code it.

I have a few ideas on how to do the sprites, but haven't really done any coding on it yet. Making a fast enough raycaster has higher priority, and I'm afraid there won't be any progress on that front either in the near future.

Let's see who makes the best version

I'd rather concentrate on making an enjoyable game

[AndNN]

I'm wondering if anybody that contributed here read my threads because out of the two threads I made there's a lot of my ideas that are discussed in this thread.

The two main ideas been rotating 90 degrees and the use of mip-mapping to gain cycles by reading words.

If anybody can prove those ideas before my threads then I will back down. I'm actually kicking a fuss about this because as I mentioned I had some pretty nasty PMs saying I was a crackpot when I did a similar discussion. I'm actually not that impressed with this community because I was pretty open about discussing ideas.

ACTUALLY THIS HAS LEFT A BAD TASTE FOR ME AND I WONT BE BACK AGAIN...

[britelite]

Originally Posted by AndNN

I'm wondering if anybody that contributed here read my threads because out of the two threads I made there's a lot of my ideas that are discussed in this thread.

Or, you know, most of the ideas aren't actually very original or new, and several people may have come up with the same ideas. I mean, I don't claim to have invented any of the techniques I used in my demo, but I do know for a fact that I didn't get my ideas from you.