[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.

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

Postby ibm5155 » Tue Jul 07, 2015 1:55 pm

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...
User avatar
ibm5155
Just Spooky
 
Joined: 20 Jul 2011

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

Postby ShinyCrobat » Tue Jul 07, 2015 2:22 pm

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...
ShinyCrobat
 
Joined: 20 Jul 2013

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

Postby phantombeta » Tue Jul 07, 2015 2:27 pm

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
phantombeta
Tired of being treated like trash by control freaks
 
Joined: 02 May 2013

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

Postby AlexMax » Tue Jul 07, 2015 4:53 pm

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
AlexMax
Certainly they existed...
 
Joined: 15 Apr 2006

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

Postby Hoodoo456 » Tue Jul 07, 2015 4:56 pm

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
Hoodoo456
 
Joined: 29 Oct 2013

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

Postby deathride58 » Tue Jul 07, 2015 4:58 pm

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
deathride58
 
Joined: 26 Jun 2015
Location: Everywhere

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

Postby AlexMax » Tue Jul 07, 2015 5:02 pm

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
AlexMax
Certainly they existed...
 
Joined: 15 Apr 2006

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

Postby Hoodoo456 » Tue Jul 07, 2015 5:24 pm

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
Hoodoo456
 
Joined: 29 Oct 2013

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

Postby phantombeta » Tue Jul 07, 2015 5:45 pm

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
phantombeta
Tired of being treated like trash by control freaks
 
Joined: 02 May 2013

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

Postby Marrub » Tue Jul 07, 2015 6:58 pm

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 this wiki page, but of course, without FMOD Ex.
User avatar
Marrub
Xevv Va Rkvyr
 
 
 
Joined: 26 Feb 2013
Discord: Marrub#5455
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

Postby AlexMax » Tue Jul 07, 2015 7:41 pm

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
AlexMax
Certainly they existed...
 
Joined: 15 Apr 2006

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

Postby Marrub » Tue Jul 07, 2015 8:22 pm

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
Xevv Va Rkvyr
 
 
 
Joined: 26 Feb 2013
Discord: Marrub#5455
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

Postby Marrub » Tue Jul 07, 2015 9:00 pm

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
Marrub
Xevv Va Rkvyr
 
 
 
Joined: 26 Feb 2013
Discord: Marrub#5455
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

Postby ibm5155 » Wed Jul 08, 2015 11:18 am

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
ibm5155
Just Spooky
 
Joined: 20 Jul 2011

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

Postby JPL » Wed Jul 08, 2015 12:34 pm

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!
User avatar
JPL
 
 
 
Joined: 09 Apr 2012

PreviousNext

Return to Abandoned/Dead Projects

Who is online

Users browsing this forum: No registered users and 2 guests