[Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow

[MTrop]

At some point I found the least amount of zdoom.pk3 resources for getting something to run, all the way down to and including which base DECORATE actors need to be defined without things crashing. Turns out you can cull a lot, and only leave the ones that have native hooks.

jmickle66666666 said:

If this is true, that's really cool. My request is more about making it as clear as possible to developers just so they don't have to find out about obscure issues by trial and error etc.

A simple guide along the lines of "Here's how to make a thing for Gloome in X easy steps!" and at the end have something to play.

I'd probably go the route of a project creator program. It'd create all of the stubs for a runnable package, plus generated scripts that bundle things together, similar to how we assemble Square. Then you can use Git or something for revisioning or whatever.

[Jaxxoon R]

esselfortium said:

Is it possible for a game to define the intended GL lighting options and hide them from users? GZDoom's apparent inability to ensure that lighting mode, ambient light level, and dynamic lights will be configured correctly for the wad makes it rather awkward to use its features. (See: Phocas Island 2's calibration room.)

Oh yes, this is exactly the kind of thing I pondered about with TCs and yes, even this. Well, except in my case it was for keybindings.

O great and rad GPL engine guy, heed our askings!

[Snarboo]

esselfortium said:

Is it possible for a game to define the intended GL lighting options and hide them from users? GZDoom's apparent inability to ensure that lighting mode, ambient light level, and dynamic lights will be configured correctly for the wad makes it rather awkward to use its features. (See: Phocas Island 2's calibration room.)

Having the author define the intended lighting settings and then have them override the user settings or defaults with a flag is good idea, but I'm not sure about hiding or disabling user controls entirely. The user should always have the option of setting the lighting options themselves, especially in cases of accessibility where the author provided settings cause issues. There's always the potential for an author to set them suboptimally on purpose, too, either to troll the user or otherwise (eg imagine an author that has their monitor set poorly; their custom GL settings might look fine for them, but terrible for everyone else).

Edit:
For clarification, I can understand wanting to control the user experience so it plays and looks like it should, but the reality is that it's impossible to ensure that it will always play exactly how an author intends it to. All hiding or locking the settings does is annoy the end user, since they can always crack open a project in their wad editor of choice and mess with it that way.

[Gez]

You can set the lighting mode at least.

As for calibration, one shouldn't forget that not all monitors are identical.

[scifista42]

What about adding a new GameInfo option "Create config"? Then, upon launching the wad for the first time, the engine would generate a special config for this wad, and then use it whenever the same wad is launched again. GameInfo would specify which options should copy the player's default config, and which options should be set to new defaults defined by the game creator. Then, the engine should let the player reconfigure the options. Perhaps it could display a special icon at the options that were "forcedly defaulted" by the game creator, warning the player that "Beware, if you change this option, you interfere with the game creator's intention!" - but anyway, letting him to change it, and the change will be saved into the config. The special icon should stay in the engine's options even afterwards, tied to the GameInfo itself instead of the config.

This would be used to allow the game creator set lighting mode for his specific wad on the player's computer, while still allowing the player to change it, while allowing the engine to remember it. Or keybindings instead of lighting mode. Or any other options.

[esselfortium]

A simplified user-facing menu that only allows for things like basic brightness and gamma adjustment would be fine, I think.

For a standalone game, size and intensity of dynamic lights shouldn't be user-facing, and neither should the ambient light level, fakecontrast/smoothlighting toggles, or lighting mode. All those things are going to be specific to how the project was designed.

If this is to be an engine for standalone games, intended to be accessible to players who aren't familiar with the world of Doom source ports, there's no sense in displaying options that have no purpose in standalone games.

You don't need to block savvy users from changing them in the console if they feel like it, but the options menus for a preconfigured standalone game ought to be much much simpler than the endless cascade of settings pages that source ports need to have in order to accommodate every wad in existence.

[Clonehunter]

Welp, time to start cracking, and I have to show my friend this. Maybe I can make more gun sprites with photos and try to sell them off to people as resources

[Jaxxoon R]

If you wanted the big bucks, you could strive to become a professional MD3 modeler ;)

[Clonehunter]

It's more fun to buy expensive airsoft replicas and use them for five photos and then never touch them again :,)

[jmickle66666666]

MTrop said:

I'd probably go the route of a project creator program. It'd create all of the stubs for a runnable package, plus generated scripts that bundle things together, similar to how we assemble Square. Then you can use Git or something for revisioning or whatever.

This is a really cool idea. I'd be up for helping develop such a thing, if it came to it.

[Gez]

esselfortium said:

For a standalone game, size and intensity of dynamic lights shouldn't be user-facing, and neither should the ambient light level, fakecontrast/smoothlighting toggles, or lighting mode. All those things are going to be specific to how the project was designed.

Good thing the options menu can be entirely redefined.

[TerminusEst13]

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa i go to sleep and suddenly two pages hello everybody glad you like this

jmickle66666666 said:

If this is true, that's really cool. My request is more about making it as clear as possible to developers just so they don't have to find out about obscure issues by trial and error etc.

A simple guide along the lines of "Here's how to make a thing for Gloome in X easy steps!" and at the end have something to play.

This is a fantastic idea and will certainly be a good way to ease people in to this. For a lot of veteran ZDoom modders, this sort of thing is pants-easy to do ("Write a menudef? That's all? Sure, give me like five minutes."), but for people from traditional modding scenes and/or more familiar with something like EGDE/Eternity, there'll probably be a lot to do.
I'll start jotting down documentation as I go and continue work on Nocturne. I'm not sure whether to merge it on an existing wiki or start with the Github built-in wiki or what, but...well, I'll figure that out as people need it.

Jaxxoon R said:

Oooh my. This is exactly something I've been waiting for without knowing that I was waiting for it. I'm curious though, is there to be a prebuilt version in the future? What exactly are the new exclusive features this has? Is there a generic "game.pk3/wad" sort of thing going on that it will automatically look for in the program directory and load? Are there still predefined ACTOR and WEAPON classes like in gzdoom.pk3? Is there anything that GZDoom can do that GLOOME cannot?

Yes, there will be a prebuilt version in the future--probably a soon future. At the moment, priority has been focused entirely on implementing new/separate features in order to assist with full-fledged game development, like the ability to set the ticrate of the world and defining your own cheats.
At the moment, there is currently an engine.pk3 which contains all of the ZDoom-esque information, such as predefined actor classes, default menu data, icons, default sounds, and etc, and more importantly contains an IWADINFO lump, which people can edit to include whatever extra file they want that contains the game data.



As for anything GZDoom can do that GLOOME can't...well, probably all the super-modern features that came after 2.7.1. I don't have any examples right off the top aside from A_SetSpeed off the top of my head (I've been using Zandronum for all my mods up until now), but I'm sure a few people intimately more familiar could list off a featurelist. Marrub's said he's been interested in backporting stuff (especially if they can point out a specific commit), but if we stay a little bit behind and leave the feature-superior engine to Graf and Randy, then hopefully there's less of a chance of inter-port fights breaking out.

esselfortium said:

Is it possible for a game to define the intended GL lighting options and hide them from users? GZDoom's apparent inability to ensure that lighting mode, ambient light level, and dynamic lights will be configured correctly for the wad makes it rather awkward to use its features. (See: Phocas Island 2's calibration room.)

I answered this in IRC, but I'll repost it here.
Yes, you can redefine the entire options menu. There's also the fact that GLOOME only has one .ini file--there's no zdoom-USERNAME.ini or such going on, there's only one .ini.
So a developer can quite easily set up presets about lighting, light level, dynamic lights, fog mode, and etc, pack the .ini along with distribution, and the player will start with those options turned on by default. That way you can specify exactly what kind of lighting you think best benefits the mood.

MTrop said:

I'd probably go the route of a project creator program. It'd create all of the stubs for a runnable package, plus generated scripts that bundle things together, similar to how we assemble Square. Then you can use Git or something for revisioning or whatever.

This would be super-cool! If you decide to go ahead with this, please let me know and I'll pass it on to marrub. This would go a long way towards introducing new people to development.



Phew. That was quite an info dump. Very sorry if I missed your question.

On the development front, marrub's been charging ahead with features and pull requests (the aforementioned cheat code customization and tic rate customization are really cool!), and I've been charging ahead with development on Nocturne in Yellow.
As requested by a few people, I've set up a public Github/Copy folder for Nocturne, that people can peruse through and poke at with whatever they'd like:

https://github.com/TerminusEst13/NocturneInYellow
https://copy.com/l8kOw6GUJwu30lFv



Maps still haven't been started and enemy/weapon graphics are still in placeholder status, but we're picking and stabbing at replacing things bit by bit.

[Jaxxoon R]

Ohohoho thank you, thank you, that's exactly what I was hoping to hear. Beautiful work, a wonderful thing you have done for this community and the indie scene in general by spending your precious time and effort making this a reality.

Yay! (claps)

[MTrop]

TerminusEst13 said:

Yes, you can redefine the entire options menu. There's also the fact that GLOOME only has one .ini file--there's no zdoom-USERNAME.ini or such going on, there's only one .ini.
So a developer can quite easily set up presets about lighting, light level, dynamic lights, fog mode, and etc, pack the .ini along with distribution, and the player will start with those options turned on by default. That way you can specify exactly what kind of lighting you think best benefits the mood.

That will not be very good at all if the INI gets deleted or the user wants to start from default settings. There needs to be a way to generate a new default INI if one gets ruined or erased. Maybe embed the default one in the bootstrap archive ("engine.pk3")?

What I would REALLY like to see is use of the HOME or APPDATA folders per user - it ensures separate settings on a multi-user system when the application is installed to a protected space. There could be an option to write/read config from the executable directory for some kind of "portable" mode.


Graphic-wise, the only things that a user should be changing are gamma, color, and things that affect performance. Messing with anything else could affect the game itself, especially with how wall shading and distance fog is handled. Keep in mind that you're writing a developer-oriented engine now, not a source port for end-users.

[Jon]

Hey, I just found out about this today - I guess this probably belongs on Source Ports section rather than WADs, but hey ho...

I like the concept of this, I think it's a great idea, but I'm really troubled with the foundation of the project. You've taken GZDoom, which is licensed under the old Doom License, and re-licensed it to GPL.

I'm a big fan of the GPL and that's one reason I've personally not spent much time using or modding ZDoom or derivatives myself over the years.

However I can't see that you actually have permission to relicense it. The copyright is held by every contributor to any of the code from GZdoom or ZDoom that you haven't ripped out or replaced. Have every single one of those people agreed to relicense their contributions?

[Gez]

ZDoom's license situation is more subtle than that.

The only parts of ZDoom that are under the Doom source license are those parts that are taken directly from the original Doom/Heretic/Hexen source release. This code exists also under the GPL and can therefore be swapped.

New code original to ZDoom is under the BSD 3-point license. Other code taken from elsewhere is under a number of various other licenses.

The only problem points are code under the Build license, under the FMOD EX license, under the MAME license, and under the MUSLIB license. GLOOME got rid of these parts by ditching the software renderer, OPL emulation and OPL formats playback, and using OpenAL audio instead of FMOD.

GLOOME itself did not change the license of anything -- it removed code under incompatible license, and switched dual-licensed code from one license to another, but the dual licensing was pre-existing. Note that they didn't say GLOOME was GPL itself, but was GPL-compliant.

[Jon]

Hi Gez, thanks for trying to explain.

Gez said:

ZDoom's license situation is more subtle than that.

The only parts of ZDoom that are under the Doom source license are those parts that are taken directly from the original Doom/Heretic/Hexen source release. This code exists also under the GPL and can therefore be swapped.

The bits of the source that are preserved verbatim, yes.

Gez said:

New code original to ZDoom is under the BSD 3-point license. Other code taken from elsewhere is under a number of various other licenses.

The BSD license is compatible with the old Doom license but not with the GPL. So such code is not problematic combined with the original code, but becomes so if you consider that original code to be GPL going forward.

There's also a big thorny issue around what is "new code". A new source file? A new subroutine? What about modifications to subroutines from the Doom source?

Gez said:

The only problem points are code under the Build license, under the FMOD EX license, under the MAME license, and under the MUSLIB license. GLOOME got rid of these parts by ditching the software renderer, OPL emulation and OPL formats playback, and using OpenAL audio instead of FMOD.

GLOOME itself did not change the license of anything -- it removed code under incompatible license, and switched dual-licensed code from one license to another, but the dual licensing was pre-existing. Note that they didn't say GLOOME was GPL itself, but was GPL-compliant.

Zdoom minus the bits you mention there is not equivalent to the Doom, Heretic and Hexen sources combined though, is it? Those bits have been modified. Once the incompatible parts have gone, what is left could be re-licensed under the GPL, and I would very much welcome that: but it could only be done so by the copyright holders: namely, the authors, which means at least Randy, but I have no idea how many others too.

I've not heard of this notion of Zdoom's Doom/Heretic/Hexen sources being dual-licensed. It's also not mentioned on the zdoom license page, which is pretty clear (as in: clearly describes the mess ;)), it even clears something up that I didn't know, namely, Zdoom got it's own permission to distribute heretic/hexen sources under the original doom license.

here's the commit where GLOOME changes source files to the GPL.

It's far from clear-cut, and it's a shame because this project's goals are laudable, but I really can't see this being a suitable platform for a truly independent-from doom, indie game, potentially commercially sold, with this uncertainty hanging over it.

[Gez]

Jon said:

The BSD license is compatible with the old Doom license but not with the GPL. So such code is not problematic combined with the original code, but becomes so if you consider that original code to be GPL going forward.

Since when can't you mix BSD code with GPL code? There are more than a few GPL projects which include BSD-licensed code.

Keep in mind that we're talking about the three-point BSD license here, not the four-point one.

Here's the FSF itself telling you it's compatible with the GPL:
https://www.gnu.org/licenses/license-list.en.html#ModifiedBSD

[Jon]

Gez said:

Since when can't you mix BSD code with GPL code? There are more than a few GPL projects which include BSD-licensed code.

Keep in mind that we're talking about the three-point BSD license here, not the four-point one.

Here's the FSF itself telling you it's compatible with the GPL:
https://www.gnu.org/licenses/license-list.en.html#ModifiedBSD

Sorry I wrote that pretty bad. You can indeed include BSD code with GPL code. The problem I was trying to outline was, what of the new stuff is considered a "derived work" of the Doom source, and what is totally novel? A good example of mixing BSD code with GPL would be if you took an independent implementation of something (like SHA1 say) that was BSD licensed and included it into a GPL program. The SHA1 implementation would obviously not be derived from the GPLd sources (not least because it existed independently). Anything derived from the Doom sources cannot be downgraded to BSD. So, a doom routine that had been edited and extended in some way couldn't be BSD licensed.

[andrewj]

What is the license of the ACC compiler in the repository?

[TerminusEst13]

Hello, Jon, sorry it's taken a while to get back to you.

Jon said:

You've taken GZDoom, which is licensed under the old Doom License, and re-licensed it to GPL.

Pardon? GZDoom-specific code is not under the Doom license.

Jon said:

I'm a big fan of the GPL and that's one reason I've personally not spent much time using or modding ZDoom or derivatives myself over the years.

However I can't see that you actually have permission to relicense it. The copyright is held by every contributor to any of the code from GZdoom or ZDoom that you haven't ripped out or replaced. Have every single one of those people agreed to relicense their contributions?

We have not relicensed GZDoom or any of its original code, which is still under the BSD license--and by extension, all of the contributions other people have done to it.
The only code we have re-licensed is the Doom code, which was re-released under GPL and ergo is perfectly fine to change the license to under GPL.

Jon said:

here's the commit where GLOOME changes source files to the GPL.

It's far from clear-cut, and it's a shame because this project's goals are laudable, but I really can't see this being a suitable platform for a truly independent-from doom, indie game, potentially commercially sold, with this uncertainty hanging over it.

What you've linked is the Doom source code that was changed to GPL, as per the re-release. It's actually very clear-cut.
Are you trying to say that the Doom code in GLOOME/GZDoom is not actually from the Doom source code? http://www.doomworld.com/idgames/?id=14576
Because that would be an entirely separate situation, but incredibly easy to rectify. All it would require is pointing out specifically what code was changed for ZDoom, and then those sections can be properly put under ZDoom's BSD license.
EDIT: Or reverting them back to the original. Or re-writing those sections from scratch. Either way.

Jon said:

The problem I was trying to outline was, what of the new stuff is considered a "derived work" of the Doom source, and what is totally novel? A good example of mixing BSD code with GPL would be if you took an independent implementation of something (like SHA1 say) that was BSD licensed and included it into a GPL program. The SHA1 implementation would obviously not be derived from the GPLd sources (not least because it existed independently). Anything derived from the Doom sources cannot be downgraded to BSD. So, a doom routine that had been edited and extended in some way couldn't be BSD licensed.

Even with specifically outlining a problem, I'm honestly not sure what you're trying to say here. Could you clarify, please?
Are you saying that GZDoom's source port code extending the Doom code should not BSD licensed and should be under Doom's license? Are you trying to say the modifications we made to GZDoom's code should be under the Doom license? Or are you asking what the changes we made to the code are licensed under?


EDIT 2:
Sorry, I missed this.

andrewj said:

What is the license of the ACC compiler in the repository?

The ACC code is copyright under Raven's license just as the original ACC is; it shouldn't be distributed with anything, and it's only there because it needs extensions. Marrub says he might open up an entirely new repo for it.

[TerminusEst13]

A few people have been asking about GLOOME's netplay capabilities. It's functionally the same as GZDoom's. Have a video!

Sorry, but you probably won't be able to make GvH standalone just yet. There are "plans" to have client/server/masterserver multiplayer down the line in the future, but this is in the future.
Like, far in the future.
Like, Zandronum will be at 6.0 future.

[Jon]

andrewj said:

What is the license of the ACC compiler in the repository?

It's a derivation of the Raven ACC compiler source (just done a quick diff to confirm). So, it's under the Activision EULA, which as we well know, is completely unusable.

Interestingly the GLOOME authors have added a 0-length file to that folder "Don't distribute this folder with your game".

[Jon]

TerminusEst13 said:

Hello, Jon, sorry it's taken a while to get back to you.

No problem!

TerminusEst13 said:

Pardon? GZDoom-specific code is not under the Doom license.

I might have been switching between ZDoom and GZDoom a bit in my messages, sorry for any confusion.

TerminusEst13 said:

We have not relicensed GZDoom or any of its original code, which is still under the BSD license--and by extension, all of the contributions other people have done to it.

You are right that any original code in ZDoom is under the BSD license. I assume the same is true for GZDoom.

TerminusEst13 said:

The only code we have re-licensed is the Doom code, which was re-released under GPL and ergo is perfectly fine to change the license to under GPL.

Any Doom code modified by Randi or anyone else in Zdoom you cannot automatically convert it to GPL unless you have their consent. That code contains copyright by ID Software *and* anyone who has changed it.

In summary:

• Doom source code as released by ID Software: Copyright ID Software. Available under the Doom Source License or the GPL.
  
• Doom source code in ZDoom, unmodified: copyright ID Software. Available under the Doom Source License. Could be "replaced" with GPL code from above, essentially relicensing it.
  
• Doom source code In ZDoom modified in any way, including new code that has been added which is derived from the Doom source (could not exist independently): Copyright ID Software *and* whoever has modified it. Available under the Doom Source License ONLY, since that's the only way that Zdoom has distributed it. Can be considered GPL only if all copyright holders agree.
  
• Completely new code, in Zdoom, not derived from Doom: distributed under 3-point modified BSD license.
  
• Doom source code in GZDoom modified in any way: As above for ZDoom, + additional copyright holders of GZDoom.
  

TerminusEst13 said:

All it would require is pointing out specifically what code was changed for ZDoom, and then those sections can be properly put under ZDoom's BSD license.
EDIT: Or reverting them back to the original. Or re-writing those sections from scratch. Either way.

No, you can't take modified Doom code and call it BSD. The fact you suggest this further suggests that you do not understand this properly.

TerminusEst13 said:

Even with specifically outlining a problem, I'm honestly not sure what you're trying to say here. Could you clarify, please?
Are you saying that GZDoom's source port code extending the Doom code should not BSD licensed and should be under Doom's license? Are you trying to say the modifications we made to GZDoom's code should be under the Doom license? Or are you asking what the changes we made to the code are licensed under?

I'm trying to say that if you want to make a free Doom-like platform for indie gamers to build on which has a clear and consistent license, then you've started with the worst possible port to work from. Unless you're selling indemnity insurance I don't think you'll ever sort it out, I'm sorry :(

[Graf Zahl]

Jon said:

Any Doom code modified by Randi or anyone else in Zdoom you cannot automatically convert it to GPL unless you have their consent. That code contains copyright by ID Software *and* anyone who has changed it.

In summary:

• Doom source code as released by ID Software: Copyright ID Software. Available under the Doom Source License or the GPL.
  
• Doom source code in ZDoom, unmodified: copyright ID Software. Available under the Doom Source License. Could be "replaced" with GPL code from above, essentially relicensing it.
  
• Doom source code In ZDoom modified in any way, including new code that has been added which is derived from the Doom source (could not exist independently): Copyright ID Software *and* whoever has modified it. Available under the Doom Source License ONLY, since that's the only way that Zdoom has distributed it. Can be considered GPL only if all copyright holders agree.
  
• Completely new code, in Zdoom, not derived from Doom: distributed under 3-point modified BSD license.
  
• Doom source code in GZDoom modified in any way: As above for ZDoom, + additional copyright holders of GZDoom.
  

That's correct. The code cannot be relicensed without all of the original authors agreeing.

That said, I have no problems with relicensing my contributions to the original code - under one provision: The code should remain dual-licensed so that eventual changes may be backported to G/ZDoom if deemed desirable.

And I honestly do not think that any of the other contributors would object either.

[TerminusEst13]

Jon said:

Any Doom code modified by Randi or anyone else in Zdoom you cannot automatically convert it to GPL unless you have their consent. That code contains copyright by ID Software *and* anyone who has changed it. [...]
No, you can't take modified Doom code and call it BSD. The fact you suggest this further suggests that you do not understand this properly.

That's...not what I'm saying. But all right, I'll go with that instead!

Jon said:

I'm trying to say that if you want to make a free Doom-like platform for indie gamers to build on which has a clear and consistent license, then you've started with the worst possible port to work from. Unless you're selling indemnity insurance I don't think you'll ever sort it out, I'm sorry :(

Yes, we were aware of the difficulties going in.
And on the contrary, today I've managed to get in contact with almost all of the people that have contributed to GZDoom and ask their permission. All of the ones that returned said they were fine with it, and I have no reason to suspect any different from any of the remaining contributors.

Graf Zahl said:

That said, I have no problems with relicensing my contributions to the original code - under one provision: The code should remain dual-licensed so that eventual changes may be backported to G/ZDoom if deemed desirable.
And I honestly do not think that any of the other contributors would object either.

Oh shit it's the man himself.
Thank you very much for your work and for letting us do this. We will definitely keep things open, and hopefully we'll be able to backport some of the crazier features--multiple sprite layers alone will probably be unbelievably valuable for a lot of people.

[Jaxxoon R]

Multiple sprite layers? You mean like some kind of texture patches kind of thing but for sprites?

[Jon]

TerminusEst13 said:

That's...not what I'm saying. But all right, I'll go with that instead!

Please accept my apologies again, I'm not understanding what you tried to express.

TerminusEst13 said:

Yes, we were aware of the difficulties going in.
And on the contrary, today I've managed to get in contact with almost all of the people that have contributed to GZDoom and ask their permission. All of the ones that returned said they were fine with it, and I have no reason to suspect any different from any of the remaining contributors.

That is great news. Don't get me wrong: I'm not a nay-sayer, wanting your project dead. I'd love it to succeed. Up until this point, I just hadn't seen that you understood the problem or had worked to seek the necessary permissions. The fact you do, and have, is wonderful news.

[TerminusEst13]

Jaxxoon R said:

Multiple sprite layers? You mean like some kind of texture patches kind of thing but for sprites?

Sort of.

In Decorate, Flash states are considered a separate layer above the weapon. You can put cut-off sprites on top of the existing sprites via Flash to have multiple layers going.
Previously, you could hijack the flash state in order to use its separate layers for asynchronized weapon functions, such as realistic(?) dual-wielding or Duke Nukem style shoot-n'-boot other such nonsense.

In short, now there are multiple layers like these, all of them independent from each other, so dual-wielding can no longer be a bag of hacks.
Or, yeah, you can just piecemeal a weapon together like in Textures. :D

[Sergeant_Mark_IV]

Outstanding work, Term.

Any plans on working on a mobile version?