Chilvence
Ogre
Posts: 55
|
A few games with my brother helped renew my interest in Generations the last couple of weeks - quite honestly I only played online once, but my skills with these sorts of games typically stop me from enjoying the online play. In my circle, there is nobody else who would want to play any sort of deathmatch type game so I decided to leave it be until 1.0 came around, hoping there would be enough plebs like me playing to stop me wanting to bang my head into the desk.
But since I am still watching, I am aware of the fact that you guys are building your own standalone executable - afaik, with particle effects, weapon animations, and who knows what else.
I've seen what happened with the Doom source, where everyone and their mother has made their own version, with incompatible features, different (sometimes trivially) implementations, patchy cross platform support, and endless user generated holy wars. So in the interest of not wanting the same to happen with Q3, I want to ask, is it really necessary to branch the source, if you can instead run with something that already exists?
Are there any features in gen.exe that would break compatibility with ioquake3 or classic quake 3?
I think it would be great if the base source code would grow as different teams require, resulting in a unified project that shares all of its benefits. It means the 'de-facto' q3 project gets stronger over time, and that I as a simple player only have to use one program.
OR it could just be an impossibly limiting request, which would stifle any freedom to just have fun building a q3 derivative project.
Opinions?
|
|
|
|
|
Logged
|
|
|
|
|
fourier
|
To me, it doesn't matter if it is compatible. The people who play generations are already downloading ~300mb of files, so they aren't going to be just wandering in from the q3 server browser and downloading a tiny file with autodownload. The people who play gen are going to be coming to this site to download the mod which will, presumably, provide the exe in the same installer or zips in the future for the 1.0 release.
Yes, it would be fantastic if all the programming communities worked together on a project to basically create a unified new point release, but it isn't going to happen. ioquake3 is already looked down upon by some members of the dying community.
Also, with a required new exe, Phoenix can do a lot to abstract some stuff in the game and cgame modules in the future to prevent hacks and other nuisances from people who have nothing better than to destroy the fun of the game.
|
|
|
|
|
Logged
|
|
|
|
scalliano
Elite
Posts: 1095
Yup, that's me
|
I use ioq3 for offline play, mainly because of the better hardware compatibilty on my system (widescreen video, fixed skyboxes, etc) but I think the comparison with Doom source ports is unfair. There are a lot of Doom ports out there, but they all have their merits. If you want visuals, you go for Doomsday. Gameplay enhancements? ZDoom. True 3D? GZDoom or Legacy. True lighting? EDGE. I have no loyalty to any of these and those people involved in these "holy wars" need their heads looked at, frankly.
The fact is that gen.exe will still run VQ3 and any other Q3 mods you can think of. Hell, you could use it for Painkeep if you wanted. A new .exe affords more freedom in implementing Gen's features. Besides, there are a lot of Q3 mods that are going totally standalone, UrT and WoP spring to mind, not to mention OpenArena which is essentially a freeware version of Q3 (which uses ioq3, incidentally).
|
|
|
|
|
Logged
|
PSN ID: scalliano
The Arena knows no gender, colour or creed, only skill.
|
|
|
|
Phoenix
|
My goal with the executable is as follows, in this order of priority:
1) Implementation of features necessary for Generations to function that cannot be done or done practically in the game, cgame, or ui .qvm modules.
2) Fixing of bugs in the existing Quake3.exe source, such as the long server run time bug. Ever log into a Q3 server and all the bobbing items are really choppy and any animated shaders are stalled on one frame, like fire effects?
3) Implementation of "nifty" features that cannot be done in the .qvm modules, such as improved dynamic lighting code (Vorlonesque is working on this), changes to sound attenuation and queuing, etc.
4) Retention of compatibility with existing Quake 3 Arena .qvm's if possible. I will break compatibility if I have to if there's no other way to make something work right for Generations, but I'd prefer not to.
What is not my goal with this:
- Creating an "all in one" engine to replace Quake3.exe for every mod project in existence.
- Creating "THE DEFINITIVE" Quake 3 engine that I must convert and convince every other modder to use.
- Unlinking Generations from a retail install of Quake 3 Arena. Generations cannot be a full stand-alone game due to character trademarks and licensing.
- Compatibility with OpenArena or any other "freebie" GPL'd Q3A projects. Again, trademark issues as well as licensing prevent explicit development in this direction. If happens to be compatible without us actually doing anything that's not my concern.
- Compatibility with the .qvm's for Generations to be able to run using an executable other than Generations.exe
Once the dust settles, the goal is to have Generations.exe able to run Generations and any other normal Quake 3 mod. You will NOT be able to play Generations without our executable. The .qvm's use new system trap calls that are unsupported in Quake 3 1.32 for stuff like sound attenuation control and old-style sound queuing for certain guns. That being said, according to the GPL license, once that executable is released we will also be required to make available the source code to the executable (not the game logic source for the .qvm's - that's still under the old Quake 3 license and will remain closed source). This allows two things. First, anyone downloading Generations will be able to trust the executable to not be malicious. Second, if someone really, really wanted to build their own version of the engine with feature X they could. What they cannot do is compile or examine the game logic since that will remain closed source. There are open-source purists who would complain about this stance, but making our game logic open source would open the door for easy client-side hacks and cheats to be written. By keeping the game logic closed source it helps lessen quick and dirty cheat authoring.
If it were possible to not do things in the engine, I would keep this a straight .qvm modification. Unfortunately there are several things that simply cannot be done without modding the engine. Several changes are fixes for severe bugs within Quake 3's executable. Others are features that do not work in the .qvm's, or suffer severe limitations. The particle system is a good example. Quake 2, on much older hardware, can handle 100 times more particles than I can efficiently render within the cgame module. In the current non-public test beta, I have a full Q2-style particle railgun trail. This is not the same trail effect used in .99f - that's actually a multi-segment model beam shaderized to look like particles, so it renders very quickly. The actual true particle trail, which nobody outside of the beta testers has seen, when fired across a large map causes framerates down in the 20's on my machine that can run Doom 3 at a steady 60FPS at 1280x1024. That's unacceptable. So, why the difference? Running particle math in the renderer is more efficient than running the particle math in the .qvm logic. So the particles will get moved engine-side and be triggered with system traps in the way Quake 2 handled it. I can render a lot more particles that way without the framerate loss, which will be a boon to older hardware which really need the CPU power for other things.
As for cross-platform support, I already have a version compiled and tested under Linux, though it's been a while since I've fooled with it because I only have a linux install on the other machine, which is currently idling as a server. When I get further along I'll set up a drive with a Linux partition on this machine and copy over the compiling instructions and see about automating the process a bit. It's my full intention to have cross-platform compatibility. That's a big part of the reason I've kept the .qvm system in place. I used to frequent quakesrc.org before Ender's server went down, and there's a lot of back and forth over native-only "purists" poo-pooing .qvm's, etc. I've seen the arguments against the .qvm system, but frankly I consider it just a lot of hot air. What I consider important is making the program work right on every system it runs. I KNOW the .qvm system works across platforms, and that Q3 handles it pretty flawlessly. Why break what I know already works? At times it might not seem that way, but Generations exists as a game to be played, not as a monument to my ego. That means I want everyone who owns Quake 3 Arena to be able to play the mod. If they think it sucks, that's fine, but if someone wants to play it but happens to be on a Linux machine or a Mac, why should that be a limiting factor? My goals with the engine enhancements revolve strictly around what is best for making Generations work best, and they don't extend beyond that.
Now as for a unified engine goes, it's nice in theory, but I can tell you it will never happen and why. Too many coders have very disparate and entrenched opinions on how things should be done. Coder A wants this, Coder B thinks that sucks and wants something else, and in the end you'll have a bunch of coders all bickering and accomplishing nothing because all of them think they are right and, to some degree, they all are. Every coder wants to do what is important to their own project. The only time I have seen unified engines work are actually engines like Zdoom and Doomsday where they are coding a single engine to run multiple game logic sets that are static and unchanging. Zdoom and Doomsday can work because the retail souce code for Doom, Heretic, and Hexen will not ever, ever change. That means separate coding teams can do the same thing with these sources. Trying to do this on separate, evolving projects simultaneously simply cannot work. Someone can take source from something like ioquake3 and utilize it in their own project, or base their code off someone else's source, but that's about it. I'll give you a good example from my own experience recently. I downloaded the ioquake3 source code. I can't compile it in Visual Studio. Why? Their solution files are a newer version, and upgrading my version is not a practical option right now. That would force me into using Mingw to compile their source, which would mean I would have to port my own source into ioquake3, learn how to compile it under Mingw (since I've not worked with Mingw for about 4 years), hope it works, then figure out how to get it all to compile under Linux again since my existing compile instructions would no longer be valid anymore. I'd really prefer to concentrate on writing my own code as opposed to learning new programming environments just to compile someone else's. I probably would look at using ioquake3 as a base for my own executable if it were not for the fact I cannot easily compile it, but since it's a hassle I have to weigh whether it's worth trying to fool with it or just soldier on and write my own code. Right now I have too much else to do, so it's not worth fooling with. Perhaps later it may be, but it's little things like that which make a unified engine a difficult prospect. I don't think the ioquake3 team, or any other mod team, would want several outside coders telling them what to do either, nor could I blame them. I'd feel the same way if someone from an outside project started telling me what to do just because they want some feature in the engine I'm working on, when it has nothing to do with my own project.
That's why I think it's better to collaborate in a forum setting like quakesrc had before it went down, where coders can discuss things and share helpful snippets, like major bug fixes, etc. It's less dictatorial and much more open to just share useful information or source than to try to force everyone into a single project.
|
|
|
|
|
Logged
|
  I fly into the night, on wings of fire burning bright...
|
|
|
Chilvence
Ogre
Posts: 55
|
Wow, big reply.
I guess I already knew such a thing would be impossible deep down.
All I really want to see though, is say you were to come up with something awesome and useful and generic enough to be usable by anyone, that it should eventually find it's way back to the core. It is a minor inconvenience to have different executables that are similar, but tailored for each game, but it is much more frustrating to be unable to use a feature because it isn't generically available.
For example zdoom has a million improvements over the stock ACS script that comes with hexen, but other ports wont go near it. Possibly because of the sticky license situation there... thankfully all quake code has been GPL from the get go, so no one will ever have to deal with that again.
|
|
|
|
|
Logged
|
|
|
|
|
fourier
|
The game source was available almost from the start (game was released in the beginning of December, and the game source came out in January I think), but the full source was released in Aug 2005
|
|
|
|
|
Logged
|
|
|
|
Chilvence
Ogre
Posts: 55
|
I know that, I was referring to the engine code specifically, which at the time of release was GPL'ed.
Doom's code was only made GPL after it was released, after a community request to id, and the code for Hexen and Heretic, while being publicly available, comes with a license that paradoxically forbids doing anything with it.
While in practice it is ignored, it still means you can't technically make your own engine that runs Doom+Hexen under the GPL without violating the token Hexen license.
It also means anyone can do anything with the original release of Doom source, upload it as a compiled binary, and keep all their changes to the source code completely secret. So any project under the original license rather than the GPL version can effectively be co-opted into a closed-source derivative, even if they themselves are keeping it open. Which actually happened...
So be thankful the license situation with Quake 3 is a little bit more clear cut, and remember it was Doomers that had to suffer all the teething problems!
|
|
|
|
|
Logged
|
|
|
|
scalliano
Elite
Posts: 1095
Yup, that's me
|
Yet most Doom ports out there run Doom, Heretic, Hexen and even Strife in some instances. Nice try, Raven. .gif) |
|
|
|
|
Logged
|
PSN ID: scalliano
The Arena knows no gender, colour or creed, only skill.
|
|
|
|
|
Chilvence
Ogre
Posts: 55
|
Yet most Doom ports out there run Doom, Heretic, Hexen and even Strife in some instances. Nice try, Raven. Actually, the Raven license was admitted to be a oversight on their part, Raven don't actually want to stifle anything except commercial usage of the code (which is a laughable idea anyway). But since they won't change the actual text of the license, it still turns some project admins green and nauseous. For example Odamex refuses to use any Raven code. The author of Eternity has actually tried to replace it, in a similar manner to the rebuilt-from-scratch Strife code. No less than three independent people wrote support for Strife without any access to the original code  Some people just don't like working on a big grey area. Others have just reasoned that they can trust Raven enough not to stamp on their face (which has proven to be true) |
|
|
|
|
Logged
|
|
|
|
|
Phoenix
|
If Raven says "We won't actively enforce this license" then the coders are free to use it and that's actually binding on Raven's part to some degree. Non-enforcement of copyright creates a kind of precedent for future enforcement claims. LeeMon did a lot of research into copyright law when Generations started up, and that's one tidbit he found out about it. This is actually where the concept of Abandonware originates. Despite claims to the contrary by some critics, Abandonware is a real thing precisely because of copyright law, not in spite of it. The term itself may not be a legal term but it describes what is in effect abandonment of copyright, which then makes something public domain. That's why some companies, like Fox, are extremely aggressive about copyright and trademark enforcement (hence the terms "foxing" and "being foxed" being coined in regards to mods being shut down for those reasons). They're paranoid about losing rights to their own stuff, and they don't want Joe Modder making something with their trademarks because they're afraid it will hurt sales if they make their own game later. Other companies are not so aggressive. Id tends to look the other way a lot, but there's limits to what they'll allow and I've seen mods shut down over crossing those boundaries.
Anyway.. I'd say as far as Heretic and Hexen are concerned, Zdoom and Doomsday are precedent that Raven is not going to aggressively enforce that particular license, so unless it's a strange point of honor with someone I don't see why they don't just use the code for their port if Raven said it was OK. Push comes to shove they could always mail Raven and ask. Since Raven owns the license they own rights to override it or grant explicit license as they see fit. Simple as that.
|
|
|
|
|
Logged
|
I fly into the night, on wings of fire burning bright...
|
|
|
scalliano
Elite
Posts: 1095
Yup, that's me
|
I have the ioquake3 source, so I can use features from there if they're of value.
[cough]skyboxfix[/cough]   (slightly) I remember reading about how the term "foxing" came about (in regards to an unofficial AvP mod) but it has always left me wondering how and why Justin Fisher never got his ass pounded over the Aliens mod for Doom. Given that it managed to be better than most of what Fox Interactive could come up with it has always puzzled me. |
|
|
|
|
Logged
|
PSN ID: scalliano
The Arena knows no gender, colour or creed, only skill.
|
|
|
|
|
|
