Inside3D!
     

Engine standards for mod compatibility
Goto page Previous  1, 2, 3 ... 9, 10, 11 ... 14, 15, 16  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion
View previous topic :: View next topic  
Author Message
FrikaC
Site Admin


Joined: 08 Oct 2004
Posts: 947

PostPosted: Tue Jan 05, 2010 11:37 am    Post subject: Reply with quote

FRIK_FILE can be used to make that a lot less ugh, r00k. QCCX hacking is never a good idea.

I was going to say that FRIK_FILE is probably the most common extension out there, because the waypoint editor in FrikBot is in so many mods, but I guess I forgot to update that code and its still using the old QSG_FILE builtin numbers. Crap.

FRIK_FILE proper is at least supported in Prydon for what its worth.
Back to top
View user's profile Send private message Send e-mail
r00k



Joined: 13 Nov 2004
Posts: 483

PostPosted: Tue Jan 05, 2010 12:21 pm    Post subject: Reply with quote

Ah, I knew that!

I forgot there was a PF_substring there...

Well either way FRIK_FILE (updated) should be supported Very Happy
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Tue Jan 05, 2010 12:22 pm    Post subject: Reply with quote

Baker wrote:
I *like* vertex arrays.

It is my understanding that they aren't supported on at least some of the older Intel display adapters and my priority #1 is maximal compatbility (engine runs on all machines).

You shouldn't need to check for extensions with vertex arrays, just the same as you don't need to check for GL_EXT_texture_object any more. They're probably just not exported in the extension string (just like texture objects wouldn't be in the extension string), but they're there alright. Just #include <gl/gl.h> and call glVertexPointer, glDrawArrays, etc (not glVertexPointerEXT, that probably doesn't exist, just like glBindTextureEXT doesn't exist) and they should just work.

At least they did for me on my old Intel 915.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Tue Jan 05, 2010 12:37 pm    Post subject: Reply with quote

r00k wrote:
Ah, I knew that!

I forgot there was a PF_substring there...

Well either way FRIK_FILE (updated) should be supported Very Happy


Rook let this lighten the task:

RocketGuy's EBFS + Frik_File ProQuake 3.50 (download source)

Merge against ProQuake 3.50 (download source) to find differences:


Prydon qc source (download) if you do not have



@MH. Ok ... well, that makes sense. Back in Dec 2008 when those threads occurred, OpenGL was half a mystery to me and it was the next week when I set out to finally learn OpenGL. I had the impression vertex arrays weren't supported from that thread but it was mostly greek to me at the time.
Back to top
View user's profile Send private message
lth



Joined: 11 Nov 2004
Posts: 129

PostPosted: Tue Jan 05, 2010 2:52 pm    Post subject: Reply with quote

Coming back to the question of what should be standard, here is my two cents from a modder's point of view, as someone who has pretty exclusively modded specifically for DarkPlaces:
- External texture support for .mdls in tga with alpha that is correctly rendered in-game - AFAIK even DP still renders .mdls with alpha tgas front-to-back.
- MOVETYPE_FOLLOW as seen in DP is so powerful and useful for so many things.
- custom particle effects via effectinfo or whatever.
- string manipulation that doesn't cause memory leaks.
- viewmodelforclient / drawonlytoclient etc - vmforc is really important since it lets you do lots of clever HUD things. Perhaps CSQC will replace this eventually but as others have said it is not mature and not well documented.
- DP's physics QC file. Never used it myself but I can see how being able to alter basic player physics would be vital for some mods.
_________________
randomviolence - tactical combat boardgame
Back to top
View user's profile Send private message
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Tue Jan 05, 2010 7:42 pm    Post subject: Reply with quote

<offtopic>GL_EXT_texture_object was made core in GL 1.1, but the exports lack the EXT postfix</offtopic>

DP's physics QC file cannot be used with QW engine prediction.

FRIK_FILE's string manipulation builtins are important, but the file manipulation is questionable for many (especially for csqc). Bit clumsy to use without some sort of multiple temp strings from strcat though.

QCCx hacks should never be endorsed as a standard. From an engine perspective, it is too limiting (eg: r00k's code shows hunk stuff, but eg. DP doesn't have a hunk any more).
Same with pluggable engine modules (which is kinda what csqc is for - pluggable stuff only works where there is a proper api for it, which is what csqc is for, and compiled c isn't cross platform).

Regarding rain... Rain, snow, sleet, acid rain, biological goo. What precipitates where? Lava smoke, slime ejections, steam, ground fog... How does a simple enable flag interact with a fully scriptable system?
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
LordHavoc



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

PostPosted: Tue Jan 05, 2010 8:08 pm    Post subject: Reply with quote

Baker wrote:


I believe the extension being checked for is GL_EXT_compiled_vertex_array which is NOT standard and many drivers do not support, it was never adopted as a core OpenGL feature because it was such a bad hack, and often did not help performance at all.

Requiring a very stupid GL extension that has been repeatedly rejected by the OpenGL standards group (ARB) is a good way to upset users.

That extension has been known to crash in some drivers too.

DarkPlaces stopped using it about a year ago, and I finally removed the code for it today because it's a waste of time to maintain support for a bad extension.

Now if you want fast rendering of huge maps, the GL extension you want is GL_ARB_vertex_buffer_object - combine all surfaces of the bsp into one mesh, upload it to video memory (GL_STATIC_DRAW vertex buffers) and render sections of it selectively based on visible surfaces (I.E. a surface becomes a range of vertices and triangles in the world mesh), this performs quite well, and is how darkplaces operates. You obviously have to turn off the vertex buffer when rendering deformed water and such - this is why darkplaces has no warps, it just scrolls texcoords using the GL_TEXTURE matrix in hardware (even on Geforce1 or original Radeon).
Back to top
View user's profile Send private message Visit poster's website
goldenboy



Joined: 05 Sep 2008
Posts: 310
Location: Kiel

PostPosted: Wed Jan 06, 2010 1:08 am    Post subject: Reply with quote

One more point: Liquid textures (*water etc) larger than 64x64 should be correctly rendered by all engines.

DUH.
_________________
ReMakeQuake
The Realm of Blog Magic
Back to top
View user's profile Send private message
r00k



Joined: 13 Nov 2004
Posts: 483

PostPosted: Wed Jan 06, 2010 4:36 am    Post subject: Reply with quote

Spike wrote:

QCCx hacks should never be endorsed as a standard. From an engine perspective, it is too limiting (eg: r00k's code shows hunk stuff, but eg. DP doesn't have a hunk any more).

Exactly! I'm only displaying the condition I'm trying to escape from.

Spike wrote:

Regarding rain... Rain, snow, sleet, acid rain, biological goo. What precipitates where? Lava smoke, slime ejections, steam, ground fog... How does a simple enable flag interact with a fully scriptable system?

same way a cvar does? Wink
Back to top
View user's profile Send private message
reckless



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

PostPosted: Wed Jan 06, 2010 6:16 am    Post subject: Reply with quote

hmm couldnt mh's memory allocation system be the defacto standard ? im using it in realm and so far it behaves quite nicely.

it emulates the hunk system for easier implementation but in fact it uses a virtual allocation table much like dp's and is only limited by system ram ie. no need at all for memory switches.

its also a part (a big part) of the pk3 tutorial im writing up so if zip/pk3 etc support should be made a standard this might be a thing to consider ?.
Back to top
View user's profile Send private message
Spirit



Joined: 20 Nov 2004
Posts: 476

PostPosted: Wed Jan 06, 2010 8:09 am    Post subject: Reply with quote

Aaahh, guys. Stop dreaming. Think about what should be in a first standard. Easy things. Things that are at least a bit common already. Things that maps and mods already use.

Also please don't post gigantic images, it stretches the sites and makes everything harder to read.
_________________
Quake Maps
Back to top
View user's profile Send private message Visit poster's website
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Wed Jan 06, 2010 8:17 am    Post subject: Reply with quote

Spirit wrote:
Aaahh, guys. Stop dreaming.


No. Twisted Evil
Back to top
View user's profile Send private message
MDave



Joined: 17 Dec 2007
Posts: 75

PostPosted: Wed Jan 06, 2010 8:51 am    Post subject: Reply with quote

Environment mapping effect for map surfaces? Easy code to do, just the glquake sky surface poly warpping effect, but without the scroll and uses an ordinary texture image. Kurok has this effect for glass and metal surfaces if you want to see what I'm talking about.

No idea how to do the effect in software rendering though, but I imagine it's quite possible. Half-Life did the effect in software rendering for certain models, like the revolver, black parts of the HEV suit and the black op girls.

Would be neat for Quake models too Smile
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Wed Jan 06, 2010 5:22 pm    Post subject: Reply with quote

reckless wrote:
hmm couldnt mh's memory allocation system be the defacto standard ? im using it in realm and so far it behaves quite nicely.

it emulates the hunk system for easier implementation but in fact it uses a virtual allocation table much like dp's and is only limited by system ram ie. no need at all for memory switches.

its also a part (a big part) of the pk3 tutorial im writing up so if zip/pk3 etc support should be made a standard this might be a thing to consider ?.

I might have a look at setting something up in such a way that it can completely replace the old Hunk but retain the very same interface (so that anyone porting it to their engine can just drop-n-go with it - not being able to do that would kill the idea stone dead).

This is way off-track for this thread, but any Linux people who would be willing to port and test it on Linux should speak up now.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
goldenboy



Joined: 05 Sep 2008
Posts: 310
Location: Kiel

PostPosted: Thu Jan 07, 2010 12:31 am    Post subject: Reply with quote

I can compile and test anything on Linux, not sure about porting engine components though. I have only done "some hacking" previously. PM me if you need anything.
_________________
ReMakeQuake
The Realm of Blog Magic
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion All times are GMT
Goto page Previous  1, 2, 3 ... 9, 10, 11 ... 14, 15, 16  Next
Page 10 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