ZDoom

It doesn't like 3D sectors at the moment

Spoiler:

---

I am aware of this - and actually, after playing with the masking drawers (sprites and stuff) I think I have a theory as to why, but it may be some time before I'm able to pin that problem down. I'll add it to the list of known issues, though, thank you for reporting that.

If you don't mind me asking - what mod is that?

Eruanna wrote:I am aware of this - and actually, after playing with the masking drawers (sprites and stuff) I think I have a theory as to why, but it may be some time before I'm able to pin that problem down. I'll add it to the list of known issues, though, thank you for reporting that.

If you don't mind me asking - what mod is that?

Mr. Smiley Head's Safari II
A mod of mine.
You can find it here: http://forum.zdoom.org/viewtopic.php?f=19&t=47836

Will check it out later. Thank you.

I'll look into the 3D floors thing again now that I know somewhat more about how the drawers work after spending hours on them yesterday.

This project is extremely cool.

Eruanna wrote:

Nash wrote:So this is basically "GZDoom for people who can't run the latest OpenGL", am I understanding this correctly... ?

It's still ZDoom's software renderer - just with Truecolor changes. Eventually, I am hoping to make it into something that is compatible with GZDoom.

Does that mean that at some point GZDoom might support both OpenGL and Software render?

LkMax wrote:

Eruanna wrote:

Nash wrote:So this is basically "GZDoom for people who can't run the latest OpenGL", am I understanding this correctly... ?

It's still ZDoom's software renderer - just with Truecolor changes. Eventually, I am hoping to make it into something that is compatible with GZDoom.

Does that mean that at some point GZDoom might support both OpenGL and Software render?

You mean QZDoom, right?

All of these letters get a bit confusing

LkMax wrote:Does that mean that at some point GZDoom might support both OpenGL and Software render?

GZDoom already supports ZDoom's renderer. This project is no different - just the software renderer supported happens to sport 32-bit color.

If you are asking what I meant by that post - admittedly, I was probably half-asleep when I typed it so it's pretty vague - I meant I was hoping to backport some features (models, skyboxes, and dynlights) to the software renderer - where they'll all look really cool with 32-bit.

Right now it's just a wish list though - I gotta get everything working right, first.

New version out. Heretic/Hexen skies now show.

Gonna try this one later with Blade of Agony and Gore, I am pretty curious

I can almost guarantee you Blade of Agony won't look well on it. But I'll tell you - it is my goal one day to be able to run Blade of Agony using QZDoom's software renderer.

I've never tried Gore, though.

I think the next thing I am going to do (if I don't rack my head against the wall trying to figure out how to get true-color sprites working...) is figure out a good algorithm to get skyboxes working, as that was pretty big on my hit list and it's actually very simple (just a few trigonometric functions, but I have to figure out what they are first and test them).

After that, getting GL lighting is next. Those two things will make mods like Unloved, Sapphire, Stronghold, and a few others compatible. I can't promise GL lights will run smoothly on all systems, though, given the huge amount of calculations required per-pixel to make them work. I might write a shader to offput some of the calculations from the CPU but then you'd need a compatible GPU that would support them (luckily, most can run simple shaders like that rather well).

EDIT:

Well - I guess Blade of Agony is not a TOTAL shipwreck... but I think QZDoom still has a long ways to go for it.

Very very interesting. I'm looking forward to see how this port develops. Would be really awesome to be able to see all the GL features (lights, models, skyboxes) implemented into the software renderer... harkening back to the days of old with the Half-Life or Unreal engine software renderer. :P Who knows, if QZ becomes full-featured and stable enough, I might even consider switching fully... :D

I'm flattered, Nash. But you should know, unless dpJudas does the models (and if he does he'll probably have different plans for them), I have two plans for them, the first one being far more likely:

The existing voxel code simply converts voxels into sprites. That's how the build engine did it - and that's how I was going to do models. Obviously, that means that models will not properly clip each other - an object that is in front of another object will always be rendered first - even if the object behind is bigger. (You get a bit of a "sink-in" effect due to lack of z-buffer checking)

Another way to do models is to do them as a completely separate pass - creating a z-depth buffer during Doom's render pass (probably just creating it with the various column functions) and overlaying a Quake-style model renderer on top of it (which would have full z-buffer support, and would be more akin to like how Half-Life did it way back in the day).

There are advantages to both methods - the first method is way easier, first and foremost, and it's also likely that it will render a lot quicker.

Back when kgsws did his 3D floors submission, I remember I was in chat with Blzut3 about how to get 3D floors working without clipping existing geometry. The problem with kgsws's 3D floors at the time (which was a problem later solved by someone else [Randi?] which became the final implementation, still a complete mystery to me how) was that they would appear in front of walls or sprites. One obvious solution would be to render everything to a z-buffer and clip the 3D floors based on that.

Well - Blzut3 did exactly that, fully. The problem was - ZDoom's frame rate dropped by half, if not more, when he did it. That's why I am a bit weary of implementing the second solution for models.

So - because of that, I don't know if this project will ever be a good replacement for GZDoom.

Eruanna wrote:I can almost guarantee you Blade of Agony won't look well on it. But I'll tell you - it is my goal one day to be able to run Blade of Agony using QZDoom's software renderer.
EDIT:

Well - I guess Blade of Agony is not a TOTAL shipwreck... but I think QZDoom still has a long ways to go for it.

Lol I assume that's an old build of Blade of Agony because I removed all Doom inheritances or sprites in general for 3d models... But surely it looks good...

Btw keep up the good work Eruanna! (Still didn'thad the time to try this new port )

Eruanna wrote:GZDoom already supports ZDoom's renderer. This project is no different - just the software renderer supported happens to sport 32-bit color.

If you are asking what I meant by that post - admittedly, I was probably half-asleep when I typed it so it's pretty vague - I meant I was hoping to backport some features (models, skyboxes, and dynlights) to the software renderer - where they'll all look really cool with 32-bit.

Right now it's just a wish list though - I gotta get everything working right, first.

Uh, do you have to edit a ini file or something? Because AFAIK there's no option on the menu to use software render.

Gamer With Dignity wrote: You mean QZDoom, right?
All of these letters get a bit confusing