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

Quake Standards Base discussion Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next

| Inside3d Forums Forum Index -> General Discussion

View previous topic :: View next topic
Author | Message
--- | ---
Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Jul 20, 2010 7:39 am Post subject: |

/And triple post ... The Value of the Eye of The Hurricane Some easily persuadable people right now would look around at the decreased level of activity at Func, QuakeOne, qw.nu and think such a thing is a permanent trend. In reality, it is far easier to rewrite the rules when activity is low.
When activity is low, there is little to no resistance to change. No one arguing against ideas and experimentation. No static from loud mouths.
It is calm and a time of peaceful concentration.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Tue Jul 20, 2010 10:56 am Post subject: |

Baker wrote:
It is calm and a time of peaceful concentration.

Om, om, om.
_________________
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:00 pm Post subject: |

I actually come from a Linux / open source background. I wasn't really fundamentally based in the mapping culture, but I love singleplayer games like the Tomb Raider series and Doom 3. Our source is no secret. It's no magic, just QC and migraines...
So you guys are saying that things like (cross)platform support should be part of QSB? Well, which platforms - Win/Lin/Mac? IMO expecting normal engines to run on the PSP is outside the focus of this thing. So PC?
Open source is secured by the GPL anyway, so that's outside of QSB as well.
_________________
ReMakeQuake
The Realm of Blog Magic

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Tue Jul 20, 2010 2:29 pm Post subject: |

DOS is a platform too. Setting up a DJGPP environment isn't that hard, so don't zap the dos support files out of laziness. It's protected mode, it shouldn't be that hard to maintain the DOS version at all. _________________

Back to top |

mk Joined: 04 Jul 2008 Posts: 94 |

Posted: Tue Jul 20, 2010 2:30 pm Post subject: |

goldenboy wrote:
IMO expecting normal engines to run on the PSP is outside the focus of this thing.

Agreed. However, defining abstraction layers for integrating their specific features into the engine would help a lot.
Things like controller vibration, multiple memory cards, savegame icons, and so on. With well-defined entry points in the code, port authors can just plug their platform-specific code in.
_________________
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: Tue Jul 20, 2010 2:55 pm Post subject: |

standards are a sort of open contract. 'my code will do X when it sees Y' enforcing specific IDEs, that it must support all platforms, etc, is just futile. That is a contract between an engine and a user. It is not something that affects modders nor coders of other engines nor users of other engines.
Any actual standards here should concern actual run-time interactions between engines and other engines, between engines and mods, between engines and content packages, between maps and mods, between maps and engines.
Sorry, but anything else is idealistic pigswill that will only come true some time after the next iceage hits hell.
QSB shouldn't exclude platforms by saying 'renderer must use only d3d' (as an example), but saying it must also support d3d is utterly futile.
When it comes down to it, the user's choice of engine is the _user's_ choice. If their favourite engine doesn't work in dos then that's their problem, not the problem of the mod that would otherwise run just fine if their engine in question supported software rendering and dos.
The whole point of QSB standards is so that the user can choose a different engine which does support dos, rather than having to hack a dos engine to change the path it loads its textures from.
(leileilol, substitute 'dos' for 'windows', its just an example)
_________________
What's a signature?

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Tue Jul 20, 2010 3:00 pm Post subject: |

Cross-platform is an interesting thing. DirectQ doesn't bother itself with being cross-platform, and is a much much better Win32 Quake engine that it ever could have been as a result. Aside from just D3D (which was not a trivial undertaking, caused plenty of pain and suffering along the way, but was more than worth it in the end) the code uses the Windows API very extensively, and also uses API calls for which there is just no equivalent in Linux or the CRT.
Porting the D3D stuff to OpenGL would be easy enough, the renderer is structured in a manner that the platform-specific code is actually quite minimal. Porting the other stuff (in particular the memory manager) to a cross-platform environment would be hell.
I wouldn't enforce cross-platform as a requirement. This should be up to the individual engine coder, and the requirements of the work they are doing. There will always be enough engine developers who care sufficiently about being cross-platform that it is going to happen anyway, and doesn't need to be enforced.
Edit: oh yeah, and what Spike said.
QSB needs to be about what engines can do. Specifics and implementation details about how they do it shouldn't really be in scope.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

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

Posted: Tue Jul 20, 2010 3:12 pm Post subject: |

I think we are, again, missing the entire point of having something called "Quake Standard Base". Time to give a step back and look at the problem again: problem: there are a lot of engines, implementing a considerable number of features each one, and among all those features there are a common subset that behaves differently among every implementation, forcing modders and mappers to create content with one or two engines in mind at max. Worse, with the recent port of the Quake engine to other platforms (PSP, Flash, etc) the common denominator among all implementations is reduced due hardware constraints.
solution: let's create a standard (already named Quake Standard Base) grouping the most common features among all current engine implementations, and let's define a minimal contract to be obeyed by the engine programmers.
addendum: AND, regarding the myriad of platforms the Quake engine now reaches, I suggest to subdivide the QSB specification in "desktop" and "mobile" categories, so we can treat the mobile constraints separately, without artificially reducing the scope on the desktop world. I believe this is an acceptable trade-off.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

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

Posted: Tue Jul 20, 2010 3:19 pm Post subject: |

mh wrote:
QSB needs to be about what engines can do. Specifics and implementation details about how they do it shouldn't really be in scope.

Lots of engines support fog in different ways. What looks good in one looks crap in other, spoiling the modders/mappers efforts.
Lots of engines support external textures, each one using their own folder naming convention, again trashing the modders/mappers work.
And don't even get me started on CSQC...
QSB needs to be not only about what is supported, but also how.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Tue Jul 20, 2010 3:30 pm Post subject: |

frag.machine wrote:

mh wrote:
QSB needs to be about what engines can do. Specifics and implementation details about how they do it shouldn't really be in scope.

Lots of engines support fog in different ways. What looks good in one looks crap in other, spoiling the modders/mappers efforts.
Lots of engines support external textures, each one using their own folder naming convention, again trashing the modders/mappers work.
And don't even get me started on CSQC...
QSB needs to be not only about what is supported, but also how.

I think we're actually coming at the same thing but from different angles. I would see a standard like "load external textures from a directory called 'textures' and support at a minimum TGA, PNG, JPG and PCX" as being part of the "what", but "you must use libpng to load PNG files" as being part of the "how" (unless of course you use it as a DLL, in which case the version of the DLL used definitely belongs in QSB).
Mandating that a developer should always use libpng, SDL_image, ILU, or whatever for image loading is an implementation detail. It doesn't form part of the contract, which is that the end result is presented in a consistent and predictable manner to the user, and that the same content that works in engine A should also work in engine B.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

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

Posted: Tue Jul 20, 2010 4:11 pm Post subject: |

My idea of QSB is more a "black box" approach: as long you deliver what is expected - exactly in the way is expected - I couldn't care less about HOW you did it. So, as long your engine loads the external textures from the expected path and they look right and aren't flipped or have wrong colors or artifacts, I don't give a flying damn if you're using libpng or DeVIL or some obscure Windows API or you wrote a PNG loader from scratch in x86 assembly to do the job.
That said, suggesting paths to beginners such "you can use an external lib such libpng to load the image" is nice. But this must be a suggestions, not an imposition.
And now that we all agree about this point, CAN WE PLEASE STOP TALKING AND DO SOMETHING CONCRETE ABOUT THIS ?
@goldenboy: I think your feature list is a really nice and reasonable start point, so do you think you could create one or two small maps so coders can have a reference to "calibrate" their engines ?
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Tue Jul 20, 2010 4:24 pm Post subject: |

i think qsb should be a engine that uses md2 (as md2 is superior like Quake2 is superior), tons of particles, tgas in the "TARGASFORMAPS/" folder inside "base2" and connects to my quake servers with special quake network protocol made fo rit only with a launcher with american mcgee alice's chesire cat pasted all over because i think that is cool also it must only run on the nvidia cards because like the qsb i am proposing this is the way it's meant to be played
THE WRITTEN ABOVE IS EVERYTHING QSB ISN'T but it pretty much summarizes all the offtopicness here
_________________

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Tue Jul 20, 2010 4:45 pm Post subject: |

its imho more important to say that it looks in textures/$imagename.$ext to find its replacement images than it is to say that it must support any specific format, although both are useful. a) phat map support -bsp limits, more ents, static ents, signon size, avoiding packet overflows.
b) checkextensions and common map-related extensions
-tracebox, replacement texture naming, aware of .lit files, aware of qsg_fog, aware of some skybox cvar/field (not specifically support, but will load them from the correct path if they are supported, mod must be able to stuffcmd or whatever without errors appearing to the user).
c) a chosen few non-map related extensions, like FRIK_FILE (QSB 2 would focus on more extensions)
-string manipulation from frik_file, sincossqrt, 'set' command, multipletempstrings.
d) Protocol
-specify actual protocol separately. clients must be able to support protocol 15 if they connect to a server/demo that uses it. Must be able to support big maps which may be cvar-set to enable, exact protocol not specified. Must be aware of protocol version ids used by other engines (no incompatible duplicates).
e) bug fixes, gameplay fixes, and 44100 kHz sound support.
-oriented sprites. functioning skingroups/framegroups
Any objections? Anything I overlooked? Anything that is vital, versatile and simple?
_________________
What's a signature?

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Jul 20, 2010 7:31 pm Post subject: |

Really, one thing I would think would be important is not only a feature but the lack of one. Every engine should use the DarkPlaces naming convention and folders for the replacement textures. Q1 model textures go in (gamedir)\progs Q1 maps textures go in (gamedir)\textures or (gamedir)\textures\(mapname)
And wherever sprite textures go. If replacement textures for sprites even exist ... I'm sure they do.
I get tired of "I want to use DarkPlaces textures in Qrack" or how do I use the QRP model textures in DarkPlaces. And so forth.
I think non-support of the non-DarkPlaces way to do replacement textures for Q1 models, Q1 bsps and Q1 sprites is important. There should only be one way and the DarkPlaces way is easily the best. (Some may argue the weirdness of progs containing both .mdl files and textures, but it is actually convenient when reskinning to not have to hunt 8 folders to find them).
[But I'm not sure how DarkPlaces handles 2D replacement graphics for the sbar and such. The "EZQuake" way of dealing with that stuff seems more established ... and I guess if CSQC is actually going to be of this such a thing might matter.]
Where do skybox textures actually go? I've seen 12 places with (gamedir)\gfx\env being the one I assume is the "standard".

mh wrote:
Om, om, om.

_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

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

Posted: Tue Jul 20, 2010 7:45 pm Post subject: |

Baker wrote:

mh wrote:
Om, om, om.

_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

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, 6, 7 Next
Page 6 of 7

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