View previous topic :: View next topic |
Author |
Message |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Tue Mar 02, 2010 6:28 am Post subject: |
|
|
6.] svc_gamedir |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Sun Mar 07, 2010 12:35 am Post subject: |
|
|
OK, since the RemakeQuake mod runs on a server, I have gained a little additional perspective about things that should be standard.
Now I didn't think I'd have to say this, because it should be obvious, but ALL quake engines should be capable to connect to a server.
... Let that sink in for a moment...
Required features (and I mean basic necessities):
1. NAT fix
2. connect server.blah.net:port must be working (this includes non-standard ports like 26001, gasp!)
3. Ping in scoreboard - I want to readily see my ping and others' as well, this is just basic functionality
Now that seems to be hard. O_o Folks, this game INVENTED multiplayer! That's a proud heritage and any self respecting engine should connect to any old server and port, as well as show me my ping.
Another thing is
4. Support for fake CD tracks; Quake CDs are a thing of the past, just look at the Steam version. Ogg Vorbis is fine. The standard should be how Darkplaces does it. _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Sun Mar 07, 2010 12:39 am Post subject: |
|
|
Also, it would be good to sticky these QSB threads perhaps? I think this is important and anyone in a sane state of mind would want this. _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Mon Jul 19, 2010 8:58 am Post subject: |
|
|
OK, who is interested in really getting together and defining a small set of core features that a QSB 1 should contain - following the 90/10 rule that Baker mentioned, 90 percent of the gain for 10 percent of the effort?
http://quakery.quakedev.com/qwiki/index.php/QSB
The list of map limits and extensions on the Quake Wiki page is still too big for a first attempt IMO. So let's try to pare it down:
1. Map limits; example mod
RemakeQuake is a humungous mod, and we already break most of the limits listed by Urre in that draft. So regarding map limits, I'm pretty sure RMQ could serve as a test case for engine coders, and several of them have kindly expressed interest in supporting it, too. When it comes to oversized maps with badly broken limits made by self-absorbed, criminally negligent outlaw mappers, I guess we are a good example, and a realistic example at that.
QSB 1 should aim to only include stuff that actually, realistically, gets used and can be tested (engine coders can simply get access to our SVN as watchers). In the case of the rotating entity stuff and flickering bmodels, there was already a working collaboration like that.
I think the full list of map related limits ("phat map support") should be part of QSB 1, since this really gets used and I think it isn't too hard to implement. Also, lots of engines support most of that already, anyway - it is in accordance with the 90/10 rule.
I count as part of "phat map support" also an increased map size limit - some of our maps will break the unwritten law of the 4096. Not by much, but they will break it. This means QSB1 will break protocol 666, for example, and it will need its own.
2. Extensions and general fixes
RMQ uses stuff like rotating bmodels, entity alpha, fog, skyboxes and lit files. We're thinking to include stuff like FRIK_FILE and perhaps a few other extensions.
I do think that checkextensions must be in QSB 1, along with things like FRIK_FILE, .lit file/skybox/entity alpha support, rotating bmodel support - including smooth angles (breaks protocol 666 again) -, and also a common QSB_FOG format much as defined here:
http://quakery.quakedev.com/qwiki/index.php/QSB_FOG
and the list of gameplay fixes defined as QSB_GAMEPLAYFIXES:
http://quakery.quakedev.com/qwiki/index.php/QSB_GAMEPLAYFIXES
as well as the bugfixes mentioned on the wiki page.
All of that is stuff that actually gets used, fixes gameplay bugs, and is widely implemented and working (90/10 rule). We should probably add external texture support to that list, as defined in the QSB wiki entry.
Engines must also contain fixes for flickering (rotating or otherwise) bmodels; mh posted a fix recently. RMQ includes at least one test case for this.
44100 kHz sound support is required by RMQ; this should be standard anyway. Is there an engine that doesn't support this?
If I'm not mistaken, this sums up the stuff that RMQ uses currently or in the near future (like FRIK_FILE). This is as good a starting point as any, and the advantage is that there is a real-world test case with its own (Fitzquake-derived) engine and protocol (999).
3. Network protocol
A few fixes require protocol changes; for example large map capacity and smooth angles. In a poll on this forum, there was a 14 : 0 vote PRO new network protocol. So let's have it.
Out of necessity, RMQ created its own protocol (999) which right now basically is PROTOCOL_FITZQUAKE (666) with large map support (float coords) and smooth angles (floats again) added on top of it. Protocol 999 should be considered in-development, though; a possibility is to use 777 as a short-term solution (fitz666 + float angles/coords), while 999 is used as a testbed, and an eventual, finished, QSB protocol would be protocol 1000.
Of course there can always be discussion about numbering and general features of both the short-term and long-term solutions. But again, I think the 90/10 rule applies: Let's go with something that exists already, and augment it. Protocol 666 includes most of the required map limits stuff and entity alpha support, it is well commented, and easily extensible.
Future / Timeline
After QSB 1 is defined and engines start supporting it, more extensions can be added to it; this would be the main point of QSB 2. Protocol changes and refinements would go into protocol 999. At some point after QSB 2 is finished, protocol 1000 is finalized.
Implementation
The idea of the 90/10 rule (90 % gain for 10 % of the effort), or going with only a small core set that is largely already supported, makes the most sense.
I'd be willing to write down the specs and hopefully transform input from engine coders into a detailed list.
Very basically, QSB1 would include
a) phat map support
b) checkextensions and common map-related extensions
c) a chosen few non-map related extensions, like FRIK_FILE (QSB 2 would focus on more extensions)
d) Protocol 777 (or whatever the number ends up to be - while 999 is used as a testbed, and eventually becomes protocol 1000)
e) bug fixes, gameplay fixes, and 44100 kHz sound support.
Does that sound roughly agreeable? _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Mon Jul 19, 2010 10:08 am Post subject: |
|
|
a) if conformance is testable rather than limits specified which may not actually exist, sure.
b) checkextension is a given. tracebox is somewhat fundamental (and easy). not sure what else you'd include.
c) string manipulation is good, but how many tempstrings do you include? (bearing in mind that an engine that supports unlimited makes a baaad engine to test mods). And what's the min required length of a temp string?
Many people object to the fopen part of FRIK_FILE. Strings are useful, but it should be a choice whether fopen ever succeeds, though it should at least be implemented to correctly return an error.
There are many pure-qc functions which would be easy to provide a tutorial for, you can probably get away with adding quite a few that way (sin+cos+sqrt+stof+etc).
d) personally I would rather wait for a completed protocol than implement a partial protocol, for the server anyway.
For clients its fairly easy to add new protocols if they just add rather than change.
For testing compatibility with clients, a demo containing each required protocol with the features provided by it would be a wise choice for conformance testing of clients (easier to get running than a server+mod). But I do urge against too many protocols.
e) 44khz changes how the audio sounds. Not everyone prefers hearing the original sounds at 44khz. One specific example is the lightning gun being sampled at 16khz and played at 8khz. Play it at 44khz and it'll sound quite different. Alternatively, many bits of current hardware support only 48khz, and resampling twice can lose a bit. So please specify a cvar name and a set of values, rather than a default. _________________ What's a signature? |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Mon Jul 19, 2010 3:24 pm Post subject: |
|
|
On a) I'm pretty sure we will be able to provide test cases for the raised limits and features specified.
b), tracebox is reasonable, taking suggestions for other pretty basic and easy to implement extensions.
On c), good points... would like to know what others think.
On d), I understand that, but how would you handle a QSB 1 requirement of large map size / smooth angles support without a partial protocol? Leave it to the individual engines how they want to support it? I guess that could work, too.
On e), OK, noted. I was only thinking of support for -sndspeed 44100 / s_khz if required, with 11 kHz remaining the default. Not striving to change the default. _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Mon Jul 19, 2010 4:04 pm Post subject: |
|
|
goldenboy wrote: | 3. Network protocol
A few fixes require protocol changes; for example large map capacity and smooth angles. In a poll on this forum, there was a 14 : 0 vote PRO new network protocol. So let's have it.
Out of necessity, RMQ created its own protocol (999) which right now basically is PROTOCOL_FITZQUAKE (666) with large map support (float coords) and smooth angles (floats again) added on top of it. Protocol 999 should be considered in-development, though; a possibility is to use 777 as a short-term solution (fitz666 + float angles/coords), while 999 is used as a testbed, and an eventual, finished, QSB protocol would be protocol 1000.
Of course there can always be discussion about numbering and general features of both the short-term and long-term solutions. But again, I think the 90/10 rule applies: Let's go with something that exists already, and augment it. Protocol 666 includes most of the required map limits stuff and entity alpha support, it is well commented, and easily extensible.
|
What about QuakeWorld ? Does QSB 1 will apply to it ?
TBH my concerns are less about added features and more about sending coordinates and angles as floats over network. This may be OK for single player, but surely will suck for multiplayer. Unless of course we accept the fact that nobody will be playing in a 28.8k modem nowadays (well, except maybe leileilol).
IF the needs of extended coordinates for maps and more precision in angles could be restricted to single player, I'd say let's implement a network bypass and feed the extra precision info directly from the server side to the client side (I believe Baker posted code about this some time ago), so we can think about a good protocol solution to QSB 2.0. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
mk

Joined: 04 Jul 2008 Posts: 94
|
Posted: Mon Jul 19, 2010 6:43 pm Post subject: |
|
|
Some suggestions:
- Feature parity on the support and rendering of the different 3D model formats (BSP, MDL, SPR and any additional custom model formats).
This is useful for things like using BSP models on the thunderbolt's beams, or SPR models on the viewmodel.
Also, this also means things like player colormap and .scale support on BSP models (which is something I hope to achieve with Makaqu).
- Licensing as much as possible under the BSD license. This would make it simpler to eventually use the code in official console ports of the engine, and I wouldn't mind sharing my own code under it.
- Support for as many platforms as possible, including the ones supported by the original source release.
- Workspace and project files for free development environments such as Code::Blocks. Being able to compile all ports through a single IDE would be a plus.
- Support for as much features present in official ports of Quake as possible. Things like lighting coloration (Quake 64 / Saturn Quake), end1.bin/end2.bin textmode messages (DOS Quake), mirrors (GLQuake), and so on.
Support for the exclusive file formats in those ports would be a plus, so we could do things like use the exclusive maps/textures from Saturn Quake directly from its CD, or listen to the Quake 64 soundtrack directly from its ROM file.
All things considered, I care more about fixing and unifying Quake than about bringing it to a "next level". I want anyone who first learned about the game through any of its official ports to feel at home when playing it, without missing anything. _________________ Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Mon Jul 19, 2010 7:09 pm Post subject: |
|
|
uhh, mk, that's quite a way away from the 90/10 thing... its more like 10/90 _________________ What's a signature? |
|
Back to top |
|
 |
mk

Joined: 04 Jul 2008 Posts: 94
|
Posted: Mon Jul 19, 2010 7:22 pm Post subject: |
|
|
I know.
However, I feel that any standards should really try to make things uniform. It's a lot easier to implement new features after achieving that, since when making things uniform we can also make them more abstract - including the documentation, which can be a lot easier to understand and write when there's no need to explain things like specific filetype-dependent behavior. _________________ Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Mon Jul 19, 2010 11:26 pm Post subject: |
|
|
I'd suggest picking an easier baseline than that. Software Quake is the obvious one; it's the original version of Quake and it's how the original game was designed and intended to be (in as much as a game like Quake could have been designed and intended to be anything!)
So step 1 is to get all engines up to the same baseline level of functionality, which is that offered by software Quake. Individual engines should be free to offer enhancements to that as the authors see fit (otherwise they'd all be the same and there would be no reason for more than one to exist!), but they should all be able to do what software Quake does.
Once everythings on a common baseline it makes sense to talk about moving forward.  _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Tue Jul 20, 2010 2:04 am Post subject: |
|
|
What I am suggesting is that we start doing something, instead of continuing to talk.
mh, how would you express "do everything software Quake does" as part of a standard?
tbh, I think it's pretty irrelevant what the renderer is, or what the platform is, or if overbright lighting or transparent water is supported - I was under the assumption that QSB is about guaranteeing a certain overall capacity to mappers and modders, so those can simply say "my map/mod requires a QSB 1 compliant engine".
Let's not go back to the start of this whole discussion, let's run with what Urre already collected. I'm trying to do something instead of talking about what 111.000 things should be supported by something in principle.
Discussion is fine but let's not forget actually doing stuff - I proposed a later QSB 2 for a reason. QSB1 should be totally baseline, already existing stuff.
About the protocol, I really think large map support and smooth angles should be in QSB 1. But we can perhaps leave it to the engines how they want to support it, and defer a QSB protocol to version 2 or even after version 2.
About 28.8k modems, it's 2010 damn it. Other games laugh at this.
Multiplayer can continue to use protocol 15, unless it's a new mod like RMQ or something that simply requires the heavier stuff. I'd also wager that most multiplayer mods don't need phat map capacity etc. _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Tue Jul 20, 2010 3:06 am Post subject: |
|
|
I would assume the common denominator for a standards base would be to examine what is required to run on today's platforms. Original Quake doesnt run out of the box on the majority of computers today. So, we need to at least ensure that engineXYZ will work on today's budget pc. In combination with system requirements, we should also address requirements of popular mods, yet not to exceed the baseline platform.
Quake 1.09 was QSB 1.0 IMHO. What of 1.09 doesnt work now a days, that needs to be addressed to mod Quake tomorrow. |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Jul 20, 2010 6:54 am Post subject: |
|
|
mk wrote: | I know.
However, I feel that any standards should really try to make things uniform. It's a lot easier to implement new features after achieving that, since when making things uniform we can also make them more abstract - including the documentation, which can be a lot easier to understand and write when there's no need to explain things like specific filetype-dependent behavior. |
I think the coolest thing about engine coding is all the different perspectives and how they influence things.
Most people pursue their own ideas and then someone hits a great idea every once in a while and suddenly a few others follow suit or get similar interests/demands.
Big maps, alpha entity, better map compilers, rotation, software render with more traditionally GL engine features, CSQC, etc. etc.
goldenboy wrote: | What I am suggesting is that we start doing something, instead of continuing to talk. |
Perhaps in many ways, Remake Quake will be defining QSB 2.0
Engines that can run it, engines that can't.
@goldenboy
p.s. One thing I like is how someone originally single player oriented and embedded in the mapping community culture, after just a bit of server experience, can see all the things I've thought is absurd about closed source + servers and/or fatal design flaws in closed source mods from a multiplayer perspective.
[Travail, for instance, if a coop player gets a key and dies ... no more key on map -- forever gone. The End. You can't run that on a public server. Regardless of the brilliance of craftmanship of the episode release, the closed source status for example prohibits a 5 minute fix and recompile. FOQ ran that on a server this year, everyone wanted to play Travail online ... a shame.
Likewise, you've seen the importance of vote-map. Quoth can never be run on a server --- some of the maps exits link to some map that doesn't exist. Listing one reason among several, like how can users select a map to play? The ultimate single player achievement? I think not. Even progs 1.06 can be recompiled to be made competent for a server since the source is open. And it reflects a lack of interest or wisdom in the concept that Quake due to the open source engine/tools/qc status will be virtually immortal.
This type of problem isn't just "NetQuake" .. ZQuake can play Travail for sure. Maybe FTE can as well.] _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Jul 20, 2010 7:23 am Post subject: |
|
|
mk wrote: | - Support for as many platforms as possible, including the ones supported by the original source release. |
I'd really like to be able to use essentially the same engine on every platform with almost no difference between hardware and software.
I would also like the engine to be VASTLY compatible with different hardware and the code almost identical in all platforms and renderers. FTEQW is quite an awesome example of the latter for sure (the rendering thing, is cool.]
DarkPlaces, on the other hand, is very neat how it handles multiple operating system platforms.
I personally think that the code should be readable by normal people. DarkPlaces code except for the early days is quite hard to understand in some places. And in other places, it is simply an ingenious learning tool. _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2004 phpBB Group
|