View previous topic :: View next topic |
Author |
Message |
FrikaC Site Admin

Joined: 08 Oct 2004 Posts: 947
|
Posted: Tue Jan 05, 2010 11:37 am Post subject: |
|
|
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 |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Tue Jan 05, 2010 12:21 pm Post subject: |
|
|
Ah, I knew that!
I forgot there was a PF_substring there...
Well either way FRIK_FILE (updated) should be supported  |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 910
|
Posted: Tue Jan 05, 2010 12:22 pm Post subject: |
|
|
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 |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Jan 05, 2010 12:37 pm Post subject: |
|
|
r00k wrote: | Ah, I knew that!
I forgot there was a PF_substring there...
Well either way FRIK_FILE (updated) should be supported  |
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 |
|
 |
lth

Joined: 11 Nov 2004 Posts: 129
|
Posted: Tue Jan 05, 2010 2:52 pm Post subject: |
|
|
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 |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Jan 05, 2010 7:42 pm Post subject: |
|
|
<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 |
|
 |
LordHavoc
Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA
|
Posted: Tue Jan 05, 2010 8:08 pm Post subject: |
|
|
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 |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Wed Jan 06, 2010 1:08 am Post subject: |
|
|
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 |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Wed Jan 06, 2010 4:36 am Post subject: |
|
|
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?  |
|
Back to top |
|
 |
reckless
Joined: 24 Jan 2008 Posts: 390 Location: inside tha debugger
|
Posted: Wed Jan 06, 2010 6:16 am Post subject: |
|
|
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 |
|
 |
Spirit

Joined: 20 Nov 2004 Posts: 476
|
Posted: Wed Jan 06, 2010 8:09 am Post subject: |
|
|
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 |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Wed Jan 06, 2010 8:17 am Post subject: |
|
|
Spirit wrote: | Aaahh, guys. Stop dreaming. |
No.  |
|
Back to top |
|
 |
MDave

Joined: 17 Dec 2007 Posts: 75
|
Posted: Wed Jan 06, 2010 8:51 am Post subject: |
|
|
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  |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 910
|
Posted: Wed Jan 06, 2010 5:22 pm Post subject: |
|
|
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 |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Thu Jan 07, 2010 12:31 am Post subject: |
|
|
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 |
|
 |
|