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

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Fri Jan 01, 2010 9:51 pm Post subject: |
|
|
This map format discussion is great stuff, and warrants its own thread really. This thread is more about existing features, standardized. If the new map format gets standardized and actually implemented into atleast one engine, including it in QSB can be discussed
ceriux wrote: | 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? |
Short answer is yes. _________________ Look out for Twigboy |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Fri Jan 01, 2010 10:28 pm Post subject: |
|
|
Quote: | 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? |
I'd vote yes.
I agree that alpha should be in QSB 1.0. Leave it to the engines then how to implement it.
I also agree that 1.0 should mostly only take existing stuff, and standardize it, and give it a label that mappers and modders can then use as a requirement.
Half-Life .bsp support does exist already though, I don't remember if there is a tutorial or a patch for it, but that could probably be included. Dunno if .lit files should be dropped for that, because most WIP maps/episodes for standard Quake don't use HL format (yet). It's highly unlikely that RMQ for example (almost 40 maps, half of them existing already) would switch to HL .bsp just for colored lights. Haha, funny. Not.
Once we actually have successfully created such a standard, and can point to it as an example of this community actually AGREEING on something, more can be added in the future. Such a two-step process would be the wise approach to take, I think.
There need to be more examples of modding features to be included still. _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
Urre

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Fri Jan 01, 2010 11:02 pm Post subject: |
|
|
goldenboy wrote: | There need to be more examples of modding features to be included still. |
Yes, I'm waiting for 'em. I'm currently avoiding listing my own wishlist, for now. _________________ Look out for Twigboy |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Sat Jan 02, 2010 2:55 am Post subject: |
|
|
About external textures, and other external resources, the one thing that should probably be standardized in 1.0 is the location for these, ie standard paths.
So modders don't have to do any guesswork about where to put their sound files, textures, models, skins, conbacks and so forth.
Should resources like texture packs be loaded in a hierarchical order to avoid resource conflicts (alphabetical order or similar)?
What about file formats? _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
Downsider

Joined: 16 Sep 2008 Posts: 478
|
Posted: Sat Jan 02, 2010 5:01 am Post subject: |
|
|
goldenboy wrote: | What about file formats? |
I'd say TGA and PCX for textures; they're widely supported by image editing programs and would definitely allow for the fastest development pipeline. |
|
Back to top |
|
 |
Chip

Joined: 21 Jan 2009 Posts: 314 Location: Romania
|
Posted: Sat Jan 02, 2010 11:47 am Post subject: |
|
|
Downsider wrote: | goldenboy wrote: | What about file formats? |
I'd say TGA and PCX for textures; they're widely supported by image editing programs and would definitely allow for the fastest development pipeline. |
I'd say to leave the option open, as not everyone can handle PCXs and TGA could be replaced by PNG, or JPG if there's no alpha involved. TGA could get too big a filesize. _________________ My Projects: Quake 1 Mods | OpenQuartz 2 | ChipQuake |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 910
|
Posted: Sat Jan 02, 2010 3:28 pm Post subject: |
|
|
goldenboy wrote: | There need to be more examples of modding features to be included still. |
Agreed, and I think this brings us back to LordHavoc's point. Modders desperately need to get involved and shout about the modding features they want included; it's not sufficient to just say "give me more vague kinds of modding features that aren't really defined" and then complain and go back to GLQuake standards when the end result isn't what they actually want (this has happened in the past).
What I'd like to see is some strong modders who have recently been active talking about the types of things that they found annoying or obstructing in their recent work. What things in the engine did they have to construct workarounds for? If it was a completyely open setup with no restrictions and the sky was the limit (forget that it's even Quake), what kind of crazy-assed things would they like to be able to do?
The true strength of the Quake community is the modders, and - much as engines have their place - an engine is just an enabling tool (it's also something cool to play the game on, but that's outside the scope of this discussion). So how would modders like to be enabled by an engine?
Or (devils advocate question here) do modders even want this? Are they perfectly happy with GLQuake standards? Could they care less if any of this happened at all? _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Last edited by mh on Sat Jan 02, 2010 3:33 pm; edited 1 time in total |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Sat Jan 02, 2010 3:31 pm Post subject: |
|
|
Okay, here goes my own wish list along with some considerations and details, without any particular order:
- network protocol 666
.nothing against DP7 protocol or any other, it's just an option. Engines supporting
QSB 1.0 should AT LEAST support it, but would be free to implement additional protocols
- raised engine limits. I am assuming a list based in FitzQuake 0.85 and my current engine incarnation:
Code: |
MAX_HANDLES 10 100
MINIMUM_WIN_MEMORY 0x01000000 (16Mb) 0x02000000 (32Mb)
MAXIMUM_WIN_MEMORY 0x04000000 (64Mb) 0x08000000 (128Mb)
CON_TEXTSIZE 16384 262144
MAX_FARCLIP 4096 16384
MAX_EDICTS 600 8192 (*)
NET_MAXMESSAGE 8192 65536 (****)
MAX_STATIC_ENTITIES 128 1024
MAX_MAP_LEAFS 8192 32768 (**)
MAX_LIGHTMAPS 64 256
NUMSTACKSURFACES 800 8192
NUMSTACKEDGES 2400 8192
MAX_VISEDICTS 256 MAX_EDICTS
MAX_DATAGRAM 1024 32768
MAX_MSGLEN 8000 65536 (****)
MAX_STACK_DEPTH 32 256
MAX_EFRAGS 640 2048
MAX_CHANNELS 128 512
MAX_DYNAMIC_CHANNELS 8 128
MAX_MAP_CLIPNODES 32767 65535 (**)
MAX_GLTEXTURES 1024 2048 (***)
MAX_TEMP_ENTITIES 64 1024
DYNAMIC_SIZE 49152 262144
MAX_BMODEL_VERTS 500 1000
MAX_BMODEL_EDGES 1000 3000
MAXALIASVERTS 1024(GL),2000(SW) 4096
MAXALIASTRIS 2048 4096
MAX_LBM_HEIGHT 480 1024
ABSOLUTE_MIN_PARTICLES 512 1024
MAX_PARTICLES 2048 16384
MAX_MODELS 256 2048 (*)
MAX_SOUNDS 256 2048 (*)
MARKSURFACES 32767 65535 (**)
FACES 32767 65535 (**)
NODES 32767 65535 (**)
MAX_BEAMS 24 32
MAX_DLIGHTS 32 64
(*) = requires new network protocol
(**) = as LordHavoc pointed out, should be implemented in a non-hacky way (replacing short values with 32-bit ints)
(***) = OpenGL specific
(****) = See FitzQuake README.TXT about multiplayer games sticking to 1400 bytes due network limitations
|
- model animation and interpolation
.should use standard cvar names to toggle on/off
- per-entity alpha support for BSP and alias models:
.controlled via QuakeC or map entity lump(.alpha field);
.full range in OpenGL/DirectX engines (from 100% to 0%);
.incremental in software renderers (100%, 66%, 33%, 0% via single lookup table as used in Makaqu and Quake2)
- per-entity scale (like in TomazQuake)
- EF_ADDITIVE
- EF_FULLBRIGHT
- BSP bound box rotation fix
.for legacy compatibility, should be toggled by cvar and off by default
- fullbrights for BSP and alias models
- colored lights using .LIT files
.in future versions the standard could support an embedded .LIT lump in the BSP itself, but for 1.0 I'd say let it be an external file
- fog
.at least in OpenGL engines, should be implement to always behave in the same way
.should use a standard set of control cvars (on/off, color, intensity, start, end, etc)
.future standard versions could define ways to implement volumetric fog, too
- ability to change video resolution on-the-fly
.unlimited size list of available video modes is a must!
.vsync toggle by cvar!
- external texture loading in PCX or TGA formats as defacto standards
.image search order can be defined in standard: first try to load TGA, then PCX if failed, then WAD if failed too
.texture loading paths: don't care, as long it's part of the standard
- alternative .zip pack reading support besides the .pak format (so using lots of TGA's wouldn't hurt disk space usage)
- skyboxes
.many engines fixes the sky textures to 128x128 or 256x256. Should it be fixed at all ?
- ARB multitexture support for OpenGL engines, ditching completely legacy stuff like SGIS multitexture and 8-bit modes.
There's a practical reason for this: such hardware is really hard to find nowadays, so you cannot expect a developer
supporting features that he cannot test because he has no access to the required video card. I say out with this.
- gamma support
- fixed chasecam
- fixed z-fight in plats and doors
- basic CSQC support
.This deserves a separated message later. For 1.0, having something like Spike's reference implementation over vanilla Quake should be enough
- FRIK_FILE
- MD2 alias support
.I know, MD3 is much better. But there's no easy way to implement it (at least, no complete tutorials), and it would be harder yet in software mode. MD3 support is a good candidate to future versions of QSB
- DP_CHECKEXTENSION shold be a must
- a lot of cool features from DarkPlaces, like MOVETYPE_FOLLOW, and a bunch of additional useful built-ins. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
avirox
Joined: 16 Aug 2006 Posts: 109
|
Posted: Sat Jan 02, 2010 10:49 pm Post subject: |
|
|
And now that I've uploaded a tutorial for it, how about rotating brush support as well? At least in its basic form, so mod-makers don't need to rely on the hackish hipnotic ents. |
|
Back to top |
|
 |
ceriux

Joined: 06 Sep 2008 Posts: 969 Location: Florida, USA
|
|
Back to top |
|
 |
avirox
Joined: 16 Aug 2006 Posts: 109
|
Posted: Sun Jan 03, 2010 12:33 am Post subject: |
|
|
ceriux: works for both, tbh. Just that tutorial in particular was aimed at QW support. |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Sun Jan 03, 2010 2:05 am Post subject: |
|
|
frag.machine wrote: | Okay, here goes my own wish list along with some considerations and details, without any particular order:
.
.
. |
This is a very good and thought out list. I need to play with the Makaqu engine to see the software renderer support for transparency; I already noticed the interpolation.
Add: I still hate external textures because no sane person is going to make 2 textures for a map when making it and external texture sets are nice in theory, but in practice only make a mess. But I understand the "sentimental" value of them and obviously they are a standard, but mix up some pk3 files and some jpg vs. tga textures in different gamedirs and watch the mess that happens ... |
|
Back to top |
|
 |
c0burn
Joined: 05 Nov 2004 Posts: 158 Location: Liverpool, England
|
Posted: Sun Jan 03, 2010 3:29 am Post subject: |
|
|
This is an excellent thread Urre - and the exact issue I ranted on IRC about a while back - I was going to post something similar myself but I'm a lazy bastard, so here we go now.
Personally, I think the community needs to come together and work together, on a new engine and a new set of tools to go along with it.
Mapping and the BSP format
As far as I'm concerned, Q1BSP mapping tools were perfected a long time ago and don't need any focus whatsoever. There are excellent mapping tools, compilers, vis and lighting tools already.
Modelling and Textures
I always feel iffy using stuff like TGA textures and MD3 models in mods - it's not "pure" and unless you're doing a total conversion stuff always looks out of place anyway, so it's a bit pointless. Just my 2 cents. If you want to use MD3, use Quake3.
Making Q1MDL files reliably is an absolute nightmare and something that needs to be addressed, in my opinion. Personally I generally make mods that fit into the Q1 universe so the limits of the MDL format do not generally bother me - just look at the excellent work in mods like Painkeep and Perquake. But of course, this isn't how everyone is using the Quake1 engine.
Along these lines, I would suggest if we're going to do a new engine standard we should also focus on adding, improving, extending and basically perfecting something like FrikaC's unreleased quake data formats editor/FIMG.
That is, an all in one "misc" formats editor
- MDL
- PAK
- LMP
- SPR
- whatever else i'm forgetting
I'm sure we've all wanted to stab ourselves after using Qme/exporting stuff to Q1MDL format/etc/etc. This is a must to me.
Network protocols
Why oh why oh why do people keep basing engines on NQ? Yes, testing mods in a single executable in lovely and convenient but in the long run, some nice multiplayer mods would be great. There's no reason we can't have QW server and client in a single executable (FTE and loads of others do it).
Some sort of modern network protocol with interpolation and prediction is a must, or I simply wouldn't want to mod for it.
QuakeC
An IDE would be nice. I'm sure we all have our own homebrew solutions. There have been IDE's in the past I vaguely recall, but they were all shite. Hell, even picking a free multiplatform editor that supports external syntax definitions would be great.
CSQC
It's nice, but it's a big job, and imo in its current form is an undocumented mess that doesn't even have nice compatibility for csprogs.dat between Darkplaces and FTE. This kinda rubbish needs knocking on the head if we want to get anywhere.
Personally, although CSQC is nice, I always thought adding a few builtins to draw a hud in SSQC would have suited 99% of my needs. I couldn't care less about making smoke client side and stuff like that - but that's just me.
Misc stuff
Pruning of all unused/gameplay changing/cheaty client side cvars - or forcing their values via QuakeC - I don't want to see any stupid QW crap with white walls and solid colour players.
Darkplaces menu.dat is nice but I always thought an XML file with things like "slider" "button" definitions that was parsed by the engine would have led to less headaches. On this topic, if you're going to add features, add a fucking menu option with appropriate options. And can we make mouse support standard in the menu? It's 2009.
This post is probably a mess but I got most of it out, I guess. |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Sun Jan 03, 2010 6:02 am Post subject: |
|
|
Joystick support for remote controlled robots. |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Sun Jan 03, 2010 6:09 am Post subject: |
|
|
Each time I read this topic, I think 'well what has this got to do with engine standards regarding mod compatibility'.
If you want to argue about QuakeC IDEs for instance, create a new thread instead.
Any engine standard shouldn't state that there must be dedicated servers, dedicated clients, or that there cannot be either.
It should not dictate the network protocol other than that a given extended protocol must be supported for demo compatibility only. A non-networked (flash?) engine needn't have a network protocol at all.
It would be nice if all engines could network together. In fact, any standard should specify builtins and fields, not SVCs and TEs.
csqc standardisation? would be nice, but it needs to mature still. don't specify that it need be supported yet. There's a doc that specifies the behaviour of each field and builtin on fte's svn. As far as I'm aware, FTE matches it exactly.
But more interestingly, would you prefer q2-esque hud-script support?
a mouse controlled menu has nothing to do with mod compatibility unless the mod has direct control over the menu - in which case you're asking for something else or far more.
Stating that an engine must have ARB multitexture instead of legacy multitexture is ironic - ARB multitexture is legacy since it is core. If you really want to get rid of legacy features, you should be using OpenGL multitexture... But that's me being pedantic.
Any standard should not say the method used to achieve a goal, only how the method is used to achieve a desired effect. That is, it should state that you need a .lit file for coloured lighting. Not that the lighting must be done with multitexture. I don't see the standard mentioning requiring Combiners to do fullbrights and detail textures.
changing resolution on the fly is a personal preference thing, and has nothing to do with mods. If a QC mod ever changes my video resolution/vsync/etc, I will not be happy (unless its a menu and the new values are completely under the user's control).
'stupid QW crap' can be done in NQ engines too. Just change your player model's texture to a single colour in the last 32 pixel values in the palette, probably a yellow. Easy, at least if you have an editor. 'cheaty client cvars' just make the process easy for all, not just the people who will use any and all cheats. White walls? really depends upon your choice of retexturing set. Those cvars provide nothing new, they only simplify their use for people who are not accustomed to hacking their entire quake install just to win a couple more games.
Frankly, if you removed those easy settings from the engines that support them, you would find the users switch to a different client that does support them (or just stay with an older version).
Any standard with any chance of adoption should not specify features which may not be supported. Sorry, but if the engine was your engine, why would you need an actual standard for your mod in the first place.
Any standard for mod compatibility should not fully mandate what is supported, nor how it is supported. Only how it is activated or used if it is supported.
Knowing that the engine will use your fog if it is supported is far more useful than knowing it supports fog without knowing how its switched on. Different engines activate fog in different ways. But they must all support activating fog using the same mechanism. Either a worldspawn key or qc+stuffcmd. If so, what's it called, does it scale from 0-1 or 0-255, the ordering, count, and the defaults of the fog's settings.
If the standard says 'must support tga replacement textures' then the standard is useless. If the standard says 'must support version X and mode XYZ tgas with correct interpretation of the bottom-up flag as replacement textures stored with name blah/blah.tga' then the standard becomes a hell of a lot more useful.
It is actually quite hard to put in all the words to fully specify a standard. In all honesty, without an example mod/map that tests each requirement, such a standard will not be widely supported and thus not widely usable. With regards to mapping, Don't forget QW clients in the example mod/map. They've a slightly greater following, in europe, anyway, and you don't really want two standards.
Mneh, you get the idea, and I apologize if anyone takes personal offence, none is intended. But please stay on topic. _________________ What's a signature? |
|
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
|