Optimizing Wolf3D-style rendering

[LaBodilsen]

Originally Posted by Toni Wilen

addq.l #x,an is 8 cycles. (memory access + 4 idle cycles)

Ahh, ofcourse i had looked on the wrong column.

[Tigerskunk]

Just dropping by here to say, that this is quite frankly amazing what you guys are doing here...
Keep up the great work..

Add/edit: Why do you think that collissions and game logic will hit the FPS so hard?

[britelite]

Originally Posted by Steril707

JAdd/edit: Why do you think that collissions and game logic will hit the FPS so hard?

It's the raycasting and sprite rendering that will take the hardest toll on the framerate, not the game logic.

[Tigerskunk]

Originally Posted by britelite

It's the raycasting and sprite rendering that will take the hardest toll on the framerate, not the game logic.

Since I don't have any knowledge about this kind of stuff, could you or someone else give me a short round up what you need raycasting for in this kind of game engine?

At the moment it looks kind of amazing already, it's hard for me to imagine what's still missing except collisions and some "game" around it...

[Samurai_Crow]

Ray casting is for determining line of sight for collisions and sprites overlapping and underlapping walls and other sprites.

[robinsonb5]

Originally Posted by Steril707

At the moment it looks kind of amazing already, it's hard for me to imagine what's still missing except collisions and some "game" around it...

As I understand it, at the moment "all" the engine is doing is scaling wall textures ("all" in quotes, because it's doing that very impressively!) - for each frame it's starting with a precalculated list of wall heights for each column on the screen rather than calculating the heights in realtime, so the engine can't yet do free movement within the world.

Raycasting is about figuring out which column of which wall has to be drawn at which height, for every column of pixels on the screen, which is why it's likely to be a bit of a framerate drag. It will be very interesting to see just how much!

[ajk]

I'm sure it's calculating them in real time, just the movement pattern is fixed instead of user controllable.

[robinsonb5]

Originally Posted by ajk

I'm sure it's calculating them in real time, just the movement pattern is fixed instead of user controllable.

I don't think so - I think (though I'd love to proved wrong!) it uses the same binary blob of pre-raycasted binary data that Britelite included in the previews. In the first post he describes it:

Originally Posted by britelite

I also included a binary blob of raycasted data (wolf.3d), if anyone wants to try out the wall rendering, without having to write a raycaster. The format is pretty simple, 1024 frames of 320 bytes each. Every frame consists of 2 bytes per slice (160 slices in total), first byte being the height of the wall (0-127) and second byte being the texture u-coordinate (0-63 for texture one, 64-127 for texture two, textures being 64x64 in size).

[khph_re]

Originally Posted by britelite

It's the raycasting and sprite rendering that will take the hardest toll on the framerate, not the game logic.

Could you jusrt use pre scaled sprites, or would that be to much of a memory hog? You could at least do that for lightbulbs/barrels.

[ajk]

Ah, okay - I interpreted that as data output from his raycaster so others don't have to code one to try improving the wall rendering portion. But I won't speculate further

[Tigerskunk]

Okay, thanks for the clarification, guys...

[britelite]

Originally Posted by ajk

Ah, okay - I interpreted that as data output from his raycaster so others don't have to code one to try improving the wall rendering portion. But I won't speculate further

The raycasting is precalculated in the demo, as that way anyone else using the binary blob would be able to directly compare their implementation to mine (and it's easier to optimize the rendering part in general if everything else has constant cpu-usage).

[malko]

Just having a little walk here with the help of the "Today's post" option.
Men ! The thread is really interesting and the engine done so far is red-hot for the A500 ...

[Tigerskunk]

It's really amazing. Cannot believe what I am seeing running on my A500, even without the raycasting active at the moment...

Would really love to see this getting finished..

[zero]

I was wondering if you could use fake scaling, like the scroll register hack method for horizontal scaling but with the CPU.

Rather than doing precise scaling you can just scale every N pixels, with a number of pre-scaled textures. That way you can use longer read/writes and save a few cycles on instruction fetch/decode.

Back in the day I wanted to try doing a blitter vertical fill for the walls. That would use 1 bitplane that acted as a kind of mask. The other bitplanes would be a repeating 1 pixel high "brightness map" that made the walls fade into darkness as they got further from the player. Could even be dithered with the scroll register.

[LaBodilsen]

Originally Posted by zero

I was wondering if you could use fake scaling, like the scroll register hack method for horizontal scaling but with the CPU.

Rather than doing precise scaling you can just scale every N pixels, with a number of pre-scaled textures. That way you can use longer read/writes and save a few cycles on instruction fetch/decode..

Yes and No.. You will always have to do precise scaling when using the CPU, as you can't "blit" 8-16 pixel at a time anyway. But the scalar code could maybe be arranged to better take advantage of longword writes, without it taking to much off of the visual quality.

But then again, to take full advantage of it, you would need several copies of the same texture in memory, which would take up to much memory at least for a game like Wolfenstein.

[zero]

Originally Posted by LaBodilsen

Yes and No.. You will always have to do precise scaling when using the CPU, as you can't "blit" 8-16 pixel at a time anyway.

Can't you? Doing it a blitplane at a time with the CPU... Especially on the A1200 where the 020 makes longer shifts take as many cycles as single bit ones.

If you want to port Wolfenstien then yeah, you can't use these tricks. But this is just Wolf-style rendering so it doesn't have to look exactly the same. You could, for example, use a 1 bitplane pre-scaled texture and then a static "noise" texture under it that wouldn't need re-rendering each frame.

I'm just thinking from a demo effect perspective, how could you get as close as possible to 60 fps at high resolution (320x256). How far can you get with an A500 and things like screen mirroring and blitter fill?

[britelite]

Originally Posted by zero

If you want to port Wolfenstien then yeah, you can't use these tricks. But this is just Wolf-style rendering so it doesn't have to look exactly the same.

Well, my intention with this topic was to discuss rendering that could actually be used in a Wolf3D-port (or Wolf3D-style game). Which is why usual demo techniques are out the window.

I'm just thinking from a demo effect perspective, how could you get as close as possible to 60 fps at high resolution (320x256).

You're not going to get close to 60fps, as PAL is only 50hz

How far can you get with an A500 and things like screen mirroring and blitter fill?

Why don't you try it out? But please open your own thread for that.

[LaBodilsen]

Originally Posted by britelite

There's still room for improvement in the wall rendering (for example, the code slices could be modified to draw longwords where possible).

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.

Also tried this out:

Just an idea to take advantage of this:
for walls between 63 - 48 use downscaling of 64px texture with longwords where possible, and for 47-33 use mipmap upscaling of 32px texture with longwords where possible.

And it did result in better visual quality (see attached picture) without having and impact on performence.

So by using these two improvements the demo is now a tiny bit faster, with overall better visual quality.

[Samurai_Crow]

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.

Also tried this out:


And it did result in better visual quality (see attached picture) without having and impact on performence.

So by using these two improvements the demo is now a tiny bit faster, with overall better visual quality.

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.