This needs true-color rendering with colored lighting at the very least. It's not fun when everything is grey/brown pixel smudge.
Retro game engine for developers that enjoy creating games like it's 1997
51–60 of 124 posts
Re: Retro game engine for developers that enjoy creating games like it's 1997
#52This needs true-color rendering with colored lighting at the very least. It's not fun when everything is grey/brown pixel smudge.
There's two other cool engines with a software renderer that support colored lighting:
https://github.com/leilei-/Engoo
Both are Q1 though. However, the gray-ish/brown-ish look is entirely dependent on the color palette that you chose to use in your game. You have 256 colors to choose from, and with the 256x320 colormap, you get 64 shades of each.
Re: Retro game engine for developers that enjoy creating games like it's 1997
#53This is really cool, and I can’t believe I’ve lived long enough to see Quake 2 be called “retro.” I’ll likely live long enough to see the Unreal Engine of today called retro. I’ve never thought of this before, and it’s wild.
I wish they released UT99 under the GPL.
Re: Retro game engine for developers that enjoy creating games like it's 1997
#54Earlier quoted context omitted.
Could just release the game engine binary with a separate loader for assets and license check... Utilizing steam for distribution and in game features could help too.
You can't link a GPL engine against the Steam library (Steamworks SDK is proprietary) and then distribute binaries without violating the GPL. It's also not assets that are the problem, it's the game-specific code.
You could separate the rendering logic from the game logic and create messaging channels for them... Also, the game specific code is rarely worth anything without the assets... that's why Id has released these codebases, so that people can learn/adapt... the assets retain copyright, etc. Also, you can separate out the game runtime from launcher parts... the launcher can contain other communication channels and be responsible for delivering assets.
As I said, it isn't even about creating a perfect abstraction, just enough to minimize the effect of piracy.
Re: Retro game engine for developers that enjoy creating games like it's 1997
#55This is really cool, and I can’t believe I’ve lived long enough to see Quake 2 be called “retro.” I’ll likely live long enough to see the Unreal Engine of today called retro. I’ve never thought of this before, and it’s wild.
Came here to say the same; it’s like the first time I heard Nirvana on a “classic rock” station.
Re: Retro game engine for developers that enjoy creating games like it's 1997
#56Earlier quoted context omitted.
You can't link a GPL engine against the Steam library (Steamworks SDK is proprietary) and then distribute binaries without violating the GPL. It's also not assets that are the problem, it's the game-specific code.
You could separate the rendering logic from the game logic and create messaging channels for them... Also, the game specific code is rarely worth anything without the assets... that's why Id has released these codebases, so that people can learn/adapt... the assets retain copyright, etc. Also, you can separate out the game runtime from launcher parts... the launcher can contain other communication channels and be res…
I think when engineers answer these questions it's easy to get bogged down in issues like whether something is a single process linked together or whether you have multiple processes communicating with one another. I don't think these arguments have serious legal merit.
The question at hand is whether the game you are making is a work based on the engine. If true, to comply with the GPL you must release source. Establishing communication channels so that you can put your game logic and the engine in separate processes are not a silver bullet, they don't change the question of whether your game is a work based on the engine, they mostly change the mechanics of how your game is a work based on the engine. There are a lot of difficulties in making this argument.
The court is probably not interested in hearing about whether different components are running in the same process and linked together or whether they are running in separate processes and communicating through IPC. At best, I'd say that you're running the risk of an expensive court case, and at worse I think you stand a good chance of losing it, not having enough money to fight it (because the legal arguments are quite sophisticated), and suffering from things like DMCA takedown notices in the meantime.
I think the trap that software engineers fall into, far too often, is that we try to answer legal questions using the same techniques we use to solve technical questions. The question of, "Is this an executable?" or "Does this use dynamic linking?" is something you can answer based on your definitions of what an executable is. However, legal arguments don't happen in such a mechanical fashion. Contracts and laws are written in prose, not code, and they are interpreted by humans which are basically trying to do understand some combination of "what did the author mean?" and "how would people generally interpret this sentence?"
Re: Retro game engine for developers that enjoy creating games like it's 1997
#57This is a cool project! - CMake, yay! These make generating build files for a variety of platforms (even Windows) a breeze. It also works with code completion stuff (CLion IDE, KDevelop both have CMake-based projects) - I like how it splits stuff up as well ( https://github.com/klaussilveira/qengine/tree/master/src/gam... ). - As for vendorizing SDL2, there is an opportunity for optimization: The shared libraries and…
The license can be a problem for some studios, specially ones with uncomfortable contracts with publishers. If you are in that situation, I highly recommend writing a LuaJIT integration layer. The game code is very well separated from the engine, and qengine already removes a lot of non-generic game code from Q2. So all you have to do is delete a little bit more, write some glue code to tie in Lua, and you can write…
I think using Lua scripting like that still counts as "dynamic linking" from the point of view of the GPL.
Re: Retro game engine for developers that enjoy creating games like it's 1997
#58Earlier quoted context omitted.
It depends on how the game engine works. If your game code is directly linked with the engine in the same executable (or a shared library) it would fall under GPL. If the game engine provides a virtual machine that executes bytecode compiled from game scripts I don't believe that would count.
That's an argument, but I belive it wouldn't stand up in court. If you have something like the JVM, you can make a case that the program and the JVM are separate works. If you have something like Quake, I don't think that would hold up, I would consider the bytecode and Quake to form a combined work. At best, I think you would be testing in-court what a "derived work" is or what it means for a work to be "based on" a…
FWIW, the source to Quake's bytecode (progs.dat, written in QuakeC) is available under the GPL. I think, since the bytecode source was distributed separately from the engine source, you could get away without distributing later bytecode source as long as you start from scratch.
Re: Retro game engine for developers that enjoy creating games like it's 1997
#59Re: Retro game engine for developers that enjoy creating games like it's 1997
#60This needs true-color rendering with colored lighting at the very least. It's not fun when everything is grey/brown pixel smudge.
There's two other cool engines with a software renderer that support colored lighting: http://super8.qbism.com/ https://github.com/leilei-/Engoo Both are Q1 though. However, the gray-ish/brown-ish look is entirely dependent on the color palette that you chose to use in your game. You have 256 colors to choose from, and with the 256x320 colormap, you get 64 shades of each.
Even GZDoom (A Doom port) has software color lighting now, so I'm shocked this doesn't have it, that's all.
And engoo is very good; I was one of its beta testers!