[REL/FINAL] GZDoom-GPL 2.4 - now with software renderer

[Nash]

Alekv: Is this for your platformer game? I have 2 suggestions

1) Make a very tiny camera texture and attach it to your bunny character, so that it shows a first person view of the entire level. Draw this camera texture off-screen (or with 0 alpha) as a HudMessage. This will force the game to render the entire level, so all the model resources will have to be loaded at once. If updating this camera texture every tic is too slow, then only perform this at the start of the level

2) Make a suggestion to GZDoom for model precaching; if it gets into GZDoom, it will be in GZDoom-GPL.

[Alekv]

Alekv: Is this for your platformer game? I have 2 suggestions

Yes..

1) Make a very tiny camera texture and attach it to your bunny character, so that it shows a first person view of the entire level. Draw this camera texture off-screen (or with 0 alpha) as a HudMessage. This will force the game to render the entire level, so all the model resources will have to be loaded at once. If updating this camera texture every tic is too slow, then only perform this at the start of the level

Thank you, I will try the method .
Only it seems to me that it does not work, I like doing.

2) Make a suggestion to GZDoom for model precaching; if it gets into GZDoom, it will be in GZDoom-GPL.

Unfortunately I grow old faster than waiting in the Official precash = (


Tell me, who has a compiled version of the realties GZDoom-GPL under Win7 x32?
Really want to have a compiled version , he unfortunately can not be compiled for the reasons = (

[Agentbromsnor]

Hell yeah! I would just like to voice my support for this. Seeing (G)ZDoom expanded into a serious game-development platform is something I have been dreaming of for years.

I know there are more 'advanced' engines on the market today, such as Unity, but for me, the ease at which I can develop UDMF maps these days has a much better workflow than any other engine I've used. I also think that ACS code is a lot 'neater' than the typical C# and JavaScript stuff that engines use these days (though I know this is not a popular opinion). Yes, GZDoom is missing a lot of modern components such as shaders, but really... If classic Doom has taught us anything, it's that high-end graphics are not a big factor in deciding what makes a game great. I think the workflow of modding GZDoom is something serious indie developers would love.

On a different note: doesn't ZDoom use code from Build still? Both GZDoom and ZDoom come with a Build-license TXT file, so I assume it still does. It would be great if somebody could fix this!

[Lavender Moon]

ZDoom does, and so does GZDoom. GZDoom-GPL doesn't, because it axed the software renderer that had all the Build code in it.

[Nash]

To the 1 person who's using this (besides me!), this isn't dead; far from it! I do my best to maintain this port. But I'm going to wait until the in-progress floating point rewrite is confirmed as stable (currently it's not even merged yet; it's still a branch) so that GZDoom-GPL will build without problems. That means it might take a while. But it's definitely not dead. So don't worry. :P

[Nash]

At the request of like 2 people, I have added binaries for GZDoom-GPL so that anyone can run the engine and you don't need to compile it yourself anymore. These are currently hand-built, there's no automation system in place... if there is demand, I will do an automated system. Otherwise just ask if you need a new build ASAP, or just wait, I will periodically build and upload new executables. Currently Windows only.

Next up, I will upload some instructions on how to change the name of your program so that you can replace all traces of the word "GZDoom" with whatever you want (like maybe your game's name), and how to edit the EXE's icon. In keeping with the non-destructive nature of this fork, I will not modify anything that would make the codebase different from regular GZDoom, but the instructions will be simple so that you can go in and do the changes yourself.

[darkhog]

Aren't there any clever programmers in the community who could contribute a good, gpl software renderer to this project? I really don't want to use OGL, mainly because with all those lights floating around you really don't know what's going on around you (one of reason I DON'T play Brutal Doom, even though I want to try it) and so you get killed easily, whereas with software renderer that looks like Doom originally did, game is crisp, and you know what's going on around you. This is not a general hate on bettering Doom's graphics, it's just that Doom engine is better off without things like particles and shaders or it will look like blurry crap.

[Nash]

Half of this image is the software renderer, the other half is OpenGL. Can you tell, from a quick glance, which is which?

If you don't want dynamic lights, don't add them into your project. Lights and filters has always been optional. Stock GZDoom has no lights and the filtering can be turned off in the options menu.

[leileilol]

Software's at right. colormap ftw

[Nash]

Of course, anyone can tell in 0.5 seconds which one is software, the banded lighting 100% gives it away, but darkhog was complaining about dynamic light's and blurry fx and particle's and I wanted to demonstrate that GZDoom doesn't have grafic's by default.

[Graf Zahl]

Aren't there any clever programmers in the community who could contribute a good, gpl software renderer to this project?

Short answer: no. Apparently you have no idea how much work that would involve.

[TheRailgunner]

What about Zdoom-GPL? I mean, I can care less for the whole "you need opengl4 for 1993 game!!! software render removed!! its a shit!" aspect, and want a fast bare software renderer with decoracs stuffs.

I can understand wanting basic compatibility with Vanilla Doom (or more likely, Boom), but GL hardware render > Build software render, even if only because the software render skews the Z-axis horribly in mouselook scenarios. That, and Doom mods have become both more technically and visually complex in the past few years - I honestly can't see why anyone who isn't running vanilla would take an alpha-less render with Z-axis scaling problems and color limits over OpenGL.

This is not a general hate on bettering Doom's graphics, it's just that Doom engine is better off without things like particles and shaders or it will look like blurry crap.

If "blurry crap" be your gripe, that seems more like a filter than particles and shaders (I honestly can't stand filters like that on lower resolution games - again, blurry crap).

[maseter]

Why no 32bit builds?

[TerminusEst13]

I honestly can't see why anyone who isn't running vanilla would take an alpha-less render with Z-axis scaling problems and color limits over OpenGL.

For the authentic colormap, coloring over distance, and unique shading and lighting?

There's plenty of reasons to prefer Software over Hardware. That OGL is the only thing supported is more than understandable (THANKS KEN SILVERMAN), but it'd still be fantastic if a coding wizard with too much time on his hands was able to whip up something. Nigh impossible, mind, but still.
Ultimately the player should be able to pick and choose how they want to experience it, not have us force it on them.

[CRxTRDUDE]

Sorry, but I edited this post as this is not only an issue for this fork, but in GZDoom altogether.

I posted a separate thread here.