View previous topic :: View next topic |
Author |
Message |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Wed Dec 30, 2009 11:22 pm Post subject: |
|
|
Yes, it is time for this. Many parts of it are already there, or just about to happen.
Also, at RMQ's headquarters, we could simply close ticket #120 - Engine. _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
Downsider

Joined: 16 Sep 2008 Posts: 478
|
Posted: Thu Dec 31, 2009 12:13 am Post subject: |
|
|
Spirit wrote: | What Downsider is trying to make fun of like a know-it-all 8th grader is probably that you said a "minimum of a maximum" while there could only be one value and that would be the maximum. You probably said minimum because you meant a common maximum of 512 would be a good minimum standard to see among engines. But hey, it is way moar lulz to post backseat remarks instead of simply correcting.
I love you for posting this topic, very good initiative.  |
I was just pointing out something I found amusing.
EDIT:
And no, that's not even it. He was saying "Be more specific with your documentation, guys!", but his example is "Increased maximum to a minimum of 512".. Meaning that the limit could be anywhere above 512.. :/ |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Thu Dec 31, 2009 12:40 am Post subject: |
|
|
OK, let's not further disrupt this thread, please, because this is important. _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Thu Dec 31, 2009 1:06 am Post subject: |
|
|
I suggest the following steps:
1) enlist all cited features in this thread (and any others you think deserves to be candidates);
2) start a vote so people can give notes (say, from 1 to 5, higher notes means most valuable/desirable). It's important that this vote MUST be open to other people from the community (mappers, people that stills playing online, modders, etc), so this adds value to the standard;
3) close the vote and select the N top features;
3.1) N must be wisely defined: not being too small so basic structural changes like bigger engine limits being cut off, neither too big that implementing Quake Standard Basic 1.0 (I like this, sounds cool ) becomes an overwhelming task;
4) write or compile tutorials implementing every selected feature;
4.1) it's highly desirable such tutorials not being limited to chunks of code to cut & paste, but a comprehensive explaining at least in general lines what's going on there (MH's and Baker's tutorials are good examples), so one willing to re-implement feature XPTO in another way will have enough available info to do so;
4.2) tutorials showing how to use such features are essential, too!;
5) spread the new QSB 1.0 spec around all the community;
5.1) however, may be wise to keep this site as the main reference for updates, corrections, etc;
6) profit.  _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Thu Dec 31, 2009 1:11 am Post subject: |
|
|
From a more mapping-centric point of view, some of these seem important:
features that could break the experience if absent.
- alpha (e.g. glass that you need to be able to see through)
- fullbrights (e.g. glowing button in a dark area)
features that are pretty harmless if absent
- colored lightmaps
- skybox
- fog
relatively hard limits that break the experience (or crash the engine) if exceeded:
- faces
- marksurfaces
- leafs
- nodes
- visleafs
- lightmaps
- model precaches
- sound precaches
- edicts
- static entities
- clipnodes
more fuzzy limits that might be hard to define and generally don't break the experience (but could)
- temp ents
- efrags
- beams
- dlights
- packet size
- signon buffer size
- sound channels |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Thu Dec 31, 2009 1:24 am Post subject: |
|
|
metlslime wrote: |
features that are pretty harmless if absent
- colored lightmaps
- skybox
- fog
|
I disagree about colored lights and fog, mostly the last one. For example, one can use red lights to signalize dangerous area in a map, and plain white lights won't work well in this case.
And fog can be used to, say, hide traps (I know, this can be a very cheap mapping trick, but a valid one nonetheless - id resorted to that a lot in Doom 3 ).
EDIT: for spelling correction. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
MDave

Joined: 17 Dec 2007 Posts: 75
|
Posted: Thu Dec 31, 2009 1:27 am Post subject: |
|
|
frag.machine wrote: | metlslime wrote: |
features that are pretty harmless if absent
- colored lightmaps
- skybox
- fog
|
I disagree about colored lights and fog, mostly the last one. For example, one can use red lights to signalize dangerous area in a map, and plain white lights won't work well in this case.
And fog can be used to, say, hide traps (I know, this can be a very cheap mapping trick, but a valid one nonetheless - id resorted to that a lot in Doom 3 ).
EDIT: for spelling correction. |
Did you mean 'agree' in the first sentence?  |
|
Back to top |
|
 |
LordHavoc
Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA
|
Posted: Thu Dec 31, 2009 5:07 am Post subject: |
|
|
I should bring up two mods that kind of set a standard for themselves:
Nehahra - this is a host of hacks but some core elements are good overall (skybox, colored lighting, higher limits, etc).
Quoth - this is also a host of hacks with some good core elements (although the way the q1bsp limits were increased is dubious, the format version should have changed to prevent loading them into engines that are clearly not capable of loading them).
I think the bare minimum set of enhancements desired by level designers would be:
colored lightmaps (.lit) and dlights and optimized dlights (litsupport.zip tutorial)
increase MAX_EDICTS from 600 to 2048
increase NET_MAXMESSAGE from 8192 to 65536 (to prevent getspace errors with lots of static entities)
increase static entity limit from 128 to 512 (for more torches, etc)
skybox
fog
alpha
EF_ADDITIVE flag (can be used for a variety of effects including light beam effects)
EF_FULLBRIGHT flag (often used with EF_ADDITIVE)
fullbrights
full limits of q1bsp unleashed (like arguirre tools allow)
raised model and sound limits (requires extended protocol)
dynamic sound channels (8 is way too few)
beams (8 is too few in some levels)
external texture loading with textures/mapname/blah.tga naming to avoid conflicts with other installed maps, and also _glow texture loading
full lightmap range (0-2x brightness, not clamped like glquake, to avoid the strange gray saturation of level lighting in glquake)
software engines can be exempt to several of these requirements, but I do not recommend software engines at all. |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Thu Dec 31, 2009 5:47 am Post subject: |
|
|
Packet overflow fix is a must. There are testmaps around for this (the box full of grunts comes to mind - gib rain).
I would rate skybox support, and probably fog, as important. Support for larger skybox images than 256x256 or even 512x512 would also be nice. Mappers carefully choose the sky for their level, and some maps are designed with fog in mind. Some ugly pixelated default sky does break the experience for me, although technically skyboxes are not strictly required. It would be pretty ridiculous to not have skybox support as the standard.
Colored lighting I would see as the least important of those three, but it would be nice, yeah.
I believe a list of map-related features is comparatively easy to come up with, as metlslime and LordHavoc have demonstrated.  _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
Urre

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Thu Dec 31, 2009 11:25 am Post subject: |
|
|
LH pointed out something important, are SW engines of any priority? _________________ Look out for Twigboy |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Thu Dec 31, 2009 3:03 pm Post subject: |
|
|
metlslime wrote: | From a more mapping-centric point of view, some of these seem important:
features that could break the experience if absent.
- alpha (e.g. glass that you need to be able to see through)
- fullbrights (e.g. glowing button in a dark area)
features that are pretty harmless if absent
- colored lightmaps
- skybox
- fog
relatively hard limits that break the experience (or crash the engine) if exceeded:
- faces
- marksurfaces
- leafs
- nodes
- visleafs
- lightmaps
- model precaches
- sound precaches
- edicts
- static entities
- clipnodes
more fuzzy limits that might be hard to define and generally don't break the experience (but could)
- temp ents
- efrags
- beams
- dlights
- packet size
- signon buffer size
- sound channels |
The max number of static entities is dependent on the max number of efrags, so if you increase static entities you'll have to increase efrags. Otherwise a good list and nice to see them all in the one place. _________________ 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: Thu Dec 31, 2009 4:25 pm Post subject: |
|
|
Well, there are software users in the NQ and QW communities. Are you going to tell them to "fuck off"? Remember not all corners of the planet have cheap modern hardware available. Not all individuals might. There might be good reasons for some to use software.
I do think that we need the software renderer around and that it needs to be maintained for use as a reference. Software was how Quake was supposed to look.
On the other hand, it would put quite some burden on engines like Fitzquake, Darkplaces and DirectQ. We can't really dictate for engine coders to re-include software renderers, and including software renderers as optional would be half-assed.
Hacking the map related limits in a software engine is no problem. Neither is including CSQC or basic Nehahra support. Alpha is a problem.
Maybe the new standard doesn't even need to concern itself with renderers. You could argue that it is the individual engines' problem how they support the standard. This would include the question of which renderers they want to provide.
FTE has a software renderer that works fine. It probably supports 90% of those features already. 90% isn't bad.
In the end, I would say that the renderer question is out of the scope of such a new standard, and the engines' problem, not the standard's.
There was a famous saying in the German army: "Do X. How you do that is up to you". It worked. _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Thu Dec 31, 2009 4:47 pm Post subject: |
|
|
goldenboy wrote: | I do think that we need the software renderer around and that it needs to be maintained for use as a reference. Software was how Quake was supposed to look. |
Well said. If for no other reason we definitely need the software renderer for that.
goldenboy wrote: | On the other hand, it would put quite some burden on engines like Fitzquake, Darkplaces and DirectQ. We can't really dictate for engine coders to re-include software renderers, and including software renderers as optional would be half-assed. |
That's an interesting point. I obviously can't speak for the others, but the whole reason for DirectQ to exist in the first place was for to provide a hardware accelerated alternative for people (especially me ) who had machines that couldn't run GLQuake (or other OpenGL engines). Obviously it's grown quite beyond that initial scope, and these days provision of a software (or even an OpenGL) renderer as an alternative to the D3D renderer is something that's not impossible to consider. Not that it's particular high on the "to do" list either, but all the same, I should probably at least give thought to architecting my setup in a way that would make inclusion of a software renderer somewhat less painful. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
FrikaC Site Admin

Joined: 08 Oct 2004 Posts: 947
|
Posted: Thu Dec 31, 2009 5:23 pm Post subject: |
|
|
I should note that a lot of the ports to other platforms are based on the software renderer. GP32, etc spring to mind. It'd be nice if some of those engines were able to participate in these standards. |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Thu Dec 31, 2009 5:35 pm Post subject: |
|
|
If alpha support is included in the standard, software renderers are excluded. As far as I understand it.
That warrants discussion about alpha support. _________________ ReMakeQuake
The Realm of Blog Magic |
|
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
|