When did people start switching from zdoom to gz?

[Chris]

Second is the MD3 support - there are many static objects, enemies and projectiles,which simply can't be sprites, as they'll look incredibly fugly.

Not enough love for voxels.

[Reactor]

Well...considering the stuff I desire to be done in models, they're a gazillion times harder to make in voxels!

[koverhbarc]

Yeah, I think that's why people don't use voxels more, there aren't very easy tools to work with them. They really shouldn't be much harder than sprites, and probably easier if the sprite would use rotations. Indeed for the software renderer a voxel is equivalent, I think, to a sprite with a very large number of rotations, but only needing to do be one time.

[drfrag]

A problem I see with GZDoom is that it is not very good with its Software Rendering.

I've actually experienced a huge performance regression with GZDoom 3.1.0 in software mode (both 8 bit and 32 bit) compared to QZDoom 1.3.0.1 and that's without using the poly renderer. I haven't tried GZDoom 3.0. My fps @1024 have gone from 70 to 14 in 32 bit mode and with a huge keyboard delay, the delay is even there on 8 bit mode but is not that severe. That's on doom2.wad map01. Now the game is unplayable in software mode here, hardware runs fine. This is a 10 year old machine (athlon64 3500+).

[dpJudas]

Hmm, that is very odd since the LLVM removal happened in QZDoom 1.3.0. After that there hasn't been anything major that I'd expect would affect the performance in any great deal. This is also after ZScript was added, which is the other major change in GZDoom recently.

What version of OpenGL does that machine support? If it supports 3.0 then try switch to the OpenGL backend for the software renderer and see if it makes any difference.

[drfrag]

Sorry, something was running in the background and was unfortunate than only affected the latest GZDoom (i switched engines several times). Now it runs fine with the same performance and i get 30 fps @1024x32 in both engines.
Only GL 2.0 support here, with the GL backend QZDoom exits to windows but the process is still running while GZDoom crashes.

[Major Cooke]

I hit the ground running with GZDoom from the very start. The only reason I ever worked with ZDoom was because DBThanatos requested we make different rendering optimizations for the people who couldn't handle GZDoom in our mods.

I knew from Randi's absence that it was a ticking time bomb, honestly. With Graf constantly on top of things and making a dream come true, there was going to be a time where the old was going to die. I could tell from the very start Graf really hated this separation, and I'm glad he (and Randi) finally placed ZDoom on the chopping block.

Now I no longer need to worry about such things anymore such as the differences between renderers (unless flat sprites don't work in QZDoom's renderer -- should that be the case, I have faith they will get around to making it work someday) and as such will not optimize anything that relies on ZDoom's old renderer. In fact, I may outright remove the alternative effects in the future.

[Enjay]

Right from the outset for me too.

[Graf Zahl]

I never actually used plain ZDoom...

[Kinsie]

I picked it up immediately, but had to drop it at one point when my GPU died and I had to use a Voodoo 3 for a while. Turns out GZDoom, at least at the time, did not play nice with OpenGL-to-Glide injector thingies. I know, right?

Doom Builder's 3D mode (this was before 2.0) also failed to be much use under these circumstances, as it'd be forced into fullscreen and be glitchy to the point of unusability, so I'd have to guesstimate things in 2D mode and jump into the game to check. And that's how I did a good chunk of NOTH, my first "big" mod. I honestly don't know how I had the time...

[Graf Zahl]

I picked it up immediately, but had to drop it at one point when my GPU died and I had to use a Voodoo 3 for a while. Turns out GZDoom, at least at the time, did not play nice with OpenGL-to-Glide injector thingies. I know, right?

Not sure what the cause may have been but I think the reason is that GZDoom always required a true color framebuffer, it never worked with 16 bit due to lack of stencil buffers in that mode.
-

[leileilol]

At least in some older gzdooms of the past I was able to load the MesaFX ICDs with them (which should lie about its supported buffers and use 16bpp anyway for the sake of getting games working), on V2 and V3 at least.


I don't see the appeal of spammed dynamic lights nor models without normals being used so I stick to software ports anyway. Besides, gzdoom revs my fans up and does a dirty refresh of the desktop on init even while in a window (affecting streaming media playing stuff badly)

[Rachael]

That's odd - on my computer, it's the software renderer that revs my fans up - but it could also be the resolution that I run it at, and the fact that GZDoom is relatively passive on my GPU. (My GPU gets very bored with GZDoom...)

[Kinsie]

Not sure what the cause may have been but I think the reason is that GZDoom always required a true color framebuffer, it never worked with 16 bit due to lack of stencil buffers in that mode.

Well, I mean, it ran, but textures would corrupt before my eyes. And seeing as the reason I was using that card was because my previous one had died of overheating, it spooked me and I went back to software.

Also: Every sprite had a thick black outline where anti-aliasing would be, like old versions of EDGE.

[Graf Zahl]

That's odd - on my computer, it's the software renderer that revs my fans up

That's to be expected if software uses more than one core for 100%. The GL renderer does not use multithreading (because OpenGL cannot be used like that easily.)