[Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
-
- Posts: 1268
- Joined: Wed Jul 20, 2011 4:24 pm
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
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...
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...
-
- Posts: 65
- Joined: Sat Jul 20, 2013 5:42 pm
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
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...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.
-
- Posts: 2119
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
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?
So... Chances of that getting added?
-
- Posts: 64
- Joined: Sat Apr 15, 2006 12:26 am
- Preferred Pronouns: She/Her
- Operating System Version (Optional): Windows 11 22H2
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
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.
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.
-
- Posts: 21
- Joined: Tue Oct 29, 2013 10:13 pm
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
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?
-
- Posts: 15
- Joined: Fri Jun 26, 2015 8:07 pm
- Location: Everywhere
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
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.
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.
-
- Posts: 64
- Joined: Sat Apr 15, 2006 12:26 am
- Preferred Pronouns: She/Her
- Operating System Version (Optional): Windows 11 22H2
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
Correct. There are many parts of ZDoom that are under no-commercial clauses (see here), and this project removes all of them.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?
-
- Posts: 21
- Joined: Tue Oct 29, 2013 10:13 pm
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
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?
-
- Posts: 2119
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
Shaders are already in. It's a GZDoom feature.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.
What GZDoom doesn't have is screenspace/post-processing shaders. (?)
-
-
- Posts: 1198
- Joined: Tue Feb 26, 2013 2:48 pm
- Preferred Pronouns: No Preference
- Operating System Version (Optional): Arch Linux
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
I did this by editing iwadinfo.txt in engine.pk3, so, it's already customizable.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.
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.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 should all already be nuked. I'll go investigate.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.
I will see what I can do.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...
Tried adding roll before, didn't work out. Realized 15 minutes later I could very trivially add it. I'll try again.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?
Thanks.AlexMax wrote:I know this had been tossed around for a while as an idea, so congratulations on doing the legwork.
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?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".
I've been tossing this idea around in my head, trying to think of a way to do it. Maybe some day.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.
Yeah, there may still be some crusty bits. Sorry about that.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?
This is simply because I have not changed the defaults to be sane, thank ZDoom for 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.
That could work.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
Could be interesting, but I'm not very good with GLSL.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.
It compiles just as GZDoom does, but you need OpenALSoft and libsndfile, and optionally mpg123.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?
See [wiki=Compile_ZDoom_on_Windows]this wiki page[/wiki], but of course, without FMOD Ex.
-
- Posts: 64
- Joined: Sat Apr 15, 2006 12:26 am
- Preferred Pronouns: She/Her
- Operating System Version (Optional): Windows 11 22H2
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
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.
-
-
- Posts: 1198
- Joined: Tue Feb 26, 2013 2:48 pm
- Preferred Pronouns: No Preference
- Operating System Version (Optional): Arch Linux
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
Spoiler:
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.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.
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.
-
-
- Posts: 1198
- Joined: Tue Feb 26, 2013 2:48 pm
- Preferred Pronouns: No Preference
- Operating System Version (Optional): Arch Linux
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
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.Marrub wrote:It should all already be nuked. I'll go investigate.
-
- Posts: 1268
- Joined: Wed Jul 20, 2011 4:24 pm
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
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
I'll give a touch on it today, and, at least, see if I can compile it over visual studio :S
-
-
- Posts: 523
- Joined: Mon Apr 09, 2012 12:27 pm
Re: [Engine] GLOOME / [WIP] Project 67 & Nocturne in Yellow
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!
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!