Zandronum

It looks like as of 0.5.6, alexey-lysiuk osx branch has managed to be in sync with GZDoom 2.x.

https://github.com/alexey-lysiuk/gzdoom ... ReadMe.rtf

Doesn't this open the flood gates for Zandronum to do the same?

AFAIK Zandronum will stay in sync with GZD 1.x to ensure compatibility with potatoes or something

My graphics card on my laptop is a 6 year old Nvidia GT 330M. And seems to run all right. Not sure how much more of a potato you can get. Perhaps mine is only half baked. I just worry about future mod compatibility. It seemed like for a little bit Zandronum was finally about to catch up. There is more to 2.x then just the renderer.

Zandronum 3.0 will use GZDoom 1.8.6 as base. We have already spent a lot of time stabilizing 3.0, so it's not feasible to switch to a different (G)ZDoom version for Zandronum 3.0 anymore.

Nevertheless, my Zandronum-ZDoom-Sync branch is fully in sync with the latest GZDoom 2.x git repo version. So once 3.0 is out, we can move on with our GZDoom base.

I had know idea you had a branch fully in sync. How you can hold 3 disparate projects together like that is beyond amazing. Yah no point backtracking on 3.0 now :)

Torr Samaho wrote:Nevertheless, my Zandronum-ZDoom-Sync branch is fully in sync with the latest GZDoom 2.x git repo version. So once 3.0 is out, we can move on with our GZDoom base.

Now this is exciting! I am looking forward to seeing Zandronum finally catch up with GZDoom's latest development!

darklord42 wrote:My graphics card on my laptop is a 6 year old Nvidia GT 330M. And seems to run all right. Not sure how much more of a potato you can get. Perhaps mine is only half baked. I just worry about future mod compatibility. It seemed like for a little bit Zandronum was finally about to catch up. There is more to 2.x then just the renderer.

I have NVidia GeForce 6200 LMAO

darklord42 wrote: There is more to 2.x then just the renderer.

Really? Prove me this.

GZDoom 2.* issues:
- still no VBO for walls.
- VBO for other detail provides about the same frame rate as glBegin does. GLBoom shitcode is still faster on vanilla maps than GZ. Fell the difference on this wad.
- VBO emulator for 3d models is not a good joke. They still lag.
- Dynlights are still crappy and they lag too. They also go through the walls like in 1.*!!!
- No dynlight/model shadows in 2016, but we've f*cked opengl 2.0 users, mission success! I remember, even ZDoomGL had them.
- GZDoom shader architecture is shit. No changes there. Custom shaders are possible, but with shitty restrictions.
- GLDefs just sucks, including definitions for shaders. ^^^
- Modeldefs suxxxx. ex. no XOffset, YOffset and such useful options for models. You can't directly use decorate <-> modeldef without *fake* sprites.
- md3 and md2 suck: 1. no skeletal animation 2. no good converters for these outdated formats. I always had a pain in the ass with them.
- Always uses GL_BLEND for non-translucent detail (walls, flats, etc.). I checked, this reduces fps by 1.5 times on some maps.
- Uses extra CPU resources for useless geometry calculations like converting quads to triangles. The visible part of the map is converted to polygons EVERY FRAME, even though 99% of the map is completely static.
- 3D floors are... yes.. THEY LAG TOO!
- Missing render distance feature that could fix a lot of issues.
- 3D portal render bugs and such things.

*..And more bad things in gzdoom. This list is very long*

So...
I see no big difference between 2.x and 1.x. Why do we need this "new" renderer that breaks compatibility with old videocards when it's possible to work with them?

I can't help but ask why should people be forced support ancient 10+ year video cards for all eternity? I think I have a Voodoo 2 Banshee somewhere in the attic. Should that be supported? At what point are developers free to drop support for ridiculously old hardware to pursue at least newer technologies?

All that said, perhaps it's not making the most of OpenGL 3.0 that it could be yet. You seem to be quite an expert on it. But mods will be making use of what is there. (which is what I meant when I posted it's more then just a render, in that GZDoom2.x stands to be a bit of a culture shift and I don't think it would be best for zandronum to ignore to support a few ancient cards.)

There has to be a compromise somewhere. Maybe zandronum users can choose between renders as they do software and opengl 2.0 now. I'm sure it would be a heck of a lot of work to implement, but if there was a large demand for use with old cards, then ideally that would be the way to do it.

Monsterovich wrote:Really? Prove me this.

Please see this topic as for the purpose of the GZDoom 2.x branch.

Monsterovich wrote:GZDoom 2.* issues:

Feel free to make it happen, if its approved. [1]

Monsterovich wrote: GZDoom 2.* issues:
- GZDoom shader architecture is shit. No changes there. Custom shaders are possible, but with shitty restrictions.
- GLDefs just sucks, including definitions for shaders. ^^^
- Modeldefs suxxxx. ex. no XOffset, YOffset and such useful options for models. You can't directly use decorate <-> modeldef without *fake* sprites.
- md3 and md2 suck: 1. no skeletal animation 2. no good converters for these outdated formats. I always had a pain in the ass with them.
- Always uses GL_BLEND for non-translucent detail (walls, flats, etc.). I checked, this reduces fps by 1.5 times on some maps.
- Uses extra CPU resources for useless geometry calculations like converting quads to triangles. The visible part of the map is converted to polygons EVERY FRAME, even though 99% of the map is completely static.
- 3D floors are... yes.. THEY LAG TOO!
- Missing render distance feature that could fix a lot of issues.
- 3D portal render bugs and such things.

1. They are quite restricted currently, it would be nice to be able to specify 2nd, 3rd, and 4th textures in GLDEFS for multitexturing.
2. GLDEFS is fine and the definitions are fine. Don't know what else it really needs aside from what I just mentioned above.
3. Just do what I do, make fake sprite file for the base frame, leave the rest out. You don't need a fake sprite file for every frame. Also, X Y and Z offsets are already in. See latest GZDoom or Zandronum 3.0. It also has XYZ rotation.
4. A skeletal animation format would be nice, such as SMD. I have the format spec if someone wants to try to implement it. However, there are good tools to convert to MD3. Noesis (Great if animation is unimportant), Misfit Modeler 3D (I made a patch for it to raise the poly/vert limit), Milkshape 3D (good SMD importer), and 3DS Max. Crowbar MDL Decompiler and CannonFodder's MDL decompiler both work great for converting from source engine with full animation.
5. This may be necessary for textures with PNG alpha. Someone correct me if I'm wrong. If it isn't needed, I imagine a check for line alpha can be used to turn the GL_BLEND state off.
6. I imagine this could be optimized by considering the entire map as static, and if something moves, it becomes dynamic for the duration of the map. I'm pretty sure later GZDoom builds do *something* like this, my framerate in many maps has improved drastically.
7. This is because 3D Floors cut the entire map into slices IIRC, including all sprites and whatnot... which is wholly unnecessary. This should only need to be done to the sector it resides in and anything in it, not the whole map.
8. Being able to specify a render distance for 3D Models would be nice, controllable in MODELDEF.
9. Yeah, I've noticed lately they've been considerably more fucked in OpenGL than in Software, when it's usually the other way around, especially in recent builds with Wall Portals.

StrikerMan780 wrote:5. This may be necessary for textures with PNG alpha. Someone correct me if I'm wrong. If it isn't needed, I imagine a check for line alpha can be used to turn the GL_BLEND state off.

GL_BLEND is completely unnecessary for one-sided geometry (floors, ceilings, top/bottom wall textures, middle textures of one-sided walls). GL_BLEND is also unnecessary for transparent graphics that only have completely transparent pixels (alpha 0) using a shader that simply discards pixels with zero alpha (since GZDoom 2.x forces a GL version that is guaranteed to have shaders anyway).

btw, Monsterovich, did you report this to GZ aside from crying about it in the forums? Because then I probably should.

ZZYZX wrote:btw, Monsterovich, did you report this to GZ aside from crying about it in the forums? Because then I probably should.

Now, it's your turn.

Monsterovich wrote:

ZZYZX wrote:btw, Monsterovich, did you report this to GZ aside from crying about it in the forums? Because then I probably should.

Now, it's your turn.

Make sure to link it here so I can see it.

Also since I recall Graf saying he doesn't care as much about rendering based on the thread linked above somewhere, I figure that would explain funny stuff. However it is ironic that he basically made a port centered around OpenGL rendering if he is not a fan of it.