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

[ibm5155]

There's the fmod code
https://github.com/marrub--/GLOOME/sear ... %93&q=fmod
Out may not be but I'll not enter on a game that idk well about it. It may be just some code that wasn't deleted...

[ShinyCrobat]

Also, that's an interesting question. Being able to remove the vertical stretch might be a good idea, especially for more hardcore pixel enthusiasts.

I hope it gets added! I know I'm one of those people... You can get around it with textures lump, but it would be tedious to do it for every single graphic...

[phantombeta]

I believe Nash has said that the roll feature and the stretch multiplier (sp?) are easy to make. If I recall correctly he was saying this even before the new renderer was out...
So... Chances of that getting added?

[AlexMax]

I know this had been tossed around for a while as an idea, so congratulations on doing the legwork.

I do have a question, though. Based on what you have seen, how possible would it be to hide GPL-incompatible bits behind a compile flag in GZDoom proper? Seems like it'd be possible to just pass a cmake flag and leave out all of the GPL-incompatible bits out of the final executable. As long as it remains in the source tree, it'd be "harmless".

Even if it was possible, I wonder if Graf would merge such a patch.

EDIT: Also, I can understand why you went with GZDoom 1.x, for compatibility's sake. However, while GZDoom 1.x is more backwards-compatible, GZDoom 2.x is far more likely to be forward-compatible and mobile-friendly. So it might be worthwhile to have both renderers, if you can.

[Hoodoo456]

To be absolutely, totally clear on this - The Gloome engine could be used to develop a brand new game that you could sell, correct? Or am I wrong, and games made on this engine can only be distributed for free?

[deathride58]

I got around to downloading and compiling it.

I've noticed that the default midi device is fmod, even though it results in no music from midis. Is that intentional or did I compile it wrong?
Also, is there any reason why the resolution doesn't default to the native resolution or windowed? I know developers could easily include a config with everything set to what most computers these days can handle, but it would likely result in a better experience for users who want to be able to simply start the game and enjoy without having to do any configuration.
And on a vaguely related note, would it be possible to separate the user's rendering settings, player preferences, and game specific configuration options into separate files, so that rendering settings and player preferences are carried over between separate .exes? Storing settings in (user)/appdata/roaming/GLOOME might work

Also, are there any features that are going to be added? Having built-in shaders like bloom and color-correction along with a way for iwads/pwads to define extra shaders would be pretty nice.

[AlexMax]

To be absolutely, totally clear on this - The Gloome engine could be used to develop a brand new game that you could sell, correct? Or am I wrong, and games made on this engine can only be distributed for free?

Correct. There are many parts of ZDoom that are under no-commercial clauses (see here), and this project removes all of them.

[Hoodoo456]

I'm seeing what I can do with this engine, see if anything can eventually come from it, but I don't know how to compile the program into a runnable EXE. Could anyone help me out with that?

[phantombeta]

I got around to downloading and compiling it.

I've noticed that the default midi device is fmod, even though it results in no music from midis. Is that intentional or did I compile it wrong?
Also, is there any reason why the resolution doesn't default to the native resolution or windowed? I know developers could easily include a config with everything set to what most computers these days can handle, but it would likely result in a better experience for users who want to be able to simply start the game and enjoy without having to do any configuration.
And on a vaguely related note, would it be possible to separate the user's rendering settings, player preferences, and game specific configuration options into separate files, so that rendering settings and player preferences are carried over between separate .exes? Storing settings in (user)/appdata/roaming/GLOOME might work

Also, are there any features that are going to be added? Having built-in shaders like bloom and color-correction along with a way for iwads/pwads to define extra shaders would be pretty nice.

Shaders are already in. It's a GZDoom feature.
What GZDoom doesn't have is screenspace/post-processing shaders. (?)

[Marrub]

For my project, it loads up NIY.pk3 like an iwad. For marrub's project, it loads p67_g1.pk3 as an iwad. Later on, obviously I'll have to pester marrub about a customizable system where people can direct what .pk3 to point to.

I did this by editing iwadinfo.txt in engine.pk3, so, it's already customizable.

Other platforms? Aahhhhhh... I'm not marrub, but I think the answer is pretty clearly a "no" on that. For now, we're gonna stick with the platforms we know and we know works.

It works on Linux, as an anonymous person has confirmed. It spits out a bunch of warnings due to hacks in my basicinlines.h replacement, but otherwise, it works.

FMod code? Could you point out where, please? FMod is indeed now free for indie developers, but it'd probably be better to nuke it all Just In Case.

It should all already be nuked. I'll go investigate.

I hope it gets added! I know I'm one of those people... You can get around it with textures lump, but it would be tedious to do it for every single graphic...

I will see what I can do.

I believe Nash has said that the roll feature and the stretch multiplier (sp?) are easy to make. If I recall correctly he was saying this even before the new renderer was out...
So... Chances of that getting added?

Tried adding roll before, didn't work out. Realized 15 minutes later I could very trivially add it. I'll try again.

I know this had been tossed around for a while as an idea, so congratulations on doing the legwork.

Thanks.

I do have a question, though. Based on what you have seen, how possible would it be to hide GPL-incompatible bits behind a compile flag in GZDoom proper? Seems like it'd be possible to just pass a cmake flag and leave out all of the GPL-incompatible bits out of the final executable. As long as it remains in the source tree, it'd be "harmless".

It'd probably not be that hard, most of the code I nuked could be removed with #ifdefs. Most of it. Some things may need to be rewritten?

EDIT: Also, I can understand why you went with GZDoom 1.x, for compatibility's sake. However, while GZDoom 1.x is more backwards-compatible, GZDoom 2.x is far more likely to be forward-compatible and mobile-friendly. So it might be worthwhile to have both renderers, if you can.

I've been tossing this idea around in my head, trying to think of a way to do it. Maybe some day.

I got around to downloading and compiling it.
I've noticed that the default midi device is fmod, even though it results in no music from midis. Is that intentional or did I compile it wrong?

Yeah, there may still be some crusty bits. Sorry about that.

Also, is there any reason why the resolution doesn't default to the native resolution or windowed? I know developers could easily include a config with everything set to what most computers these days can handle, but it would likely result in a better experience for users who want to be able to simply start the game and enjoy without having to do any configuration.

This is simply because I have not changed the defaults to be sane, thank ZDoom for that.

And on a vaguely related note, would it be possible to separate the user's rendering settings, player preferences, and game specific configuration options into separate files, so that rendering settings and player preferences are carried over between separate .exes? Storing settings in (user)/appdata/roaming/GLOOME might work

That could work.

Also, are there any features that are going to be added? Having built-in shaders like bloom and color-correction along with a way for iwads/pwads to define extra shaders would be pretty nice.

Could be interesting, but I'm not very good with GLSL.

I'm seeing what I can do with this engine, see if anything can eventually come from it, but I don't know how to compile the program into a runnable EXE. Could anyone help me out with that?

It compiles just as GZDoom does, but you need OpenALSoft and libsndfile, and optionally mpg123.
See [wiki=Compile_ZDoom_on_Windows]this wiki page[/wiki], but of course, without FMOD Ex.

[AlexMax]

Since we're throwing out ideas, how difficult would it be to add support for a real scripting language, like Lua? If the engine is to be aimed at indie devs, seems like that would be a better bet than ACS.

[Marrub]

---

[22:11] <TerminusEst13> The road to hell is paved with good intentions.
If the author of this article is reading this, only half of that is correct.
This is made for commercial and standalone works that want to be distributed without worry of copyright issues in the engine.

Since we're throwing out ideas, how difficult would it be to add support for a real scripting language, like Lua? If the engine is to be aimed at indie devs, seems like that would be a better bet than ACS.

Perhaps. I will probably be adding file i/o to ACS, limited to a userdata/ folder in the executable directory (or ~/.gloome/userdata/ on non-windows), and read-only access to a userdata/ folder in the IWAD.
So, for example, you could have dialogue scripts read from gameiwad.pk3/userdata/dialogue_jack.txt and parse/use/whatever them in ACS, then write a scoreboard file to C:/path/to/gloome/userdata/playerscores.txt
Not quite sure yet.

[Marrub]

It should all already be nuked. I'll go investigate.

Done checking this, it is indeed all nuked. There's some things I forgot to rename, and of course the mathematical function fmod, but it is clean.

[ibm5155]

Ehm, can I make a special version of GLOOME for my mod/game? So instead of having a launcher and the port itself, I would mix both in the same .exe, or, maybe I could make GLOOME iwad api actually detect both iwads (there're two versions of my iwad one with all the stuff in english and other in portuguese)

I'll give a touch on it today, and, at least, see if I can compile it over visual studio :S

[JPL]

This is really cool to see and I'm glad it exists, thanks for the shoutout in the readme! One hope is that this clarifies the remaining work required to remove or make optional (via #ifdef or whatever makes sense) the code in mainline [G]ZDoom that keeps it from being incompatible with commercial and more liberal license use cases.

It seems like there's two possible futures for this project:

1) Stick as close to mainline GZDoom as possible, so it's trivial to merge new features and fixes. If a system for using both old and new renderers in the codebase is developed, help get that into mainline GZDoom (Graf didn't seem interested in this and I don't blame him, but if yall figure out a way then that's valuable work!). Anything cool GLOOME does can easily be pushed upstream if Randi, Graf et al deem it useful.
2) Embrace the fork-ness, and eventually let GLOOME grow its own unique features as needed by the direction of its devs and/or the needs of its users.

Having not looked closely at the code or the overall diff between this and mainline, I'm probably simplifying a lot of the issues. Deep down my preference is probably for #1; for a while now I've felt that a brand new Doom-like engine free of all legacy and back-compat stuff would be a more worthwhile use of the energy required to make #2 really work (as sadly projects like XLEngine have failed to produce the dream of an awesome end-all-be-all Doom-like engine).

Great work folks! Eager to see how the demo projects develop. And yeah hopefully this can help bring projects like Adventures of Square to Steam!