[No] Generic systems for GZDoom

Moderator: GZDoom Developers

Generic systems for GZDoom

Postby CBM » Fri Nov 06, 2020 1:45 am

I suggest addition of the following generic systems

1) a generic extendable weather system that can be controlled from zScript and decorate
(ie. rain, fog, snow, ...)

2) a generic extendable system for vehicles that makes it easy to use sprites or 3d models to create vehicles for gzdoom mods - native engine support would make stuff like sergeant marks tanks waaaaay easier to make or replicate

3) support for true 3D maps (ie. quake 2 BSP maps, to avoid 3d floors completely)

4) inheritance in 3dmodeldef (ie. if you have a generic soldier model, then it would be nice to just have to specify texture for each subsequent cloned actor)
User avatar
CBM
Imp Slayer
 
Joined: 09 Oct 2019
Location: The Shores of Hell
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: Yes (Using Development/Testing Version)
Graphics Processor: nVidia with Vulkan support

Re: Generic systems for GZDoom

Postby Graf Zahl » Fri Nov 06, 2020 2:35 am

No comment.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Generic systems for GZDoom

Postby Nash » Fri Nov 06, 2020 2:46 am

About the only thing that would make sense here is related to (1) - if modders could define texturized particles, I think these precipitation systems would benefit more from it. Of course those weather systems would still need to be done as mods, as built-in engine features they'd make no sense because weather was never a part of any of the base games.

Regarding (4), MODELDEF should not be expanded any more. Some new model format would make more sense, going forward.

Of course this all means nothing if no one steps up to do the actual work. :^)

Ah, maybe some day when I have more free time and have more programming skill...
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: Generic systems for GZDoom

Postby phantombeta » Fri Nov 06, 2020 10:07 am

CBM wrote:1) a generic extendable weather system that can be controlled from zScript and decorate
(ie. rain, fog, snow, ...)

Out of scope for the port, DIY. A ZScript solution would be more flexible anyway.

2) a generic extendable system for vehicles that makes it easy to use sprites or 3d models to create vehicles for gzdoom mods - native engine support would make stuff like sergeant marks tanks waaaaay easier to make or replicate

Waaaaaaaaay out of scope for the port, and also DIY. Same as above.

3) support for true 3D maps (ie. quake 2 BSP maps, to avoid 3d floors completely)

Not possible in this engine.

4) inheritance in 3dmodeldef (ie. if you have a generic soldier model, then it would be nice to just have to specify texture for each subsequent cloned actor)

As Nash said, MODELDEF should not be added to anymore. It's already awful and hard to work with, it'd be easier to make a new lump and animation system.
User avatar
phantombeta
In the meadow of sinful thoughts, every flower's a perfect one
 
Joined: 02 May 2013
Location: Brazil, South America, Earth, Orion-Cygnus Arm, Milky Way
Discord: phantombeta#2461
Twitch ID: phantombeta_
Github ID: Doom2fan
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Generic systems for GZDoom

Postby Redneckerz » Fri Nov 06, 2020 1:54 pm

CBM wrote:I suggest addition of the following generic systems

1) a generic extendable weather system that can be controlled from zScript and decorate
(ie. rain, fog, snow, ...)

There is WeatherFX, but this is quite a monumental effort first and formost.

CBM wrote:2) a generic extendable system for vehicles that makes it easy to use sprites or 3d models to create vehicles for gzdoom mods - native engine support would make stuff like sergeant marks tanks waaaaay easier to make or replicate

This is even more of an effort. The closest equivalent is KGZDoom, and that's more of a hack job to implement vehicles (and outdated)

CBM wrote:3) support for true 3D maps (ie. quake 2 BSP maps, to avoid 3d floors completely)

:| Do you realize to the full extent of what you are suggesting here? You suggest a true 3D polygonal renderer here, in the vein of Doom3D

CBM wrote:4) inheritance in 3dmodeldef (ie. if you have a generic soldier model, then it would be nice to just have to specify texture for each subsequent cloned actor)

Kevinevans made a 256 textures generator that does variety of actors.

In short, the suggestions aren't just relatively easy features, but significant additions that require significant development time. Given that most of the team has been occupied as is, i do like to ask what made you arrive at these suggestions of this order.
User avatar
Redneckerz
To it's ports i may have seen
Spotlight Team
 
Joined: 25 Nov 2019
Discord: Redneckerz#8399
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia (Legacy GZDoom)

Re: Generic systems for GZDoom

Postby Apeirogon » Fri Nov 06, 2020 3:03 pm

Nash wrote:Of course those weather systems would still need to be done as mods, as built-in engine features they'd make no sense because weather was never a part of any of the base games.

Heh, so sprite shadows in the past was a part of a base games?!
User avatar
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Re: Generic systems for GZDoom

Postby phantombeta » Fri Nov 06, 2020 5:30 pm

Redneckerz wrote:
CBM wrote:3) support for true 3D maps (ie. quake 2 BSP maps, to avoid 3d floors completely)

:| Do you realize to the full extent of what you are suggesting here? You suggest a true 3D polygonal renderer here, in the vein of Doom3D

GZDoom's hardware renderer is a "true 3D polygonal renderer". As is the SoftPoly backend.
GZDoom not having "true 3D maps" has nothing to do with rendering. It's the way Doom's physics, collision detection, AI, sight checks, etc. work that are the problem here.
User avatar
phantombeta
In the meadow of sinful thoughts, every flower's a perfect one
 
Joined: 02 May 2013
Location: Brazil, South America, Earth, Orion-Cygnus Arm, Milky Way
Discord: phantombeta#2461
Twitch ID: phantombeta_
Github ID: Doom2fan
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Generic systems for GZDoom

Postby Graf Zahl » Sat Nov 07, 2020 2:37 am

Keep in mind: Even though Build is also a 2.5D engine there is no realistic way to make Build maps work in Doom. Real 3D maps would be infinitely more complex.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Generic systems for GZDoom

Postby Gez » Sat Nov 07, 2020 5:27 am

You can sort-of fake it by making a non-solid 3D model of the map (or of map segments, at least) and then use regular geometry to handle the collisions. Don't forget to give your map hull things a huge render radius so that they don't get hidden when their center is out of line of sight.

I think there was someone who worked on a project using this approach but it probably went nowhere as I don't remember seeing it elsewhere than a couple of old posts in what was probably the WIP thread.
Gez
 
 
 
Joined: 06 Jul 2007

Re: Generic systems for GZDoom

Postby Redneckerz » Sat Nov 07, 2020 7:54 am

phantombeta wrote:GZDoom's hardware renderer is a "true 3D polygonal renderer". As is the SoftPoly backend.

I stand corrected.

phantombeta wrote:GZDoom not having "true 3D maps" has nothing to do with rendering. It's the way Doom's physics, collision detection, AI, sight checks, etc. work that are the problem here.

So that does not work then.
Good, OP's questions are answered then.
User avatar
Redneckerz
To it's ports i may have seen
Spotlight Team
 
Joined: 25 Nov 2019
Discord: Redneckerz#8399
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia (Legacy GZDoom)


Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 0 guests