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

Snarboo wrote:This looks pretty cool! Will this be keeping up with the latest versions of G/ZDoom, or are you looking to target a specific feature set instead?
It will stick to 1.8.10 with extensions and backported features. This is only because 1.8.10's renderer works on a wider range of hardware.
As much as I'd love to use the new one, I do know project developers who can't run 2.x. (This includes Terminus.)
Jimmy wrote:Whoa.

So, uh, given the licensing of this particular engine, would it therefore be plausible for, say, a *COUGH COUGH* certain other project with entirely custom-made assets to be made into something vaguely more distributable / saleable?
Yep. Since this is now (as far as I can tell, I'll have to smack someone if it isn't) GPL and GPL-compliant code, it can be sold as long as you either distribute the source code or make it somehow available (i.e. through a link) in your distribution.
User avatar
Snarboo
Posts: 2598
Joined: Tue Nov 29, 2005 4:37 am

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

Post by Snarboo »

Marrub wrote:It will stick to 1.8.10 with extensions and backported features. This is only because 1.8.10's renderer works on a wider range of hardware.
As much as I'd love to use the new one, I do know project developers who can't run 2.x. (This includes Terminus.)
Why not keep the software renderer intact, then? I can understand wanting to support legacy hardware, but isn't that the exact purpose of the software renderer?

I guess there is the whole palette problem...
User avatar
TerminusEst13
Posts: 1625
Joined: Mon Nov 09, 2009 3:08 pm
Twitch ID: TerminusEst13

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

Post by TerminusEst13 »

The software renderer also has a mess of Build code in it, unfortunately. 1.8.10 is more compatible with a wider variety of hardware with less issues, with the downside of being a bag of dicks to wade through on the programming end.

Plus, if we purposely don't try and stay 1:1 with GZDoom, less chance of getting into any potential upsets with Graf/Randy, since they'll still have the feature-superior engine.
We could also talk it out like reasonable adults, sure, but Just In Case.
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 »

Snarboo wrote:
Marrub wrote:It will stick to 1.8.10 with extensions and backported features. This is only because 1.8.10's renderer works on a wider range of hardware.
As much as I'd love to use the new one, I do know project developers who can't run 2.x. (This includes Terminus.)
Why not keep the software renderer intact, then? I can understand wanting to support legacy hardware, but isn't that the exact purpose of the software renderer?

I guess there is the whole palette problem...
This:
TerminusEst13 wrote:The software renderer also has a mess of Build code in it, unfortunately. 1.8.10 is more compatible with a wider variety of hardware with less issues, with the downside of being a bag of dicks to wade through on the programming end.
Basically.
There is a lot of copyrighted code from BUILD that I just couldn't care enough to rewrite, so I removed most of the software renderer code and removed vid_renderer.
Thus, the most logical solution is to just use the 1.8.10 renderer.
I mean, if someone really wants to (or me to) rewrite that code, I might switch to the new renderer. (Or.. perhaps make a very terrifying mess-jumble hybrid of fuck that allowed vid_renderer to go up to 2, allowing for use of the 1.8.10 renderer if the 2.x one fails to work? I don't know.)
User avatar
zrrion the insect
Posts: 2397
Joined: Thu Jun 25, 2009 1:58 pm
Location: Time Station 1: Moon of Glendale

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

Post by zrrion the insect »

This is fantastic news. I'll have to let some people know what's happened here. They'll be pretty excited.
User avatar
Wiw
Posts: 744
Joined: Thu Jun 11, 2015 1:58 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
Location: Everywhere and nowhere.

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

Post by Wiw »

This could change the market! Brilliant!
User avatar
Raziel236
Posts: 313
Joined: Tue Jul 02, 2013 7:26 pm

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

Post by Raziel236 »

So, just to clarify the process, can maps still be made in GZDoomBuilder, code and sprites still be done in slade, and then this is somehow imported into GLOOME?
ShinyCrobat
Posts: 65
Joined: Sat Jul 20, 2013 5:42 pm

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

Post by ShinyCrobat »

Finally! I've been wanting something like this forever! I'm curious though, how compatible will this be with existing GZDoom projects? Assuming they work on 1.8.10, obviously. Just want to know so I know how different it will be, and how many features that GZDoom already has it can take.
Edit: Oh, also, what are the options for Aspect Ratio Correction? I feel like that could mess with spriters who are used to 1:1 ratio for pixels.
User avatar
Snarboo
Posts: 2598
Joined: Tue Nov 29, 2005 4:37 am

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

Post by Snarboo »

Dumb question: does this still behave like GZDoom, in that it can still be played with all the major IWADs? I could see this being used as a vehicle for standalone mod releases built upon Freedoom, much like most Wolf 3D hacks, but with the added advantage of supporting custom maps!
xenoxols
Posts: 2106
Joined: Mon Mar 18, 2013 6:08 pm
Location: Americopolis

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

Post by xenoxols »

My only concern is resources being used commercially without permission, as most stuff around here isn't clearly licensed.
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 »

woah, nice stuff, can I use it with my cursed maze "indie" game? :D

EDIT: I actually want to give a touch on that wad, add some new stuff, fix others :D (no more terminal launcher :\)

I'll edit it on the future, but I would ask about how would GLOOME detect the .iwad? like if there's any wad file on the Gloome folder then it'll be an iwad? I mean that because making gzdoom thinks cursed maze was an iwad is a pain in the ass, I ended up renaming it to freedoom.wad and just loading some aditional stuff over the autoload ini...

^
I'm gonna check that information at night, so I may be doing some kind of dumb question.

And finally, a proper port for making indie games, I know it's too much to ask, but will GLOOME support more platforms than zdoom like Android/IOS/WP? that would make a paradise for me about mobile indie development, since, Doom engine is easy, and smooth with simple but fun wads.

EDIT2: I see there's some fmod code on it, also openal. About the fmod code, You will have no problem if someone wants to sell the game using fmod? (I heard there's some free indie fmod stuff, but I'm misinformed about it...)
Last edited by ibm5155 on Tue Jul 07, 2015 10:35 am, edited 2 times in total.
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 »

@marrub
Do you plan to remove the hardcoded functions that have customizable alternatives, deprecated functions and flags that are only kept around for mod compatibility, the kludge that's laying around in some places in the code and the occasional messy flags and functions that have better alternatives?
Some people would love to have a version of GZDoom with a clean codebase. This could be quite interesting.
This also would likely make the port lighter and possibly make it faster.
[edit]Also, will you make pull requests and shit for rewritten code that could be good or useful for (G)ZDoom?[/edit]
HexaDoken
Posts: 325
Joined: Thu Dec 01, 2011 7:34 am

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

Post by HexaDoken »

TerminusEst13 wrote: GLOOME is a commercial-friendly GPL-compliant rebrand of the GZDoom 1.8.10 engine, which is based on the ZDoom engine, which in turn is based on id Software's Doom engine.
Why did I read that as "...which, as it turns out, is based on id Software's Doom engine"?
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 »

It would be like hmm saying go language is based on C language, but both being two different things
User avatar
TerminusEst13
Posts: 1625
Joined: Mon Nov 09, 2009 3:08 pm
Twitch ID: TerminusEst13

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

Post by TerminusEst13 »

Raziel236 wrote:So, just to clarify the process, can maps still be made in GZDoomBuilder, code and sprites still be done in slade, and then this is somehow imported into GLOOME?
Yes. The editing process is exactly the same, with the caveat that GZDoombuilder obviously does not natively support GLOOME and so testing out maps is a little bit of a clunkier process.
I've been working around this by directing GZDoombuilder to open up my executable instead of the GZDoom executable. Marrub's been working around this by, uh, not testing using GZDB at all and just opening the maps directly.
ShinyCrobat wrote:Finally! I've been wanting something like this forever! I'm curious though, how compatible will this be with existing GZDoom projects? Assuming they work on 1.8.10, obviously. Just want to know so I know how different it will be, and how many features that GZDoom already has it can take.
Edit: Oh, also, what are the options for Aspect Ratio Correction? I feel like that could mess with spriters who are used to 1:1 ratio for pixels.
Anything you can load in 1.8.10, you can load in GLOOME. You can even load iwads and Doom mods to play on instead of GZDoom, if you're weird.
Also, that's an interesting question. Being able to remove the vertical stretch might be a good idea, especially for more hardcore pixel enthusiasts.
xenoxols wrote:My only concern is resources being used commercially without permission, as most stuff around here isn't clearly licensed.
This is definitely a big concern I have. I'd like to hope that people will be smart and ask permission, but that won't happen.
ibm5155 wrote:I'll edit it on the future, but I would ask about how would GLOOME detect the .iwad? like if there's any wad file on the Gloome folder then it'll be an iwad? I mean that because making gzdoom thinks cursed maze was an iwad is a pain in the ass, I ended up renaming it to freedoom.wad and just loading some aditional stuff over the autoload ini...
And finally, a proper port for making indie games, I know it's too much to ask, but will GLOOME support more platforms than zdoom like Android/IOS/WP? that would make a paradise for me about mobile indie development, since, Doom engine is easy, and smooth with simple but fun wads.
[...]
EDIT2: I see there's some fmod code on it, also openal. About the fmod code, You will have no problem if someone wants to sell the game using fmod? (I heard there's some free indie fmod stuff, but I'm misinformed about it...)
At the moment, GLOOME just detects the .pk3 like an iwad. 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.
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.

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.

Return to “Abandoned/Dead Projects”