Then I guess using 3D models is OK for "Doom" category, right? Chasm may be good example of raycaster that used this approach.

You do realize that Doom was 3D, right? It wasn't a raycaster, it actually drew the polygons. Shocking!

Just sayin'! You could do it as a raycaster just fine, but just sayin' the original Doom wasn't a raycaster.

You're partly correct and partly incorrect! From my understanding, drawing is overwhelmingly a front to back BSP draw but that individual wall polygons are drawn (where visible) using a trigonometric method derived from ray casting. Ditto for the placing of textures onto floors which are converted into horizontal scans, their depth computed using a ray casting method.

Conversely, I'm under the belief that Duke Nukem is a fully ray cast engine although there appears to be some controversy about that and it may be a portal/polygon derivative which draws in a Doom style.

The locations of non-static objects can only be fully specified by three scalars. Think of, e.g. running off a ledge at different speeds.

Your question wasn't "what makes a 3d engine?" it was "what do you think made doom a 3d engine?". That is what I believe makes Doom a 3d engine for most people.

You can do first rendering pass rendering to Z-buffer only (which can't be counted as 'drawing' ) and do actual drawing in second pass with zero overdraw. Z-buffer operations are heavily optimized on GPUs, so this can make things work faster.

You have to render floors and ceilings in rows instead of columns (and Build engine was of course doing this). Well, you can render them in columns, which makes things easier, but also really slows everything.

I've implemented raycaster in which you can see them at once (ray is split, one part is rendered and the second one remembered to be rendered later).

In Doom, no, but in later games running on Doom engine (Heretic, Hexen, etc.) I think it was possible. And even in Duke you can't really look in any direction I'd call 'up' or 'down'.

That's good because my entry is likely to be based on a similar thing at the very root and it is nice to know that the same sort of algorithm has been proved to be suitably efficient when correctly implemented.

But it is something that Descent achieved with full 6DOF levels!

I'm always amazed at quite how many tutorials advocate drawing in columns, although I suppose it is substantially easier.

This was implemented into later Build engine developments by various different developers. It was definitely in Blood, which also had voxel sprites for enemies.

Yep. And I think Duke3d invented that. There's certainly a bitchy comment somewhere on Ken Silverman's website about how he implemented that then two days after he showed it off the same thing had mysteriously turned up in ROTT. It's a shame nobody ever showed the ROTT people a fun game, or they might have put some of that in too!

Descent achieved this with a similar(but 3D) algorigthm. I think it was near zero not actually zero.

I second that.

Here's an idea for somebody. Make a Duke Nukem 3D engine but turn it on its side so the walls become the floor and do a first-person Sonic the Hedgehog game. I've tested this and gained %150 extra framerate due to improved cache usage from rendering horizontal lines.

Since this seems to be the main thread on the topic... I haven't had time to read it, but I've read the wiki page. Anyways, are there any expected limitations of source package size? I have an interesting idea, but I don't know how small I can make the php source package get

Oh, and what about a "Most original" award for best abuse of the rules?