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 ... 10, 11, 12 ... 14, 15, 16 Next

| Inside3d Forums Forum Index -> General Discussion

View previous topic :: View next topic
Author | Message
--- | ---
Team Xlink Joined: 25 Jun 2009 Posts: 320 |

Posted: Thu Jan 07, 2010 1:52 am Post subject: |

Well, I am up for the PSP Platform. I will do this platform. _________________

Anonymous wrote:
if it works, it works. if it doesn't, HAHAHA!

Back to top |

Junrall Joined: 21 Sep 2009 Posts: 136 Location: North West Oregon, USA |

Posted: Thu Jan 07, 2010 4:52 am Post subject: |

Hello everyone, I'm fairly new to the forums here, but would like to throw out an idea... After reading through this post my head is swimming with all of the ideas that are zinging around. Would it be a good idea to just start out with a matrix of all the engines listed across the top and then list the features that are common to each engine down the side? This would give a pretty good starting point right out of the gate and would provide a way to see which engine's features are on or off board with standardization.
Then after a bunch of the current features are taken care of add in others that aren't so common to all of the engines.
Visualize - Work with whats there - add the rest.
Ok... thats my two cents

Back to top |

r00k Joined: 13 Nov 2004 Posts: 483 |

Posted: Thu Jan 07, 2010 6:20 pm Post subject: |

That's a good idea, as with anything organization pevails. The darkplaces column will be two pages worth alone.

Back to top |

reckless Joined: 24 Jan 2008 Posts: 390 Location: inside tha debugger |

Posted: Thu Jan 07, 2010 7:39 pm Post subject: |

mh i wrote a helper in the last part of your tutorials in regards to linux memory. i dont mind helping with making the ports if needed.

Back to top |

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

Posted: Thu Jan 07, 2010 7:51 pm Post subject: |

Junrall wrote:
Hello everyone, I'm fairly new to the forums here, but would like to throw out an idea... After reading through this post my head is swimming with all of the ideas that are zinging around. Would it be a good idea to just start out with a matrix of all the engines listed across the top and then list the features that are common to each engine down the side? This would give a pretty good starting point right out of the gate and would provide a way to see which engine's features are on or off board with standardization.
Then after a bunch of the current features are taken care of add in others that aren't so common to all of the engines.
Visualize - Work with whats there - add the rest.
Ok... thats my two cents

Excellent idea, and kind of an extension of the engine limits tables that already exist here http://quakery.quakedev.com/qwiki/index.php/Engine_Limits
The table will be massive, but it's the way to go.
However I suspect we will see that there are only 5 or so engines that have ANY modding features at all, and the rest will be nearly blank columns, this is the sad state of Quake modding today, and exactly why we need a standard to raise the bar.

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Thu Jan 07, 2010 9:30 pm Post subject: |

DarkPlaces and FTEQW are the only engines with any actual modding features above baseline Quake in any way that matters. The true test of maturity and documentation is "Is a mapper somewhere using the features?" [In Nexiuz they are ... ] Mappers came out in hordes to map for Quoth because they rock at good at making maps. And any mod needs maps. And we play games to experience little fun worlds with obstacles.
And Quoth was a well documented, well designed set of features and monsters that provided modding capability with a new and exciting feature set. Ladders, flash lights, an enforcer for every mood. Rotating thingies. Mappers saw Quoth and thought "Hey, finally! Someone who knows what we need, an easy to use boxed set of new playthings that doesn't involve coding!"
Until it is "easy", features do not matter and remain in the realm of ideas, never translated to reality. This is why Frikbot has been so widely used. DarkPlaces has incredible capabilities (just look at any Nexuiz recent screenshots page or videos), yet there are few tutorials or demonstration downloads (like that cool cubemapped flashlighty map) and lack of documentation is a killer. (No the engine coder shouldn't really be doing it, the engine coder should be writing code.)
What is needed is a GPL game development toolkit that is documented with tutorials that allows the easy creation of games with a basic set of models that mostly only requires mapping that easily exposes these advanced features to newbie modders.
There are too few 10 year Quake modders who knows all the undocumented/poorly documented features. Without ijed, Goldenboy, Avirox, Supa, MauveBib, Wazat, Lardarse ... Quake modding would be DOOMED.
But all of them are power-modders, anything except basic Quake or Quoth-like expansion sets are essentially inaccessible to ANY new Quake modders, except super-stubborn ones like MDave and Solitude guys.
DarkPlaces
If you want to see DarkPlaces rock, load this on a DarkPlaces server and connect with a DarkPlaces client. The design and implementation of the download protocol at it's finest ... the map downloads and you can play WHILE the models are still downloading -- *sigh* it's too awesome for words.
Universal Server V1 Beta: http://www.quake-1.com/files/universal/universal_r1_gamedir.zip
/100% non-QCCX code, switches between Rocket Arena, Zerstorer Deathmatch (wicked!), FFA with 111 maps, Slide and QMatrix via player voting and all maps are votable (running on 2 ProQuake 4.10 servers; tested on Darkplaces server). Should work on FTEQW too (with one modification), I listened to Spike's advice on QW and it sends the aliases on every map change to be QW-compatible.

Back to top |

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

Posted: Thu Jan 07, 2010 10:11 pm Post subject: |

Junrall wrote:
Hello everyone, I'm fairly new to the forums here, but would like to throw out an idea... After reading through this post my head is swimming with all of the ideas that are zinging around. Would it be a good idea to just start out with a matrix of all the engines listed across the top and then list the features that are common to each engine down the side? This would give a pretty good starting point right out of the gate and would provide a way to see which engine's features are on or off board with standardization.
Then after a bunch of the current features are taken care of add in others that aren't so common to all of the engines.
Visualize - Work with whats there - add the rest.
Ok... thats my two cents

Great idea. I suggest to create a spreadsheet in Google Docs open for people on this forums to edit, and allow the engine authors to mark every supported feature in their programs (I believe that when speaking about DP and FTEQW nobody is better to tell what - and how - they support than LordHavoc and Spike).
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Thu Jan 07, 2010 10:29 pm Post subject: |

The DarkPlaces download page lists the features: http://icculus.org/twilight/darkplaces/readme.html

Quote:
HalfLife map support (place your HalfLife wads in quake/id1/textures/ or quake/MODDIR/textures/ as the maps need them) Larger q1 and hl map size of +-32768 units. Colored lighting (.lit support) for q1 maps. Q3 map support (no shaders though), with no limits.
Q2 and Q3 model support, with greatly increased limits (256 skins, 65536 frames, 65536 vertices, 65536 triangles). (Note: md2 player models are not supported because they have no skin list)
Optimized QuakeC interpreter so mods run faster.
Bounds checking QuakeC interpreter so mods can't do naughty things with memory.
Warnings for many common QuakeC errors.
Unprecached models are now a warning (does not kill the server anymore).
External texture support (see dpextensions.qc DP_GFX_EXTERNALTEXTURES).
Fog ("fog" key in worldspawn, same parameters as fog command).
.spr32 and halflife .spr sprites supported. (Use Krimzon's tool to make spr32, and lhfire can render directly to spr32, or just use replacement textures on .spr).
Skybox ("sky" key in worldspawn, works like loadsky and quake2).
Stereo wav sounds supported.
Ogg Vorbis sounds supported. (Thanks Elric)
ATTN_NONE sounds are no longer directional (good for music).
play2 sound testing command (ATTN_NONE variant of play).
r_texturestats and memstats and memlist commands to give memory use info.
Lighting on sprites (put ! anywhere in sprite filename to enable).
More r_speeds info (now a transparent overlay instead of spewing to console).
Supports rotating bmodels (use avelocity, and keep in mind the bmodel needs the "origin" key set to rotate (read up on hipnotic rotation support in your qbsp docs, or choose another qbsp if yours does not support this feature), or in q3 maps an origin brush works).
More sound channels.
More dynamic lights (32 changed to 256).
More precached models and sounds (256 changed to 4096).
Many more features documented in dpextensions.qc. (bullet tracing on models, qc player input, etc)

And dpextensions.qc*
*modified to a link by scar3crow for sanity's sake

Back to top |

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

Posted: Thu Jan 07, 2010 11:41 pm Post subject: |

Baker wrote:
The DarkPlaces download page lists the features: http://icculus.org/twilight/darkplaces/readme.html

Your quote of the dpextensions.qc got cut off, and is probably not a good idea on a forum anyway
The feature list is very incomplete, I haven't felt like updating it in years, and the autobuild ( http://icculus.org/twilight/darkplaces/files/darkplacesengineautobuild.zip ) has recent features like shadowmapping and deferred rendering that are not mentioned in the feature list (although I'm not sure that graphics options are really applicable to modding).

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Fri Jan 08, 2010 2:08 am Post subject: |

LordHavoc wrote:

Baker wrote:
The DarkPlaces download page lists the features: http://icculus.org/twilight/darkplaces/readme.html

Your quote of the dpextensions.qc got cut off, and is probably not a good idea on a forum anyway

The EF_ ones, many of them seem like a no-lose situation to implement. No protocol changes required (unless I'm mistaken).
And things like "draw only to client" likewise would leave the protocol untouched and only affect the server side. Alpha and fullbright are essentially supported by a few engines in a modified protocol (JoeQuake, FitzQuake 0.85, aguirReQuake, Qrack, ProQuake) -- different ones.
Some of the math functions and many of the built-ins wouldn't affect anything significant or break anything existing.
Does DarkPlaces has some sort of "team scoring total" equivalent of pq_teamscores or whatever Quakeworld uses to keep track of a team's total scores? Ditching qccx and ProQuake "proprietary" functions is something that R00k and I have a strong interest in, but well -- we don't want to "lose" them but rather use an acceptable standard way to do it.

Quote:
#define EF_NODRAW 16 #define EF_ADDITIVE 32 #define EF_BLUE 64 #define EF_RED 128 #define EF_NOGUNBOB 256 // LordHavoc: when used with .viewmodelforclient this makes the entity attach to the view without gun bobbing and such effects, it also works on the player entity to disable gun bobbing of the engine-managed .viewmodel (without affecting any .viewmodelforclient entities attached to the player)
#define EF_FULLBRIGHT 512 // LordHavoc: fullbright
#define EF_FLAME 1024 // LordHavoc: on fire
#define EF_STARDUST 2048 // LordHavoc: showering sparks
#define EF_NOSHADOW 4096 // LordHavoc: does not cast a shadow
#define EF_NODEPTHTEST 8192 // LordHavoc: shows through walls
#define EF_SELECTABLE 16384 // LordHavoc: highlights when PRYDON_CLIENTCURSOR mouse is over it
#define EF_DOUBLESIDED 32768 //[515]: disable cull face for this entity

You think movetypes and physics extensions would automatically supportable too.

Quote:
#define MOVETYPE_BOUNCEMISSILE 11 // bounce w/o gravity #define MOVETYPE_FOLLOW 12 // track movement of aiment #define MOVETYPE_FAKEPUSH 13 // tenebrae's push that doesn't p

Quote:
"DP_SV_DRAWONLYTOCLIENT "

Back to top |

Lardarse Joined: 05 Nov 2005 Posts: 243 Location: Bristol, UK |

Posted: Tue Jan 12, 2010 9:26 am Post subject: |

mh wrote:

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?

I'm a little late to this thread (and I haven't read past this post yet), but there is something that I (as a modder) would like to see:
I'd like to see a way for additional things to be displayed in the hud. Currently, the .items interface has a lot of wasted space, space that could be used by modders to display things that they want to communicate to the player without having to either resort to traditional methods, such as centerprinting, OR using CSQC.
The space I'm talking about is here:

Code:
float IT_EXTRA_WEAPON = 128; float IT_SHELLS = 256; float IT_NAILS = 512; float IT_ROCKETS = 1024; float IT_CELLS = 2048;
float IT_AXE = 4096;
float IT_ARMOR1 = 8192;
float IT_ARMOR2 = 16384;
float IT_ARMOR3 = 32768;
float IT_SUPERHEALTH = 65536;

That's 10 bits that are not used to their full potential. An interesting use for the weapon bits could be to display different images in the bottom-right "picture box" (to the left of the .currentammo number) if more than one of these 4 bits are set. Likewise with the 3 armor bits in the bottom left corner. The other 3 don't display anything in the hud, but it would be nice for them to do something. IT_SUPERHEALTH suggests itself to use the area to the right of the health display (where hipnotic put the keys). The other 2 bits could be used for other purposes. Something that I would like to see possible is a way to display an alternate background image on the ammo row (I forget the actual sprite name, "ibar" perhaps?). Rogue does this, but in a different way (it derives it from .weapon I think) which reduces the possibilities.
I believe that there is no reason why the above changes could not be done in a completely backwards-compatible way, to the point where if the image for something new cannot be found, then do something sensible instead of either complaining of not finding the image (feel free to complain with developer 1) or displaying something horrible looking in its place.
I'm not entirely opposed to CSQC (although I will admit to being mostly opposed, though). It just offers quite a lot that is, for most purposes, overkill.
I could mention more traditional things, such as fixing the cvar() and ftos() built-ins to work properly together, or adding extra built-ins, but I'm 6 pages behind here, and I don't want to waste time reading to avoid repeating what's been said already until after I've tabled something that is potentially controversial...
_________________
<ekiM> Son, you're writing data structures your CPU can't cache.

Back to top |

r00k Joined: 13 Nov 2004 Posts: 483 |

Posted: Thu Jan 14, 2010 4:28 am Post subject: |

To be totally honest, my engine is a working archive of QuakeSource.org. At the very minimum the standards should be what people can snap together from the tutorials, max>> DarkPlaces && FTE

Back to top |

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

Posted: Thu Jan 14, 2010 6:37 pm Post subject: |

I'm having a really tough time deciding on where to draw the line with graphical features. It's actually fairly simple stuff as I see it, such as external textures. The reason it's tough is due to software engines. I really want them to be part of this. I really need help deciding what's feasible to ask from a software engine. This is important for all the console and handheld ports, which I really want to support.
How feasible are the following features:

- Support for 24-bit external tga's (could they perhaps be converted to quake palette on load?)
- Fog
- Alpha (this was discussed briefly, and seemed okay)
- Skybox (kind of ties in with the tga one, as it'd be made of 6 tga's)
- Colored lighting (lookup tables again?)

Also, am I missing anything?
_________________
Look out for Twigboy

Back to top |

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

Posted: Thu Jan 14, 2010 7:36 pm Post subject: |

In terms of software: 24-bit replacement textures is useless. The lighting routines generally require a fixed pixel:lightsample ratio. and if you're converting to quake's palette in the first place, you've neither got greater colour depth nor larger textures. Sorry, I just think its pointless for 8-bit software rendering.
Fog: World rendering draws colour and depth separately. Would need to combine those, killing the assembler routines, so the depth can be calculated at the same time that the colours are written. Alternatively the depth pass could update the colours, but that depends on where your frame buffer is for speed.
Alpha: stippled alpha looks kinda poo at 320*200. My biggest concern with alpha is its interaction with fog (which is why FTE doesn't support gl fog, but its not just alpha, but really blending with fog in general, so why am I writing this under the title of alpha?). It can take a lot of time to implement alpha universally though. GL engines would also support tga alpha channels. That's much harder in software, and not plausable when stippling.
Alpha-tested bsp (sub)models would be more useful, imho. Followed by transparent water then glass effects on submodels. I don't really see the a proper need for transparencies on mdls, the only place where its useful is on the viewmodel. Someone may wish to make a doom-like spectre but that's a special case. Fading out gibs smoothly may be useful, but with stippling that's not going to happen anyway.
Skybox: Quake2 has a skybox in software. Its not too outrageous, but I agree with r00k in that it needs a tutorial to add it before it can ever be 'standard'. Q2 uses pcx or tga, though personally I'd prefer paletizing tga as required, as so few mods would come with pcx anyway.
Coloured lighting: I'm not sure quake's palette has enough variety for this to look nice when paletted, but for 16+bit rendering, sure. Also, tables would change per lightmap sample. The only sane way to do it is to limit the number of shades to then choose colourmaps based on the ratio of the colours. I don't think coloured lighting will break much, so long as the proper intensities are used (eyes see different intensities of different colours).
_________________
What's a signature?

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Thu Jan 14, 2010 8:22 pm Post subject: |

Urre wrote:
Support for 24-bit external tga's (could they perhaps be converted to quake palette on load?)

/Yes I know you know this, but I post extra information for whoever else that reads this.
The Half-Life map format does not require external textures and is supported by:
DarkPlaces
FTEQW --- both GL and software!
Qrack
FuhQuake
ezQuake
ProQuake
And there is a tutorial (link) to add it other engines and the same .map source file only requires very mild modification to compile the map as such.
I can understand external textures for models as the Quake model format is palette limited and I can understand this for sprites.
I think FTEQW's 16 bit and 32 bit color software rendering capability should be a standard available option in software rendering engines. (If I happen to do this before anyone else, I'll write up a tutorial on how to convert an 8-bit engine into 16/32 bit color supporting).
The main reason for Quake map format 2.0 is to have "Half-Life level color" (256 colors PER texture = 8-bit) and origin brushes available (revolving doors instead of doors that must slide open) the "right way" either for those that would like to be able to make more colorful Quake maps or those that want to make total conversions.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> General Discussion | All times are GMT Goto page Previous 1, 2, 3 ... 10, 11, 12 ... 14, 15, 16 Next
Page 11 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