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

[TerminusEst13]

https://github.com/marrub--/GLOOME/

GLOOME:

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.
It's a little bit incestuous.

There's been a lot of discussion as of time of this writing about the viability of using Doom source ports to create full-fledged indie games. A lot of people have come out with some astounding projects; massive mapsets, complete gameplay overhauls, redone graphics, etc.
But every now and then, there's a project that's completely unlike Doom at all, to the point where people say it would be better as its own thing, rather than a "mod". And sometimes these discussions just kind of...end with the usual question marks.

Is it possible to do this? Can mods really become standalone games? Would it even be feasible to undertake all the work for a small community? What draws the line between an extremely in-depth "mod" and a fully standalone "game"? Wouldn't we still need to have a doom2.wad to run? If we still have ties to Doom, won't that cause legal issues? What would Carmack do?

This fork hopes to address these issues. All of the licensed code has been rewritten. All of the legally-questionable code (such as Ken Silverman's Build code) has been plucked out and replaced with either more legally-compliant code or outright rewritten. The engine itself is completely open-source and free for anyone to modify, adjust, distribute, or whatever as they please.
With this, we hopefully have an engine where someone can make a completely new not-Doom game with and distribute among other sites, like RPG Maker was to Yume Nikki or Cherry Tree High Comedy Club.

Someone completely unfamiliar with Doom, the Doom modding scene, or anything at all can just download a game, fire up the .exe, and play it without needing any know-how or "drag this .pk3 onto this .exe" or "load up multiple files" or "DON'T PUT IT IN YOUR SKINS FOLDER FOR THE LOVE OF GOD". If somebody wanted to make a full-fledged indie first-person-shooter, they can use this engine to create a slew of new maps, new enemies, new levels, new items, new weapons, and more, and then throw it up on Steam without worrying about Doom copyrights.

CREDITS:

Spoiler

John Carmack
- The forefather of everything. Not just Doom, but for his incredible generosity and astounding contributions to the video game industry. Without his work, we would not be where we are now. The entire scene would be a wildly different place.
Thank you, Carmack.

Randy Heit and Christoph Oelckers
- Creating ZDoom and GZDoom, of which, of course, this is based on (and where at least 99% of the code comes from). Being amazing programmers and keeping up with a source port for 20 or so years. Without these people, this port would have not even been a thought.

JP LeBreton
- Project lead of DECK, one of the big motivators/inspirations behind GLOOME.

marrub
- Did pretty much everything else.

TerminusEst13
- Uhhhhhhhhhhhhhhh moral support? idfk

Project 67 / Nocturne in Yellow:

/

The demonstration projects for GLOOME to show off the engine's capabilities to the world and to show people unfamiliar with ZDoom what can be done with Decorate and ACS. They're small, not exactly on par with BTSX, Golden Souls, Putrefier, or even Zen Dynamics, but they'll suffice. We even have placeholder graphics and everything.
Project 67 is a straightforward science-fiction run-and-gun arcade action shooter, with an emphasis on killing robots, getting points, and using rad guns. It is being made by marrub, the head developer of the GLOOME engine, and nobody knows better how to showcase the features of the engine than he.
Nocturne in Yellow is an entry for the 2015 Indie Game Maker Contest, a challenge to make a complete game in a single month, and is a more slow-paced gothic adventure intended to be reminiscent of a first-person CastleVania than Doom. It is being made by TerminusEst13, some dork.

While both of these projects are early on in development, we will be keeping the topic up to date with progress and contributions.

[SyntherAugustus]

Interesting!

The first question I suppose is if it will be capable with GZdoom 2.0, or was it purposely based off of the old render?

edit: Answered. No.

<@TerminusEst13> Yeah, likely no. The OpenGL upgrade kind of...left a lot of people behind.

[TerminusEst13]

Yeah, sorry. 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.

[Tango]

this is awesome. really glad to see this :D I would love to eventually try to put together a unique game, probably with graphics on par with Minecraft so that I would actually be capable of doing it. this actually has me pretty excited...

[40oz]

Pretty cool. That level design is super archaic though if you don't mind me saying :P

Would you like any help with it? I can do all sorts of graphics and wall textures and stuff.

[TerminusEst13]

Yeah, neither of us are great level designers at all, so the maps for our projects will probably what only the most charitable of critics will call "basic".

That being said, help would certainly be most appreciated. I'll be moving all supplies and resources for Nocturne in Yellow to github within the next few days for public perusal, and I'll see if I can convince marrub to do the same.
Graphical stuff is certainly our weakest points at the moment, but down the line some extra eyes to look over maps and tell us how to make things not bad would also be sincerely appreciated.

[Altazimuth]

Really great idea. Fairly noble cause, also basic on 1.8.10 removes the need for indie devs dealing with having people whinge about issues withrunning this on their cobweb covered and dusty old relics that they call graphics cards.

[taufan99]

Hey Terminus, I saw your thread in the ZDOOM forum earlier, and I must say, this is one of the best things to come out from id Tech 1, not just DOOM. Keep up the good work preserving id Tech 1 for the later generations of gamers! :)

[scifista42]

Yes! I really like to see this. I hope to see indie FPSs on an advanced Doom-like engine becoming much more frequent, and this can help it greatly. The easy mapping could lead more people in the "professional scene" to care more about quality singleplayer FPS level design and gameplay (and multiplayer too, of course), which are qualities that I personally love, and I find them in good Doom wads above any other games.

[SavageCorona]

So is this like an engine you can develop a whole game in like assets, maps, etc without even any coding knowledge at all (since it's already there I assume) and then release it commercially for money?

Basically sell really elaborate Doom mods in the same way Heretic, Hexen and Strife were?

[jmickle66666666]

This is fantastic! Really cool stuff, can't wait to mess with it.

[TerminusEst13]

SavageCorona said:

So is this like an engine you can develop a whole game in like assets, maps, etc without even any coding knowledge at all (since it's already there I assume) and then release it commercially for money?

Basically sell really elaborate Doom mods in the same way Heretic, Hexen and Strife were?

They'd need to be complete and total conversions, everything from scratch. So, yes, you'd need quite a bit of coding familiarity with Decorate, SBARINFO, and ACS. You can't just swap in new graphics in and call it a full game--there's no Doom stuff in here to inherit from.

[MTrop]

Very nicely done. I have three questions, though.

Is the software renderer still intact, or has that been gutted?

What approximate version of ZDoom is compatible with GLOOME's current feature set?

Does it still use peer-to-peer networking, or client-server?

[TerminusEst13]

The software renderer has been gutted due to the Build code. Sorry.

If we're talking approximate versions, then 2.7.1, though there's quite a few dev-build features in there.

Networking is the exact same as GZDoom's, so it's a peer-to-peer model.

[SyntherAugustus]

I wonder if it would be legit to say "For multiplayer, use Zandronum" and have a Zandronum port link in the game if someone wanted to Multiplayer.

I'm toying around with ideas on how I would implement multiplayer in my game. There would be a base resource file and two code files, one for a GZDoom based port (maybe Gloome) and another for Zandronum usage.

[MTrop]

TerminusEst13 said:

The software renderer has been gutted due to the Build code. Sorry.

That's a little bit of a bummer. I liked full control over the color shading.


I have more questions.

More of a GZDoom question then anything, really - Are the GLSL fragment programs modifiable, or does it still use the D3D compiled HLSL shaders still present in the engine PK3 in some way (probably a dumb question)? I liked the ability to use a limited or exaggerated palette.

Are any binaries or builds available, and if so, which operating systems are supported?

How actively-developed will this be? Will it still pull in commits from ZDoom's master to stay up-to-date with bugfixes, at least?


Sorry if it seems like I'm grilling you for answers - something like this seems too good to be true, to me.

[scifista42]

MTrop said:

I liked full control over the color shading.

Do you mean custom COLORMAP trickery, or something else? If the latter, I thought that truecolor shading was easier to reliably predict and set (="control") by the mapper. Bonus points for the possibility of truecolor colored lighting.

[MTrop]

scifista42 said:

Do you mean custom COLORMAP trickery, or something else? If the latter, I thought that truecolor shading was easier to reliably predict and set (="control") by the mapper. Bonus points for the possibility of truecolor colored lighting.

It isn't a question of predictability. If you had control over the method of color mixing, there is no prediction. A 256-color palette plus a distinct COLORMAP granted this control in the software renderer.

The COLORMAP was essentially a way to have an input color, a calculated shade value due to distance calculation, and a lookup for the resultant color. That's it. You'd be coerced into the colors in the palette, but then again, you can write the palette.

You actually lose control if you leave it up to the stock color mixing. It is only as predictable as knowing the equation for mixing color, given the color of the surface, sampled texel color, sampled lightmap color, Z-position in the depth buffer, and the fog color plus fog coefficents. You retain that mixing control if you can write that equation. You relinquish it if you can't write it. If it lies in the GLSL shaders, then it can be rewritten according to the modder.

Truecolor output only expands your color resolution. It never grants "control."

[SavageCorona]

TerminusEst13 said:

They'd need to be complete and total conversions, everything from scratch. So, yes, you'd need quite a bit of coding familiarity with Decorate, SBARINFO, and ACS. You can't just swap in new graphics in and call it a full game--there's no Doom stuff in here to inherit from.

Yeah that's what I meant. I forgot about monster and weapons code I'm really dumb. I guess I meant all the engine code is there. Which is obvious.

[esselfortium]

What MTrop said is definitely one of the remaining advantages to designing for software mode.

I took some advantage of it with BTSX's palette, where the colormap was handcrafted along with the palette to do effects like hue-shifting colors into each other. The custom colormap used most noticeably affects blue and orange colors, which creates some additional vividness that's lost in GL. Being able to set up comparable effects with shaders would be pretty slick.

There are definitely much more advanced and ambitious ways that a custom colormap can be used in conjunction with a custom palette, but I'm not sure offhand how many other examples of similar effects exist in Doom WADs. Would be interested to find out though .:,

[Linguica]

It's certainly possible to use the Doom colormaps in a hardware renderer. https://github.com/cristicbz/rust-doom has (to the best of my knowledge) perfectly emulated light falloff.

[TerminusEst13]

MTrop said:

Sorry if it seems like I'm grilling you for answers - something like this seems too good to be true, to me.

No worries, I understand completely. There's certainly a lot of ground to cover, and both of us are figuring things out as well.
That being said, marrub answers:

<marrub> #1: I'm pretty sure 1.8.10 was the last version to have working GLSL shaders, not entirely sure as I've never looked at or used the code for that
<marrub> 2: I don't have any binaries available, but I can make some for windows (and probably linux as I have a triple boot setup) -- it should support everything that gzdoom normally supports as it doesn't have any new system-dependant code as far as I can remember
<marrub> #3: I will backport most things that are requested (especially if you point me to a specific commit), pull requests will mostly be accepted
<marrub> oh
<marrub> also, an extension to #3
<marrub> see the zdoom forums thread for a bit more info, as I do state some of my future plans for the engine there

[Gez]

MTrop said:

More of a GZDoom question then anything, really - Are the GLSL fragment programs modifiable, or does it still use the D3D compiled HLSL shaders still present in the engine PK3 in some way (probably a dumb question)? I liked the ability to use a limited or exaggerated palette.

The HLSL shaders are used by the software renderer. I'm not sure what they actually do, but they're from ZDoom, not from GZDoom. So in GLOOME they'd pretty much irrelevant from the start; no part of GZDoom's OpenGL renderer code ever referred to them in any way.

[MTrop]

Gez said:

The HLSL shaders are used by the software renderer. I'm not sure what they actually do, but they're from ZDoom, not from GZDoom. So in GLOOME they'd pretty much irrelevant from the start; no part of GZDoom's OpenGL renderer code ever referred to them in any way.

I kinda figured. That just raises questions about ZDoom, but definitely shines some light on the software renderer.

Can't be too hard to write a "software shader" path for GLSL that simulates COLORMAP use ("software" in name only). Just gotta figure out what would be the best combination of uniforms and samplers to pass to the prospective shader. Hell, I'll write it if need be.

[jmickle66666666]

request: clear guide to what is needed to be included before a wad will run in Gloome, to fulfil iwad requirements

another request: make those requirements as little as possible to aid rapid developement

[Gez]

AFAIK for ZDoom to successfully launch, the only thing you need in your IWAD is... A PLAYPAL lump. You'll get warnings about missing resources (e.g., no TITLEPIC to show) and of course you won't be able to start a game at all, but it'll successfully run until displaying the menu instead of aborting with an error message or, worse, crashing.

[scifista42]

So, will the user (game designer) have to write his own MENUDEF as the first thing?

[jmickle66666666]

If this is true, that's really cool. My request is more about making it as clear as possible to developers just so they don't have to find out about obscure issues by trial and error etc.

A simple guide along the lines of "Here's how to make a thing for Gloome in X easy steps!" and at the end have something to play.

[Jaxxoon R]

Oooh my. This is exactly something I've been waiting for without knowing that I was waiting for it. I'm curious though, is there to be a prebuilt version in the future? What exactly are the new exclusive features this has? Is there a generic "game.pk3/wad" sort of thing going on that it will automatically look for in the program directory and load? Are there still predefined ACTOR and WEAPON classes like in gzdoom.pk3? Is there anything that GZDoom can do that GLOOME cannot?

[esselfortium]

Is it possible for a game to define the intended GL lighting options and hide them from users? GZDoom's apparent inability to ensure that lighting mode, ambient light level, and dynamic lights will be configured correctly for the wad makes it rather awkward to use its features. (See: Phocas Island 2's calibration room.)