DRD Team

dpJudas wrote:

120 FPS and diminishing light. :D

Amazing! Add dynamic lights and models, and we have ourselves a Quake renderer... ;D

(Just kidding)

Gez wrote:I hope this won't suffer from GZDoom's "hey this subsector is technically behind the camera so why render it" issue at steep pitches because it always annoys me to see slivers of sky suddenly appear just because I'm looking at the floor or the ceiling.

Ah crap, I had hoped I could loot the solution to that issue from GZDoom's BSP walking.

This should be solvable, maybe by moving the viewpoint slightly backwards for culling would do the trick, or do a 3D frustum culling test against BSP nodes.

If you find the right formula for that problem, be my guest. I had to adjust it multiple times but still wasn't able to determine the pitch at which checking the entire 360° becomes necessary.

-Cool pics.
-To the hell with that image host (it looks like those websites where you try to watch tv online and there are like 1000k popups)
-I'm fine if on the future there's a quake 2 like dynamic light where in software mode there's just White light (and maybe a void one).

Heck, rename Qzdoom to Zdoom 2.0 :p

Didn't Quake use light maps? To me, the terms (in zdoom context) are as follows:

Dynamic lights = movable point lights, as implemented by GZDoom
Light maps = Baked diffuse light multiplier, like in Unreal Tournament and countless other games.
Gouraud shading = vertex coloring, either monochrome or in color
Flat shading = Doom sector light level style
Diminishing light = Doom sector light attenuated by distance to the camera

At the moment, on that list, I only intend to support diminishing light. Not that it really matters as the odds of me finishing this alternative renderer as a solo project are pretty low. I did it mostly out of curiosity, because I already had the triangle drawer and wanted to improve my understanding of some of the parts of GZDoom's rendering.

Eruanna wrote:Is there any way I could convince you not to use that file sharing host in the future? It's one of the ones that doesn't work without Javascript and the forum accepts attachments just fine.

Yes you can, sorry

ibm5155 wrote:-To the hell with that image host (it looks like those websites where you try to watch tv online and there are like 1000k popups)

Changed it to Forum attachments, sorry about that, just used the first Image uploader I could find.

No worries, than you.

Woo! That's damn good at that resolution. Hopefully it will soon be able to handle complex geometry at 70+ FPS.

... Would this also work with the 8BPP mode? I happen to like working with palettes, so it would be pretty nice to have a properly projected 256-color mode.

I have a 8BPP version of the drawer that is uses if swtruecolor is set to false, but it is without light at the moment. The challenge here is to pick the right colormap on the fly - I'm not sure what performance impact that will have.

At the moment I'm a bit stalled on the sky. I added a simple stencil buffer, but that added more problems than it solved. Thinking hard trying to figure out a way to draw them that isn't too expensive..

What you can do is create a second buffer from the sky, use it as a screen-wide texture, and every time you encounter what should be a sky draw from that texture (based on screen coordinates, obviously), instead.

That would also be the best way to handle portals, if/when you get to them.

A stencil buffer sounds like simply a more complicated way to do this exact same thing, really.

That was my initial plan, except I wanted to mark it in the stencil buffer instead. Unfortunately the starting place in E3M1 reveals that this will not work. The reason being that the ceiling actually blocks the view of the entrance in E3M1, but due to Doom's visplane_t way of grouping/floodfilling the ceiling will wrap itself around the entrance wall in a sector further ahead.

The main reason I'm using a stencil buffer, and not creating a full second buffer like you're describing, is a question of performance. Rendering a full second buffer requires drawing additional 1920x1080 pixels, even when you can only see 100 pixels of sky. The stencil method should allow it to skip a lot of drawing as it can quickly determine that most of the sky is not visible. In any case, both approaches gives me the same problem with those damned visplane_t's.

dpjudas, I suggest you to try icarus.wad map14 to get an idea of the work you'll have to do, in particular the following spots:

• start area;
• (800,-2800), the two towers outside;
• (775, -2300), the gate;
• (775, -2300), the gate after you press the switch in (725,700);
• same place, but walk inside the castle, you'll be blocked for some time and other doors open;
• (1600,-150), the door which uses sky hack.

Those were Graf's nightmares years ago in OpenGL implementation ([1] and [2]). So yeah, good luck


References:
[1] http://forum.drdteam.org/viewtopic.php?f=25&t=4748
[2] http://forum.drdteam.org/viewtopic.php?f=25&t=5920

Hehe, I have much more modest goals. Simple things. Like just rendering Doom 1 and 2 correctly.

Yeah I hate to use the phrase "putting the cart before the horse" but in this case I think it applies.

If I can pick up and understand this new renderer well enough, I plan to expand upon and complete dpJudas's work, after he gets it in a state where he thinks it is complete. I think that my support for software rendering of models and lights are going to go into this renderer, rather than Carmack's renderer - a decision that was made easy the moment I saw how quickly dpJudas got this into a playable state. Sure, it's not perfect yet and it has a ways to go but I am truly impressed by just how far it has come so far.

I'd love to get some extra help. Especially when it comes to some of the more higher level stuff where I think you actually know more about the details of Doom than I do. Like right now the texture coordinates are wrong on some of the walls. I'll clean up the code a little bit so it isn't just one big trashcan in a single file.