Would a hardware-accelerated renderer ever be added?

I was wondering the other day, would a GL renderer be added to Eternity? The only reason i don't use Eternity much is it's lack of OpenGL renderer, yeah i know i'm a freak for liking that vaseline-o-vision trilinear filter and maybe dynamic lights if they happen.

I don't like Pr/GLBoom for some reason, i just can't stand how it feels overall, but Eternity is awesome yet lacking a hardware renderer which IMO would be fantastic. I just hate how horrible the colors are in software mode, Pinkies becoming brown/grey with distance, banded lighting, and other things that make the software mode just look ugly.

I wonder, it hasn't been done just because no one seems to want it (I mean, Eternity being basically "ZDoom for old-school Doomers") or just because no one has made it?

I've been talking with @Altazimuth about stuff a while ago, including the addition of a GL-render in Eternity, but as it currently stands it is unlikely to happen, or not in the foreseeable future anyway.

They have limited time and resources on their hands.

The age old problem of not having enough coders to do all the work.

Yeah i imagined it was something like that. I was asking because i wasn't really sure if it was because it conflicted with the project's goal, or something to that effect.

It would be nice if at least they could add the GLBoom renderer or perhaps GZDoom 1.8.4's renderer, but maybe that is a lot of work too.

I'd like a potential hardware renderer to look as close as possible to a true colour software renderer. But based on what I've seen so far, I suspect that's a very tough task. Sadly I have next to no experience with hardware graphics, and the prospect of Mac graphics library shenanigans looks scary.

I agree we'll lose Boom TRANMAP along the way, so we'd have to prepare a replacement. I guess that's called "shaders".

6 hours ago, printz said:

I'd like a potential hardware renderer to look as close as possible to a true colour software renderer. But based on what I've seen so far, I suspect that's a very tough task. Sadly I have next to no experience with hardware graphics, and the prospect of Mac graphics library shenanigans looks scary.

 

I agree we'll lose Boom TRANMAP along the way, so we'd have to prepare a replacement. I guess that's called "shaders".

I'm not exactly a programmer either but i can tell you it's doable but likely costly and would require OpenGL 2.0 if you are willing to make a couple hacky tricks to get the perspective the same.

Even then, i feel that's really pointless because one of the things that the hardware renderer is prefered instead of the software renderer is the removal of the viewport distortion when looking up and down.

1 hour ago, -TDRR- said:

Even then, i feel that's really pointless because one of the things that the hardware renderer is prefered instead of the software renderer is the removal of the viewport distortion when looking up and down.

I'm not talking about that, I'm talking about the light levels and diminishing which I want to preserve.

Dunno how to best handle billboarding, that's unsolvable 100% if we use sprites in a 3d engine... 

12 minutes ago, printz said:

Dunno how to best handle billboarding, that's unsolvable 100% if we use sprites in a 3d engine... 

Perhaps look at how GZDoom did it?

Anyway, I think adding a GL render at some point in the future is totally worth the effort, provided that you guys do get to it eventually. Considering that maps are getting bigger and more complex by the day, there will inevitably come a day when Eternity's SW render will no longer be enough (not to mention stuff that simply doesn't work in SW). Without a solid GL render in place Eternity might never grow in popularity. Lack of GL rendering is the main thing preventing me from using it as often as I would like (well, best of luck trying to get maps like Sunder's new levels running in SW... ).

1 hour ago, -TDRR- said:

the removal of the viewport distortion when looking up and down.

A GL renderer can do the same shearing type of freelook as the SW renderer.

I once modified a Quake GL renderer to do shearing like that, using it felt pretty weird at first but after a while you get used to it and don't notice it that much, except when trying to look far up or far down (e.g. to shoot one  of those buttons in the ceiling) since I limited it to 45 or 60 degrees or so.

10 hours ago, printz said:

I agree we'll lose Boom TRANMAP along the way, so we'd have to prepare a replacement. I guess that's called "shaders".

Do you really need full support for it? Aside from some occasional demo maps it hasn't ever been used for anything more than setting a translucency factor (i.e. setting PrBoom to the given factor, let it generate a TRANMAP and rename it.) and for that some simple analyzer is good enough to create an alpha factor for the software renderer.

Trying to do this with shaders isn't really going to work out, because shaders cannot read from the buffer they write to - and that's what you'd need when blending a color with the background - not to mention that a shader will operate on True Color values, not palette indices. If it was that easy I'd have added support for full TRANMAP a long time ago, but unfortunately the blending stage is still not programmable on modern hardware.

For general mapping purposes you are better off anyway to do it like ZDoom and create translucency maps on the fly from a given factor and not use pregenerated resources as the only means to achieve it.

42 minutes ago, printz said:

Dunno how to best handle billboarding, that's unsolvable 100% if we use sprites in a 3d engine...  

It's a big problem, you could do it like StrifeVE but that'd cause a bootload of other follow-up problems, especially when handling portals the depth buffer is a vital component and an approach that avoids its use most likely won't work that well.

26 minutes ago, seed said:

Anyway, I think adding a GL render at some point in the future is totally worth the effort, provided that you guys do get to it eventually. Considering that maps are getting bigger and more complex by the day, there will inevitably come a day when Eternity's SW render will no longer be enough (not to mention stuff that simply doesn't work in SW).

This also shouldn't be forgotten. A software renderer will inevitably be limited to smaller screen sizes.

26 minutes ago, seed said:

Without a solid GL render in place Eternity might never grow in popularity.

I think for many users coming from more recent games, that paletted and banded look is something they are not accustomed to and really don't like.

Just now, andrewj said:

A GL renderer can do the same shearing type of freelook as the SW renderer. 

 

I once modified a Quake GL renderer to do shearing like that, using it felt pretty weird at first but after a while you get used to it and don't notice it that much, except when trying to look far up or far down (e.g. to shoot one  of those buttons in the ceiling) since I limited it to 45 or 60 degrees or so.

The main question is: Do people really want this or is it just a limitation they begrudgingly accept as an inherent limitation?

10 hours ago, printz said:

I'd like a potential hardware renderer to look as close as possible to a true colour software renderer. But based on what I've seen so far, I suspect that's a very tough task. Sadly I have next to no experience with hardware graphics, and the prospect of Mac graphics library shenanigans looks scary.

A true color based software renderer, if done correctly, will look just like hardware rendering without texture filter and proper tilting. Just have a look at the smooth lighting gradients in GZDoom's. Unless you look up and down it'll nearly be the same as the hardware renderer when using software-emulated lighting mode.

Regarding Macs, the only way forward is to use Vulkan, never mind that it's not a great API to work with with all those synchronization objects that are needed.

OpenGL on Mac is shit already and nobody is going to do a Metal port.

Also, writing a complete hardware renderer from scratch isn't going to be easy. Setting up a basic renderer isn't too hard, but what costs time is to implement all the special things Doom has to offer, like render hacks, properly positioning sprites and having to recreate the scene every frame - and optimizing the whole thing.

You'd be better off to take an existing renderer and make the needed adjustments to it instead of reinventing such a gigantic wheel.

I am just your average player but I have the following things to say:

- I think a GL renderer would do wonders for Eternity (I am not forcing u guys to add it, I just wish it would happen one day). One of the main reasons why I use PrBoom+ over Eternity is the lack of GL renderer in the latter.

- I don't mind the sprite billboarding much and I don't think fixing it (like in StrifeVE) would be worth it if there is too much hassle involved.

- GZdoom's hardware renderer and true-color software renderer look almost identical. Which is why I would prefer going for a hardware renderer over a true-color SW renderer because performance would be much better in former + no view distortion.

Most of the Eternity developers work at NightDive now, which is good for them, but doesn't leave them with much time to work on Eternity.

6 hours ago, Graf Zahl said:

I think for many users coming from more recent games, that paletted and banded look is something they are not accustomed to and really don't like.

It's not what I meant at all though, I was bringing that up because GL rendering is extremely important with all the new complex maps coming out that the SW renderer simply doesn't handle well, or at all in some cases. GL rendering is much faster as well on those maps to the point a comparison is pretty much pointless.

Also @printz, I think Graf has a very good point. You're better off taking an existing render and modify it to suit Eternity's needs. I would recommend using GlBoom's because it's by far the fastest at the moment (I think?) even though it's using an older OpenGL version than GZDoom's. It might be worth a shot.

I'm not sure GLBoom's render code is really faster than GZDoom's render code. It's well-known that actor processing is where GZDoom's performances suffer the most, the price to pay for all the extra modding features it brings. An example of that is how maps like Nuts are very smooth in GZDoom until you wake the monsters up and then it becomes a glacial slideshow. Very often when I had slow performances in GZDoom, using the console and typing "freeze" to skip over most actor processing resulted in an instant return of smooth FPS. I wouldn't be surprised if GLBoom+ with GZDoom's renderer would get even better performances; of course adapting the renderer from one codebase to the other isn't going to be easy so I doubt anyone will bother testing this.

The renderer *is* faster (on my system, compiled with the same VC compiler, Frozen Time's bridge scene is 60 fps on GZDoom (with multithreaded processing) vs. 75 fps with GlBoom. I haven't done detailed profiling, but the most likely cause is that the GLBoom renderer doesn't have a few things that cost a bit of time on GZDoom, like offscreen rendering. When this was introduced it caused a 5 fps frame rate dip on my system and it required the multithreaded render list generation plus Vulkan do get back that bit of performance.

Playsim think time is not nearly high enough on that map. I'll have to add some genuine profiling code to GlBoom to find out what part precisely is causing the difference.

3 hours ago, seed said:

Also @printz, I think Graf has a very good point. You're better off taking an existing render and modify it to suit Eternity's needs. I would recommend using GlBoom's because it's by far the fastest at the moment (I think?) even though it's using an older OpenGL version than GZDoom's. It might be worth a shot.

I don't really think that the speed advantage can be kept with Eternity. Raw speed isn't anything, you'll also need a roughly compatible feature set. Let's not forget that Eternity requires both slopes and portals which GLBoom does not have. The portal code in particular is a very complex thing because of the complex obstruction checks that can occur with portals. It also doesn't have any dynamic light code.

AFAIK the biggest thing GZDoom lacks over Eternity in rendering features are edge portals (they are a bit tricky with hardware clipping as they can cause nasty recursion cases if not handled properly.)

23 minutes ago, Graf Zahl said:

AFAIK the biggest thing GZDoom lacks over Eternity in rendering features are edge portals (they are a bit tricky with hardware clipping as they can cause nasty recursion cases if not handled properly.) 

Pretty sure you explicitly said years back GZDoom wouldn't get them anyway, and I can see why. 3D floors eradicate the need for them. Anything a combo of 3D floors and portals can do can be done with edge portals and 3D floors, and given GZDoom's polygonal renderers there's no particular downsides to 3D floors over edge portals.

9 hours ago, Graf Zahl said:

You'd be better off to take an existing renderer and make the needed adjustments to it instead of reinventing such a gigantic wheel.

Eh. I'm not sure. Using an existing implementation reduces work but also makes for lots of compromises and requires inheritance of all sorts of whatever legacy crap that GL renderer has. I'd rather learn from and improve on the GL renderers of old than just just drop them straight in. I wanna see a GL renderer that does limited computation triangulation of scenes based solely on things that update! We can make the wheel better, but sometimes that means reinventing it just to get away from the older ones.

In other news I'm going to toy with an improved render-to-texture GL renderer that should be faster. I've not had time to do so the past few days, but hopefully soon I'll have time to implement it. It'll likely be GL2.1, but that doesn't mean þe olde renderer is going away since every user counts and I don't wanna lose compat with even the most rotten of potatos. It  should just improve a certain constant (based on screen size) performance bottleneck.

I agree a hardware renderer would be great for highly vertical maps. But I dislike how it handles Doom skies though. Many things in Doom weren't designed for true 3D, it seems. Personally I like the software renderer too. Stuff @dpJudas did to QZDoom and @SoM to Eternity seems fascinating.

Back to the subtopic of TRANMAP: here's an example: I made a ghostly demon with highly translucent skin and additive blending eyes. I guess this kind of stuff is better done in hardware rendering by using per-picture alpha channels and other such channels. What I want is to let the user define their own mathematical formulae, instead of limiting them to a preset of hardcoded engine features (which would solely depend on developers to extend). Speaking as an outsider, I don't know how practical it is. But it would be an evolution over TRANMAP, instead of axing it in favour of basic blending presets. And I want the same kind of evolution to be done over vanilla custom COLORMAPs too. I really liked that experimental vanilla wad which reversed the light fading, so I'd like to see that in more advanced renderers too. Don't tell me it's impossible or impractical until I see it done.

I’m more interested if Eternity fully supports Heretic, which not every port can do.

Give me:

- Complevels.

- Level stats.

- Level skipping (holy shit I see on a github commit that -warp with level names is now a thing, we're getting there).

- Map restart/pistol start.

- Adjustable/vanilla style message positions.

- Toggleable coordinates on the automap.

- Better organized menus + clearable key bindings (a la PrBoom+ 2.5.1.5 or ZDoom, whatever floats your boat).

- 64-bit devbuilds with a compatible midiproc.exe. Obviously the one that ships with the 32-bit stable, "official" version of 4.00.00 Voluspa doesn't work. Also, snes_spc.dll is missing from both 32-bit and 64-bit devbuilds, same story as midiproc.exe, probably.

- OpenGL render.

- Heretic & Hexen support.

- Probably other things @Altazimuth already knows about.

And I am sold to Eternity forever.

40 minutes ago, printz said:

 What I want is to let the user define their own mathematical formulae, instead of limiting them to a preset of hardcoded engine features (which would solely depend on developers to extend). Speaking as an outsider, I don't know how practical it is. 

Sadly with current hardware, not at all. The limiting factor here is the blending stage which is not accessible to shaders and only offers very limited configurability.

I guess we can only hope that eventually this will become programmable as well - it'd really open up a completely new category of rendering effects if the blending could be controlled per pixel. This is basically the last remaining part of the render pipeline that isn't programmable...

1 hour ago, Altazimuth said:

Eh. I'm not sure. Using an existing implementation reduces work but also makes for lots of compromises and requires inheritance of all sorts of whatever legacy crap that GL renderer has.

What do you consider "legacy crap"? Old OpenGL version support or handling some arcane engine features?

47 minutes ago, Altazimuth said:

 I wanna see a GL renderer that does limited computation triangulation of scenes based solely on things that update! We can make the wheel better, but sometimes that means reinventing it just to get away from the older ones.

Trust me, you'd be surprised by how little you gain here. I got more juice out of just multithreading the setup, once I manage to multithread the render list generation as well the entire issue will no longer consume any relevant time and can fully run in parallel to the BSP traversal. You can't skip the BSP traverser because that's the only means to collect the needed portal information, and this needs to be kept as low as possible because too many portals can really drag down performance because they can cause render pipeline stalls with their stencil manipulation.

Actually, one of the biggest time wasters in the renderer is cache misses in the clipper, again something you cannot skip because this defines what parts of the automap are visible.

Think about it: We got several GL ports out there that tried to go the route you describe, and they are generally the slowest of the bunch - the main reason that the added data produces far worse CPU caching behavior.

Also, perfection has always been the greatest enemy of something good. I don't know how often it happened with ZDoom that something good was pushed to the wayside because something better was supposed to be in the pipeline, and often that better thing never materialized for all sorts of reasons, either because it turned out unfeasible or nobody had the time to make it work. Do you have the time to write a new renderer from scratch that works completely differently than everything that came before?

Not even GZDoom did that: The renderer grew out of PrBoom's - it just got extended and streamlined over the years and actually modernized. It still took me 3 years to get it ready for prime-time, that happened between 2002 and 2005.

53 minutes ago, Altazimuth said:

It'll likely be GL2.1, but that doesn't mean þe olde renderer is going away since every user counts and I don't wanna lose compat with even the most rotten of potatos.

For copying the software canvas to the hardware, this is perfectly fine - but once you do true hardware rendering, those rotten potatoes will really make your life miserable when it comes to a performant render setup on better hardware.

This was what actually caused the split of GZDoom into modern and vintage last year - an optimzation that brought significant performance improvements on any modern and semi-modern hardware made the frame rate tank on those "rotten potatoes". Trying to maintain both code paths in the same executable would have been a mess.

56 minutes ago, printz said:

And I want the same kind of evolution to be done over vanilla custom COLORMAPs too. I really liked that experimental vanilla wad which reversed the light fading, so I'd like to see that in more advanced renderers too. Don't tell me it's impossible or impractical until I see it done. 

That part can be done in the shader easily. However, not quite feasible on GL 3 hardware, it's just not fast enough for such complex per-pixel operations. When I was still using a Geforce 8600, that system was seriously struggling with software lighting emulation.

12 hours ago, Altazimuth said:

I wanna see a GL renderer that does limited computation triangulation of scenes based solely on things that update!

i am with Graf here: this won't give you any noticeable improvements on small-to-medium maps (most such maps can be completely uploaded to GPU, and GPU will render them without any special visibility culling with 60 FPS). and on huge maps, you'll burn your CPU doing the work that can be done offline, for no gain at all.

ok, there can be one gain: dynamic changes of sector shapes. while this may sound attractive, it opens a huge can of worms. also, BSP tree is used in other parts of the engine too, and you have to keep it up to date (i.e. rebuild for any geometry change). or rewrite the whole engine to use some other spatial structures, but then say goodbye to vanilla demo compatibility.

also, triangulation of doom maps is not that easy. many maps has unclosed sectors, for example (even some id maps). and sectors can have holes. properly triangulating such polygons is expensive.

i am still thinking about implementing such mode in k8vavoom, to allow in-engine map editing, but even if i'll do that, it will prolly be a special "developer" rendering mode. i won't dare using it as a main renderer.