Optimizing Wolf3D-style rendering

[britelite]

Originally Posted by LaBodilsen

It don't like fast setups though, as the movement becomes a little jittery. But that is not the target platform anywho, so all is good.

Yeah, first priority is to get it all working on plain A500. When everything is in place I'll fix stuff for accelerated Amigas, and possibly include some alternative (and more precise) routines for those with cpu-power to burn

Any kind of "build blog" posted here would be greatly appreciated, no need to post previews

Yeah, I think I'll at least post an update when I have the sprite rendering done, together with an explanation on how I've implemented it. Just in case anyone has some great ideas on how to improve it

[britelite]

Okay, so I've been toying around with ideas for the sprite rendering. The current idea I have is to use the same kind of scaling and rendering as with the walls, but instead of doing move.w for two texels, I would do move.l for a combination of texels and mask (basically t1t2m1m2).

Basically I would render a column with the cpu to a separate buffer with texels and mask, and then use the blitter to draw this onto the screen buffer. This would also give me the option of reusing the buffer when using larger scaling factors, as the same column might get repeated.

[rothers]

Will the sprites be entirely prerendered on boot in ram for speed? Will they always be facing the player like SNES doom, or a more complex approach?

[britelite]

Originally Posted by rothers

Will the sprites be entirely prerendered on boot in ram for speed? Will they always be facing the player like SNES doom, or a more complex approach?

Nope, the sprites won't be prescaled as that would eat up too much memory. Haven't decided yet if they'll remain facing the player at all times, that pretty much depends on how much memory and style of gameplay.

[rothers]

With regards to ram and prescaling, how many colours is it running in? What are the speeds at 8colours vs. 16? How much ram is already used?

[britelite]

Originally Posted by rothers

With regards to ram and prescaling, how many colours is it running in? What are the speeds at 8colours vs. 16? How much ram is already used?

It currently runs in 16 colors (you can have a look at the previews available in this very thread). Making it run in 8 colors won't make much of a difference regarding speed as that would only affect a small portion of the c2p-routine, and would have zero impact on memory when it comes to the graphics due to the way textures and sprites are stored.

[rothers]

I'd go with just facing away and facing forward baddies. 1 frame on the facing away (or possibly just the head part) and 2 frames on the coming forward, DOOM style.

Would that possibly fit in to RAM prerendered?

I know you have said there isn't enough RAM but have you calculated how much faster prerendered baddies would be? Even if it was only for 2MB machines? I'm just curious about the possibilities.

I have been following the thread over the last year and I did try your demo and it is impressive, I just wondered about the general specs and speeds on various setups.

It is fantastic you have decided to tackle this, it's one of the last great Amiga achievements. I do hope you make a boxed copy.

[britelite]

Originally Posted by rothers

I'd go with just facing away and facing forward baddies. 1 frame on the facing away (or possibly just the head part) and 2 frames on the coming forward, DOOM style.

Would that possibly fit in to RAM prerendered?

Assuming 32 pixel wide sprites, with sprite height never exceeding the viewport and precalculating the vertical scaling, we'd get (40*40*128)/2=102400 bytes per frame. And for this to be of any use it would have to reside in chip ram so the blitter can access it. If we have the data in slow/fast ram we can as well do the scaling with the cpu as it's pretty much copyspeed anyway, and thus save a lot of memory.

[LaBodilsen]

Originally Posted by britelite

Basically I would render a column with the cpu to a separate buffer with texels and mask, and then use the blitter to draw this onto the screen buffer. This would also give me the option of reusing the buffer when using larger scaling factors, as the same column might get repeated.

Sounds interesting.. so if the same line have to be repeated, you could simply movem.l a couple of times, and have it repeated?

Also the idea with using move.l to plot the sprite and mask, and then blit it on to the screen is pretty brilliant.

btw: i love that there is some small updates in this thread.

[britelite]

Originally Posted by LaBodilsen

Sounds interesting.. so if the same line have to be repeated, you could simply movem.l a couple of times, and have it repeated?

Not even that, but just copying+masking the column again with the blitter. No extra cpu-work needed

[LaBodilsen]

Originally Posted by britelite

Not even that, but just copying+masking the column again with the blitter. No extra cpu-work needed

ofcourse... and not even masking, if you are rendering horizontal, as with the walls.

[britelite]

So, during the weekend I implemented sprite rendering to the engine, using the method I described earlier. For z-buffering I'm cheating a bit and only compare the sprite vs wall (or sprite vs sprite) height, instead of the actual distance, as both wall and sprite elements are 64 pixels high. This could lead to some small priority bugs if a sprite is very close to a wall, but that can be remedied by not allowing sprites too close to walls

Regarding performance I haven't done any real measurements yet, but everything was still running nicely with a few sprites on screen.

Next up are all the boring bits like game logic, enemy AI, and so on. Should I maybe start a new thread for that, and only write up any possible graphical ideas and optimizations here?

[hooverphonique]

Originally Posted by britelite

Next up are all the boring bits like game logic, enemy AI, and so on. Should I maybe start a new thread for that, and only write up any possible graphical ideas and optimizations here?

That sounds like the way to go, considering this thread is about rendering

[britelite]

Originally Posted by hooverphonique

That sounds like the way to go, considering this thread is about rendering

Indeed, and it's not like I'm that interested in commenting on the boring parts anyway

So yeah, I think I'll write updates here only if I come up with improvements regarding the rendering itself (and I actually have a few tricks in mind I'm going to try out).

[Marchie]

Just tried this on a 1000, it's astonishing how smoothly it runs, amazing work!

[zero]

Any chance someone could capture and do a YouTube video?

[britelite]

Originally Posted by zero

Any chance someone could capture and do a YouTube video?

Would be quite a boring video, I'd say

Anyway, it should run just fine on an A500 config in UAE.

[zero]

I guess WinUAE is pretty accurate these days, in terms of cycle exact A500 speed.

[britelite]

Anyone interested in the current state of the game should take a look at the game dev competition at the Revision 2019 demoparty tonight

[rothers]

Originally Posted by britelite

Anyone interested in the current state of the game should take a look at the game dev competition at the Revision 2019 demoparty tonight

Awesome. I'm so excited about this from a tech perspective!