new amiga 500 doom like !

[KK/Altair]

The path through native Amiga FPSes is a sad one in places, scattered with forgotten and abandoned programming projects...

True. That's why making something actually playable floated to the top of my list leaving e.g. variable height floors behind.

Your "think out of the box" to make FPS games run better on Amiga, is just amazing.

I'm rather feeling like I'm picking ideas from wherever available and adding tiny bit of my own. But the latter is really a tiny bit compared to the ideas of others I'm using.

This statement above pricked my interest. If the engine allows a player to freely walk around a 3D environment so you have a view in any direction from any point how is it possible to precompute this? Surely there are thousands of possibilities hence why games like Duke3D do this calculation real time.

The core component of the map is a sector - a convex fragment of a map where camera can potentially be. Each sector is surrounded by walls and other sectors. Because sectors are convex, and all walls are 1-sided, we can algorithmically find all walls, that can be seen from at least one point within the sector. These walls are then ordered in such way, they always appear in correct front-to-back order when viewed from any point within the sector. So, starting from the walls attached to the sector in question, they are sorted kind of radially from closest to furthest by considering all potential occlusions. In the end, we need just one wall list per convex sector.

My current map has 344 sectors, which get cut into 411 subsectors (if it . There are 1230 lines in the map, and up to 133 lines visible from a single point of view, but much less on average. Each subsector requires a list of visible lines, and each line on this list takes two bytes (16-bit number). Ultimately, the raw visibility data takes about 64kB. Still quite a lot, and I have plans to optimize it (e.g. by grouping lines that usually get shown together), but current solution is good enough for now.


TL;DR: Thousands is something we can manage.

In other words, the amount of work involved in transforming vertices and moving actors etc increases massively, while the c2p work stays the same.

That would be the case if the amount of work did grow. But on a fixed platform like Amiga, it does not because we have to keep reasonable framerate.

[d4rk3lf]

Originally Posted by KK/Altair

This engine has nothing to do with Wolf3D, which used raycasting. Even the engine in Wildcat demo didn't use it. Raycasting is generally straightforward, but polygon rendering is much, much faster.

err... it's a noob question, but I must ask.
If polygon rendering is so much faster, why all wolf3D/Doom clones for Amiga used raycasting method?

[KK/Altair]

If polygon rendering is so much faster, why all wolf3D/Doom clones for Amiga used raycasting method?

I don't know how exactly these engines work internally. I made raycaster first for Wildcat demo and optimized as much as I could. But when I tried deferred* polygon rendering, my first rough pure C implementation was as fast as the optimized raycaster, so it was an immediate winner.

One major strength with raycasting is that you don't need any visibility data, because it emerges naturally. And you need fairly good visibility information for drawing polygons. Also Wolf3D made raycasting famous, so everybody might just try it first because of that.

*) I don't draw polygons as-is. They get "drawn" to a scanline buffer storing scale & texture information for each screen column. Because of that, drawing polygons is very cheap, and final pass draws only pixels really visible.

[sandruzzo]

Polygons in a game as Wolf3d, can be precalculated, so in realtime you don't need to rotate them. You can merge edge and doing stuff like this. I did some test on A500 AND they are very fast.

[britelite]

Originally Posted by sandruzzo

I did some test on A500 AND they are very fast.

How about you show us your results then?

[sandruzzo]

Originally Posted by britelite

How about you show us your results then?

was only fast test, to see if it would be possible. No cp2, only pure bitplane. I did that test just to inquire some my speculations, since all wolf3d world is orthogonal and a lot of calculations can be precalculated.

[britelite]

Originally Posted by sandruzzo

was only fast test, to see if it would be possible. No cp2, only pure bitplane. I did that test just to inquire some my speculations, since all wolf3d world is orthogonal and a lot of calculations can be precalculated.

I bet you did

[sandruzzo]

Originally Posted by britelite

I bet you did

The only possible problems with polygons,isto find a fast way to avoid overdraw. And I was thinking about s-buffer for example

[britelite]

Originally Posted by sandruzzo

The only possible problems with polygons,isto find a fast way to avoid overdraw. And I was thinking about s-buffer for example

How about you precalculate a suitable stream to show off your rendering techniques?

[sandruzzo]

Originally Posted by britelite

How about you precalculate a suitable stream to show off your rendering techniques?

So far I used only blitters' line. I can give you my "simple" test. I've stopped it cos other projects.

[britelite]

Originally Posted by sandruzzo

So far I used only blitters' line. I can give you my "simple" test. I've stopped it cos other projects.

So you haven't even done any texture mapping yet? That figures...

Anyway, enough off topic for my part.

[britelite]

Originally Posted by KK/Altair

One major strength with raycasting is that you don't need any visibility data, because it emerges naturally.

Yeah, it's pretty straight-forward getting started with a raycaster, and you don't need any preprocessing. But as you said, it will hit a wall regarding performance at some point.

EDIT: Oh, and really nice work with your game engine. It's also great to see you putting making a good game before adding tons of new features. And now I don't need to finish my wolf3d-clone

[sandruzzo]

Sorry but my idea was to do 1*1 polygons not 2*2 or worse textured...

[malko]

Originally Posted by britelite

[...] And now I don't need to finish my wolf3d-clone

Tss, tss, tss
It's like saying you don't need to finish <put anything here> because others already have finished something similar

[britelite]

Originally Posted by malko

It's like saying you don't need to finish <put anything here> because others already have finished something similar

I was of course joking.

Fortunately while the two games will kind of look similar (with KK's of course looking more advanced), the approaches are way different, which still makes it interesting for me to try out some ideas. And will probably also make for two games with quite a different feel and gameplay.

[malko]

^

[KK/Altair]

Polygons in a game as Wolf3d, can be precalculated, so in realtime you don't need to rotate them. You can merge edge and doing stuff like this. I did some test on A500 AND they are very fast.

From my experience, you have to at least do 2D rotation/translation and Z-clipping. Unless you are making a demo and precompute them for every frame. But their count is fairly limited, so that generally shouldn't be a bottleneck, anyway.

The only possible problems with polygons,isto find a fast way to avoid overdraw. And I was thinking about s-buffer for example

That's exactly what I'm doing in Wildcat. See the '*' annotatrion on my last comment.


Basically, for every screen column I store:
- drawing scale - a 1..50 number in Wildcat,
- texture & X texture coord - can be a data pointer, or just a coord (if you glue your textures together)


This way polygon rendering just has to write one entry to the buffer, making overdraw negligible. Rendering order also doesn't matter, because scale is already kind of Z-buffer (bigger scale = closer object). The scale can also later be used in this matter for obstructing sprites. The pixel crunching is done in later pass.

But as you said, it will hit a wall regarding performance at some point.

It didn't really hit the wall (no pun intended ) when it comes to the performance, because it already was better than anything I've seen on A500 as a kid (Citadel, Behind the Iron Gate, Death Mask). Just my crappy C polygon implementation made my asm-optimized assembler raycaster sad by having the same performance.

EDIT: Oh, and really nice work with your game engine. It's also great to see you putting making a good game before adding tons of new features. And now I don't need to finish my wolf3d-clone

Thanks! And yes, you do! Especially that by keeping features on Wolf3D level you can have better performance than me. And coppershaded floors & ceilings. Just switch to polygons & s-buffer if you didn't already.
Too bad it didn't get more recognition at Revision.

Fortunately while the two games will kind of look similar (with KK's of course looking more advanced), the approaches are way different, which still makes it interesting for me to try out some ideas. And will probably also make for two games with quite a different feel and gameplay

Yes, Tomek R. made me aware of some optimizations you did with long moves. Did you measure the exact performance of your engine?

[sandruzzo]

Rotation can be precalculated as Projection. At least the latter can be very fast since you don't have a lot of them, and just by merging edge, since a lot of walls share the same. That's what I did with my tests. And even clipping can be fast since guard band clipping

[britelite]

Originally Posted by KK/Altair

Too bad it didn't get more recognition at Revision.

Yeah, well we have ourselves to blame here, as the presentation wasn't really that good (for example, we forgot to add the background ambience sounds).

Yes, Tomek R. made me aware of some optimizations you did with long moves. Did you measure the exact performance of your engine?

I've only measured the performance for the rendering portion (with precalculated raycasting), and I'm quite satisfied with that. But the raycaster isn't complete, so haven't made any measurements on that part yet.

[KK/Altair]

Rotation can be precalculated as Projection.

Care to elaborate?

At least the latter can be very fast since you don't have a lot of them, and just by merging edge, since a lot of walls share the same.

That's one of the first things you do when drawing polygons, although I only merged walls up to 6 tiles in length - after this point, the guard band clipping broke in extreme cases. Also you can share vertexes to have a few rotations less, but this is a really minor perf boost that gets shadowed by the cost of drawing scaled textures later.

And even clipping can be fast since guard band clipping

Yes, clipping sides just by limiting drawing range worked nice for Wildcat, but I moved away from it in the new engine. With fixed horizontal FOV of 90 degrees the side clipping planes in camera space just become x=y and x=-y, which are quite simple to clip. I do this, because I had major texcoord interpolation precision problems on long walls passing near camera - they visibly jumped around with minor camera rotation. Also by clipping lines before actual drawing I make them shorter and more likely to use the linear interpolation path - because I decide whether to interpolate texcoords perspective-correct or linearly in runtime based on expected error (and most of the time, I can get away with linear interpolation).