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

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.
User avatar
ibm5155
Posts: 1268
Joined: Wed Jul 20, 2011 4:24 pm

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

Post by 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
Posts: 65
Joined: Sat Jul 20, 2013 5:42 pm

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

Post by ShinyCrobat »

TerminusEst13 wrote: 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...
User avatar
phantombeta
Posts: 1982
Joined: Thu May 02, 2013 1:27 am
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: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow

Post by 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?
User avatar
AlexMax
Posts: 64
Joined: Sat Apr 15, 2006 12:26 am

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

Post by 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.
Last edited by AlexMax on Tue Jul 07, 2015 5:03 pm, edited 1 time in total.
User avatar
Hoodoo456
Posts: 21
Joined: Tue Oct 29, 2013 10:13 pm

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

Post by 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?
User avatar
deathride58
Posts: 15
Joined: Fri Jun 26, 2015 8:07 pm
Location: Everywhere

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

Post by 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.
User avatar
AlexMax
Posts: 64
Joined: Sat Apr 15, 2006 12:26 am

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

Post by AlexMax »

Hoodoo456 wrote: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.
User avatar
Hoodoo456
Posts: 21
Joined: Tue Oct 29, 2013 10:13 pm

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

Post by 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?
User avatar
phantombeta
Posts: 1982
Joined: Thu May 02, 2013 1:27 am
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: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow

Post by phantombeta »

deathride58 wrote: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. (?)
User avatar
Marrub
 
 
Posts: 1162
Joined: Tue Feb 26, 2013 2:48 pm
Discord: agw.systems#7777
Twitch ID: marrubdaskuleion
Github ID: marrub--
Operating System: Other Linux 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

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

Post by Marrub »

TerminusEst13 wrote: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.
TerminusBest13 wrote: 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.
TerminusTest13 wrote: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.
ShinyCrobat wrote: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.
phantombeta wrote: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.
AlexMax wrote:I know this had been tossed around for a while as an idea, so congratulations on doing the legwork.
Thanks.
AlexFax wrote: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?
AlexHax wrote: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.
deathride58 wrote: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.
deathride59 wrote: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. :mrgreen:
deathride60 wrote: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.
deathride61 wrote: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.
Hoodoo456 wrote: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.
User avatar
AlexMax
Posts: 64
Joined: Sat Apr 15, 2006 12:26 am

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

Post by 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.
User avatar
Marrub
 
 
Posts: 1162
Joined: Tue Feb 26, 2013 2:48 pm
Discord: agw.systems#7777
Twitch ID: marrubdaskuleion
Github ID: marrub--
Operating System: Other Linux 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

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

Post by Marrub »

Spoiler:
AlexMax wrote: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.
User avatar
Marrub
 
 
Posts: 1162
Joined: Tue Feb 26, 2013 2:48 pm
Discord: agw.systems#7777
Twitch ID: marrubdaskuleion
Github ID: marrub--
Operating System: Other Linux 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

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

Post by Marrub »

Marrub wrote: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.
User avatar
ibm5155
Posts: 1268
Joined: Wed Jul 20, 2011 4:24 pm

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

Post by 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
User avatar
JPL
 
 
Posts: 516
Joined: Mon Apr 09, 2012 12:27 pm

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

Post by 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!

Return to “Abandoned/Dead Projects”