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

[Tango]

jmickle66666666 said:

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.

I'm a bit late, but... I don't suppose anything like this has popped up? it sounds simple enough getting a wad up and running from what I've seen in the thread, but a concise guide about what steps to take would be great :D I'm also having trouble finding info about GLOOME-specific features; is there a documentation somewhere?

[scifista42]

Feature request for GLOOME: Make it possible for the designer to define his own frame rate of game logic (=number of tics per second), as opposed to being hardcoded to 35.

Another feature request: Implement some kind of new "map format" which is not really a map at all, but just an empty dimension-less template space, capable of taking input from player's controls and displaying text/images as HUDmessages, being controlled via ACS or even a very new scripting language, and being enterable just like any normal Doom map can be (via exiting a previous map, via IDCLEV, or via console cheats for changing maps). Designers would find this useful for implementing their own "interactive 2D games" in ACS / another script, to complement (or even supersede!) standard Doom/Hexen/UDMF maps, perhaps as an intermission between them, level select hub, an ingame "minigame" map, etc.

[Jaxxoon R]

I'm still curious as to why midtextures flip out when you UDMF scale them. Is that just a result of using the 1.8 renderer?

[Shadow Hog]

scifista42 said:

Feature request for GLOOME: Make it possible for the designer to define his own frame rate of game logic (=number of tics per second), as opposed to being hardcoded to 35.

If I'm not mistaken, that's already a thing. Should be one of the new keywords for the GameInfo section of a MAPINFO lump, although I forget specifically which keyword that is.

[scifista42]

@Shadow Hog:

http://zdoom.org/wiki/GAMEINFO
http://zdoom.org/wiki/MAPINFO/GameInfo_definition

Neither of these pages documents such an option, which makes me think it doesn't exist. It makes sense to *not* exist in a Doom port, because Doom's actors and thinkers and balanced/adjusted for 35 FPS to "feel right" - but for a game-developer-focused engine, adjusting game logic frame rate should be an option. Perhaps even dynamically during the game (between maps of various kinds, see my previous post in this thread).

[Shadow Hog]

Of course the ZDoom Wiki doesn't document it; it's GLOOME-specific, and I don't think anyone's gotten around to adding any GLOOME-specific entries to the wiki pages.

A cursory look at the "features.txt" file at the root of the git repository reveals it's "ticrate", for what that's worth.

[scifista42]

Shadow Hog said:

it's GLOOME-specific,

I couldn't deduce from your previous post that you meant "GLOOME-specific", but OK, this explains it, thanks.

[Shadow Hog]

I thought it was implied, but I suppose I did a poor job at making said implication. Should've made that clearer.

[SyntherAugustus]

scifista42 said:

Feature request for GLOOME: Make it possible for the designer to define his own frame rate of game logic (=number of tics per second), as opposed to being hardcoded to 35.

Another feature request: Implement some kind of new "map format" which is not really a map at all, but just an empty dimension-less template space, capable of taking input from player's controls and displaying text/images as HUDmessages, being controlled via ACS or even a very new scripting language, and being enterable just like any normal Doom map can be (via exiting a previous map, via IDCLEV, or via console cheats for changing maps). Designers would find this useful for implementing their own "interactive 2D games" in ACS / another script, to complement (or even supersede!) standard Doom/Hexen/UDMF maps, perhaps as an intermission between them, level select hub, an ingame "minigame" map, etc.

I recall marrub has already made the first thing (the ticrate) possible.

[Sergeant_Mark_IV]

Is this really commercial-friendly?
File properties still shows copyright ownership of id Software. Or is it just a matter of modifying something before compiling?

[Graf Zahl]

Of course id still owns copyright to the code they wrote. You cannot simply take that away because you do not like it.

[Sergeant_Mark_IV]

Graf Zahl said:

Of course id still owns copyright to the code they wrote.

TerminusEst13 said:

All of the licensed code has been rewritten.

So, is it commercial-friendly or not?

[Graf Zahl]

One has nothing to do with the other. If the code is licensed under the GPL it's commercial-friendly - but the id copyright still applies.

[Sergeant_Mark_IV]

So, let's say I make a game on this engine and sell it on Steam/GOG with all resources made from scratch. A disclaimer at the loading screen stating that the "engine is written by id Software™ 1993-2015 All Rights Reserved®" is enough to prevent Zenimax from lawsuiting my ass with the force of a thousand suns?

[Graf Zahl]

That'd be exceedingly rude to all other contributors which claim copyright if you leave them out! :P

No, Zenimax can't sue you. id released the Doom source under the GPL, and as long as you use an engine based on that it's perfectly fine.

What you cannot do is do a commercial release with an engine that still uses the old id license due to some conflicts with other code. That means, that plain ZDoom and GZDoom are out. Gloome is fine, as far as I know.

[Sergeant_Mark_IV]

Graf Zahl said:

That'd be exceedingly rude to all other contributors which claim copyright if you leave them out! :P

Of course I would include everyone's names on the rolling credits. My question was more aimed towards the copyright disclaimer at the game's boot up screen and any legal issues that could attract the attention of Zen's watchdogs. Thanks for the clarification.