Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Engine standards for mod compatibility Goto page Previous 1, 2, 3, 4, 5 ... 14, 15, 16 Next

| Inside3d Forums Forum Index -> General Discussion

View previous topic :: View next topic
Author | Message
--- | ---
MDave Joined: 17 Dec 2007 Posts: 75 |

Posted: Fri Jan 01, 2010 1:40 am Post subject: |

Because the topic covers such a wide area of the engine and game logic and art assets, perhaps it would be more productive to make several distinctive topics that cover each specific area that can be standardised? People might not like what I'm about to say, but taking the engine into the same steps as it's sequels in terms of technology makes a whole lot of sense to me.

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Fri Jan 01, 2010 5:35 am Post subject: |

It seems that people have misinterpreted my list, and wandered off on their own tangents. The point of this discussion is proposals for what FEATURES are NEEDED by a MOD or MAP, nothing else is relevant. Furthermore that "bare minimum for maps" list I made was NOT a set of requirements, it was a set of recommendations - it is still up to the individual engine authors to interpret the standard in their context, for example software engines skipping external textures.
What is intended is insisting on external textures support if it is not unreasonable to do so in the context of an engine - supporting the embedded textures is a given in all engines.
The point of such a list is to start a proposal for a map limits capability that engines can advertise if they support all critical portions of the capability (such as limits) and attempt to support the other parts as best they can.
For example, support for alpha does not require blending in a software engine, but a GL or D3D engine SHOULD support it.
Ultimately the goal is that a mod or map can state one required capability and the user can choose any engine that supports that capability, it may not implement it fully or in the same way, but it WILL work on some level, and almost ensure a playable experience.
So when I said colored lighting I did not infer that software engines had to implement this feature, just that engines that can implement it reasonably, must do so, lest the experience be degraded unnecessarily, similarly external textures SHOULD be supported if possible but are NOT strictly required.
External textures and colored lighting, alpha, additive blend, fullbright, fog, skybox and other similar features are elements of the intended vision of the level designer or modder, to deny any one for personal reasons would be a disservice to the designers involved, to reject a feature for deep technical reasons is perfectly understandable - but the rest should still be implemented.
DarkPlaces has been developed with "showing the art as intended" as a core goal, many features flow from this basic theory (such as the 2x lightmap brightness range to match software), while others are enabling new forms of art (external textures, skybox, colored lighting, etc).
Any level designer would want an engine to portray the level as intended, the same is true for modders, but all of these considerations are secondary to the core problem ,"Does it run?"
When the level designer can only be guaranteed that "designed for stock Quake" will run properly, the level designer can not use features that break on stock Quake, their vision must be limited by stock Quake, lest it be portrayed incorrectly on the majority of engines.
If on the other hand they can say "requires Q1SP_EYECANDY1 capability" then their vision is only limited by what Q1SP_EYECANDY1 represents, they can design FOR alpha, colored lighting, external high quality textures, skybox, and higher limits.
Each capability sets a higher bar for what is possible, enabling experiences that are not possible with a lower bar (such as stock Quake).
However a decision on what capability to require, still needs information on the number of users of each engine, if the majority of players are using engines with a given capability, that capability can be a good target.
To cite a direct example, mods like Warpspasm (which uses Quoth) do not run on most engines, because the levels were made with arguirre's map tools and never reduced to meet stock Quake limits, this is okay but it needs to be made clear to users that this mod needs a certain capability to run Warpspasm, not a specific engine but a capability that any engine programmer COULD choose to implement and thus their engine would be added to an official "Warpspasm compatible" list, which is a service to users.
Last edited by LordHavoc on Fri Jan 01, 2010 3:38 pm; edited 1 time in total

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Fri Jan 01, 2010 2:02 pm Post subject: |

MDave wrote:

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?

Hmm... What I understood about metlslime's quote was that colored light and fog weren't that important to gameplay, and I gave some mapping examples where such features can play an important role. Since english is not my first language, I am actually in doubt now if I got it in the right way. Sorry for any confusion.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Fri Jan 01, 2010 2:05 pm Post subject: |

frag.machine wrote:

MDave wrote:

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?

Hmm... What I understood about metlslime's quote was that colored light and fog weren't that important to gameplay, and I gave some mapping examples where such features can play an important role. Since english is not my first language, I am actually in doubt now if I got it in the right way. Sorry for any confusion.

I think disagree is completely correct, metlslime is representing the view that these are "harmless if removed", and you are saying there are legitimate uses that would not be the same without them.
I agree with your view on this, as should be clear in my latest huge post.
There are other details such as the ability for people to cheat and turn off these effects in some way, but that is to their own detriment (much like playing Doom3 without the lighting - it's possible but not a good idea).

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Fri Jan 01, 2010 2:22 pm Post subject: |

Heh, thanks for clarifying LH, I was in real doubt if my english knowledge was failing me. _________________ frag.machine - Q2K4 Project http://fragmachine.quakedev.com/

Back to top |

MDave Joined: 17 Dec 2007 Posts: 75 |

Posted: Fri Jan 01, 2010 3:17 pm Post subject: |

Ah my mistake! I didn't read the first sentence in metlslimes quote in your post, just the shortened down list. Doh

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 478 |

Posted: Fri Jan 01, 2010 3:29 pm Post subject: |

Colored lighting and fog are must-haves, if you ask me. There's literally no reason not to support them whatsoever; easy to implement, thanks to the LIT tutorial, and has no repercussions on mod developers that don't want to use it. It's ideal to set a standard for, I'd say we slap a big "Yay" onto colored lighting and fog and put it on some official list
A feature I would consider adding instead of LIT support is HLBSP support. It's just as easy to implement thanks to Baker, and also as zero repercussions. It's good.

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Fri Jan 01, 2010 3:40 pm Post subject: |

A correction: I meant to say Warpspasm rather than Quoth in my earlier posts, Quoth runs on anything but Warpspasm needs expanded limits (in particular, support for arguirre q1bsp limits) to avoid crashing. Warpspasm makes a good example of what this thread is about, simply because it DID push the limits, rather than confine itself to the Quake limits, and if someone wants to play Warpspasm they must use a suitable engine.

Back to top |

ceriux Joined: 06 Sep 2008 Posts: 969 Location: Florida, USA |

Posted: Fri Jan 01, 2010 6:46 pm Post subject: |

well what about hlbsp? i dont know if its been mentioned yet. but i think at least a basic implementation of it would be good. possibly for future mods? i know that if i had time it would be the only map version id be using. _________________
QuakeDB - Quake ModDB Group

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Fri Jan 01, 2010 6:48 pm Post subject: |

HLBSP has different bounding boxes. It wouldn't be pure Quake gameplay if it were HLBSP. Also, there's no Free map compiling tools that output hlbsp, and no one's done a software engine with hlbsp (that retranslates textures to palette.lmp on load)
_________________

Back to top |

ceriux Joined: 06 Sep 2008 Posts: 969 Location: Florida, USA |

Posted: Fri Jan 01, 2010 6:51 pm Post subject: |

i believe there is. http://nemesis.thewavelength.net/index.php?p=2 http://zhlt.info/download-zhlt.html also i did mention "basic" _________________
QuakeDB - Quake ModDB Group

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Fri Jan 01, 2010 8:29 pm Post subject: |

To re-emphasize a bit: the point is to standardize existing features and put them together into a straightforward package. This:

goldenboy wrote:
Perhaps we should aim for something more realistic and push stuff like a new bsp format back to version 2.0 if there ever is one. I'd rather see something less ambitious get done than something overly ambitious fail again.

And this:

metlslime wrote:
I think the best chance of success would be to create a standard that is at least close to the current implementation of these features in most engines, rather than a re-invention. That way fewer engines have to change, and those that do will have a smaller change to make.

...sums up my mindset when starting this thread pretty well.
Talking about creating new map formats is nice and all, and I totally support it in theory, my dream would be a Quake-engine based engine, which does things "right", ignoring Quake compatibility. But that's not happening, unless I do it myself sometime in the future. It's not like this is the first time discussion about new map formats turn up. Why hasn't anything happened in the past? There could be many theories, but I believe it ends up being because no one can agree on anything. This is why I'm following the above mindset.
On the other hand, I'm having high hopes for the future of Quake Standard Base (woo!), so while it's aiming to find the middleground of things so it's easy for devs to support the standard, there will always exist middleground for all kinds of features!

LordHavoc wrote:
Warpspasm makes a good example of what this thread is about, simply because it DID push the limits, rather than confine itself to the Quake limits, and if someone wants to play Warpspasm they must use a suitable engine.

Saying this, LordHavoc summarized two important points mentioned earlier: this is a mod which needs a capable engine, and instead of listing lots of compatible engines in the readme, they could just say "Requires a Quake Standard Base compatible engine, see this here site for a list of engines", but also the fact that big and cool maps/mods pushing the limits will automaticly set new standards, even if they might not be perfectly thought out, leading to engine devs wanting to support the new features the mod requires. This is a better place to base standards on than anything in a free environment such as the Quake modding scene. It's chaotic, nothing makes sense, everyone does as they please. Try to find some middleground.
Another important thing to realise, and I can't stress this enough, is that the standard won't be respected by modders/mappers if it has optional features. What if some optional feature feels critical to you as a mapper? If the standard lists, say alpha, as optional but recommended, any mapper using alpha will do as previously, list a required engine in the readme, rather than "Quake Standard Base compatible, oh and make sure it has alpha". Then we're back to where we started. We can't have any "bare minimum" stuff.
On the subject of alpha though, I really like what I'm hearing about stippling and lookup tables for 25%, 50% and 75% alpha. Seeing as I know nothing about coding these sorts of things, are these reasonable things to require? It'd be awesome, so alpha could make it into the first version of the standard. This is also a perfect example of what I meant with a feature reaching a minimum in my very first post, which seemed to cause a lot of confusion. The standard could say (details mostly stripped out):

- Support alpha to a minimum by stippling 50%

This means that you can, if you like, support alpha in its full range, but you should at the very least support 50% alpha by stippling, which would kick in when the mapper has specified 25% alpha or more. If that's the minimum, modders and mappers using the standard will know their windows will atleast be see-through in all QSB compatible engines, even if not look great.
I'd really want an opinion on that from mappers and modders, would you be okay with windows having alpha to only some extent on certain engines? Also, an opinion from engine coders, is it a reasonable feature to ask for? I'd vote for yes on the lookup-table variant, and making alpha round off to the nearest, so a window with 80% alpha would be 75% alpha in most software engines.
I'll be starting on a list soon, which can be commented and voted on. This is going to be awesome!
_________________
Look out for Twigboy

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Fri Jan 01, 2010 9:33 pm Post subject: |

leileilol wrote:
HLBSP has different bounding boxes. It wouldn't be pure Quake gameplay if it were HLBSP. Also, there's no Free map compiling tools that output hlbsp, and no one's done a software engine with hlbsp (that retranslates textures to palette.lmp on load)

ceriux wrote:
i believe there is. http://nemesis.thewavelength.net/index.php?p=2 http://zhlt.info/download-zhlt.html also i did mention "basic"

Ceruix, the Half-Life map compile tools and their source code have a strange and complicated license agreement.
Due to this, they can't be defined as "free" because of this.
This is why the 5 or 6 small features that are neat in Half-Life BSP should be implemented in a new version of Q1 BSP to get a "no strings attached" free mapping standard.

Back to top |

ceriux Joined: 06 Sep 2008 Posts: 969 Location: Florida, USA |

Posted: Fri Jan 01, 2010 9:36 pm Post subject: |

that would be awesome to get an updated q1bsp version which was as good if not better than the hlbsp version. but is it possible? also if this was achieved would i still be able to map using worldcraft? _________________ QuakeDB - Quake ModDB Group

Back to top |

SamUK Joined: 17 Dec 2008 Posts: 98 Location: United Kingdom |

Posted: Fri Jan 01, 2010 9:46 pm Post subject: |

Baker wrote:
Ceruix, the Half-Life map compile tools and their source code have a strange and complicated license agreement. Due to this, they can't be defined as "free" because of this. This is why the 5 or 6 small features that are neat in Half-Life BSP should be implemented in a new version of Q1 BSP to get a "no strings attached" free mapping standard.

I completely agree, I think me and you once had a discussion about this.
_________________
Working on Solitude

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> General Discussion | All times are GMT Goto page Previous 1, 2, 3, 4, 5 ... 14, 15, 16 Next
Page 4 of 16

Jump to:

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