Inside3D!
     

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



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

PostPosted: Mon Jan 04, 2010 10:52 pm    Post subject: Reply with quote

r00k wrote:
standard defaults for density start end etc... for me my defaults look like this, you can barely see the doorways in the distance begging your interest...



Here is my best recreation of that shot, with rtworld:


Here is my best recreation of that shot, without rtworld:


Here is the dpmod/maps/start.ent file I made to do it:
http://havoc.planetnexuiz.com/start.ent

Note: needs dpmod for the rain_think function.

I did take the liberty of using height fog instead of global fog though.
Back to top
View user's profile Send private message Visit poster's website
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Mon Jan 04, 2010 11:04 pm    Post subject: Reply with quote

frag.machine wrote:
leileilol wrote:
Tread3D can work with huge map sizes.

The map size thing would require ripping up the protocol. It's anti-standard.


If we are talking about a new protocol embedded in the spec, no problem.

Why not use the full floating point range then? Anti-wallhack can help keep the protocol overhead down, and protocol 15 should still be supported anyway for bandwidth-critical ops.

Remember also that protocol 15 was designed for use on 28.8 dialup; it's long overdue replacement or expansion.

___________________________


Just one point on skyboxes lest they get lost in the general chatter. Skyboxes are a lot more than just eyecandy; they eliminate the rendering overhead from classic Quake sky, and so are an easy way for any engine to enable a map to have larger outdoor areas. Imagine what Marcher would run like if that wasn't a skybox?

So they're of practical use too, and definitely warrant a better focus rather than being dismissed as an inessential (or at best partially essential) eyecandy engine feature.
_________________
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
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Mon Jan 04, 2010 11:09 pm    Post subject: Reply with quote

Quote:
Just one point on skyboxes lest they get lost in the general chatter. Skyboxes are a lot more than just eyecandy; they eliminate the rendering overhead from classic Quake sky, and so are an easy way for any engine to enable a map to have larger outdoor areas. Imagine what Marcher would run like if that wasn't a skybox?


There are other ways to eliminate the cost of large sky surfaces, for example rendering the traditional quake sky using a subdivided cube or sphere.
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Mon Jan 04, 2010 11:14 pm    Post subject: Reply with quote

metlslime wrote:
Quote:
Just one point on skyboxes lest they get lost in the general chatter. Skyboxes are a lot more than just eyecandy; they eliminate the rendering overhead from classic Quake sky, and so are an easy way for any engine to enable a map to have larger outdoor areas. Imagine what Marcher would run like if that wasn't a skybox?


There are other ways to eliminate the cost of large sky surfaces, for example rendering the traditional quake sky using a subdivided cube or sphere.

...or a fragment/pixel shader on the unsubdivided surf, but all the same, skyboxes do remain the simplest way that anyone can implement in their engine right 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
scar3crow
Inside3D Staff


Joined: 18 Jan 2005
Posts: 837
Location: Las Vegas, NV

PostPosted: Tue Jan 05, 2010 12:06 am    Post subject: Reply with quote

I have nothing to contribute, other than I still love the Quake sky and tend to give a cold gaze to all but the most amazing (and amazingly appropriate) skyboxes. They almost never feel at place at all in Quake.

So, how about that QSB?
_________________
...and all around me was the chaos of battle and the reek of running blood.... and for the first time in my life I knew true happiness.
Back to top
View user's profile Send private message AIM Address
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Tue Jan 05, 2010 12:13 am    Post subject: Reply with quote

Some thoughts based on everyone's comments:

1. There have been a lot of suggestions for features that have nothing to do with map or mod support/compatibility. We should definitely exclude these as being completely irrelevant to this project.

2. Some of the suggestions are on-topic, but represent features that are not widely implemented or would be hard to standardize now because they are too new, don't exist, or vary too much, such as native rotating brushes, or weather effects. I think some of these could go into a future standard AFTER enough engines have informally implemented it in a consistent enough way to be useful.

3. Fog is a good example of a feature that is standard enough to be widely used, but still has some issues in that different engines don't interpret the numbers in exactly the same way. Perhaps in this case the standard should include a definition of how the fog should be calculated, for example whether to use GL_EXP or GL_EXP2, and in the case of implementations that calculate their own fog in software (i think Darkplaces does this) define the actual fog calculation. Or, maybe we can accept that fog isn't identical across engines, but is at least close to being correct? If so how close does it have to be? Another fog-related issue is whether the sky is rendered when fog is present, and if so, how the fog interacts with it.

4. Skyboxes are another case where things are almost standard. I think the two issues are orientation (which side of the box is north) and what folder the images should be stored in. I believe almost all engines orient the skyboxes the same way; there was a bug in the older darkplaces that rotated it 90 degrees from the typical standard, but that's long been fixed. The folder issue is fairly simple, it is a good idea for engines to support all known folder paths, so that legacy content doesn't break, but only new content is going to advertise the "standard" and so the standard only needs to declare one folder.

5. QC control of sky and fog is a really good idea, however the "stuffcmd" method is really ugly and has the negative effect that it demands a certain cvar or command be present on a client. I think the correct approach would be to provide builtins for the quakec, and those builtins would generate a message using the server's current network protocol. This way the standard would not have to make any demands of the client UI or the server protocol. At worst, a lazy engine could implement that builtin by generating its own stuffcmd message, but this standard is pretty much going to require some sort of custom protocol anyway (higher precache limits,) so adding additional requirements to the network protocol wouldn't be too much of a burden, i guess.

6. which brings up the question, is it outside the scope of this project to define the network protocol itself? Technically demos are content, and if your engine can't read the protocol it can't display the demo for the user. However, A. that may be a tolerable loss, and B. it is a huge can of worms and would probably stall this project indefinitely.

7. External textures may be a good candidate for this standard, they are widely used in the field, implemented in multiple engines, and are already mostly consistent across engines. It might be worth it to include them, and clean up the small inconsistencies that remain. I think the only issues are with folder paths and file names at this point.

8. We may want to create a roadmap for future versions so that programmers and modders can work towards the future standards as soon as possible. So even if something isn't part of Quake 2.0, we can say that it will be in Quake 2.1 and people can start implementing it.

9. I agree with the observation about "GLQuake mods" and "Darkplaces mods". Part of the problem for me (as an engine developer) is that, when it comes to quakec extensions, there are like a hundred of them and i don't know which are most important, which mods need which extensions, and even which mods are most important to support first.

10. So based on #9, we have already got a pretty good list of map-oriented features, anyone want to put together a bullet list of the most useful quakec additions (ideally already implemented and used in the wild) that we would want in this standard? I would submit that "PR_CheckExtension" is probably feature #1 on such a list.
Back to top
View user's profile Send private message
Team Xlink



Joined: 25 Jun 2009
Posts: 320

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

First off, thank you LordHavoc for the new desktop background, it is absolutely beautiful.

Now onto the related content.

These should be in the standard:

Max FPS
Display FPS

They both have a tutorial on quakesrc.

If we are too really get this standard engine going, then I want to mention multiple platforms.

I for one will gladly work on an engine following the new standards (once there decided for sure) for the PlayStation Portable platform.
_________________
Anonymous wrote:
if it works, it works. if it doesn't, HAHAHA!
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Tue Jan 05, 2010 1:19 am    Post subject: Reply with quote

Team Xlink wrote:
These should be in the standard:

Max FPS
...


No way! First, Quake is designed to run at 72 frames per second and QuakeC runs at 10 frames per second.

For most engines (virtually all of them except DarkPlaces and FTEQW ... I think), frames per second in single player is also the "host_maxfps" (because there is no separation of rendering vs. server) -- as opposed to being connected to a server where the client frames per second is not the server frames per second and therefore safe because the physics are not impacted.

At a host_maxfps above 72 FPS, the physics are altered and you can do things not possible at 72 FPS (better NQ bunnyhopping and sometimes even slightly higher jump height) and in some cases the operation of doors and lifts appear to be impacted. (I have encountered a "killer lift" that kills me every time at 300 FPS in a map, but operates normally at 72 FPS).

/Plus non-modding and non-mapping engine features are not supposed to be posted in the thread. So something like user preferences aren't supposed to be posted here (even though most of us have done it at least once .) Very Happy
Back to top
View user's profile Send private message
r00k



Joined: 13 Nov 2004
Posts: 483

PostPosted: Tue Jan 05, 2010 2:15 am    Post subject: Reply with quote

basic string functions would be a must.

strcat, strcopy, strlen, substr, etc.. available thru quakeC makes menus more dynamic. and could possibly open up more to the csqc subset.
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Tue Jan 05, 2010 3:43 am    Post subject: Reply with quote

r00k wrote:
basic string functions would be a must.

strcat, strcopy, strlen, substr, etc.. available thru quakeC makes menus more dynamic. and could possibly open up more to the csqc subset.


I like Remake Quake's "world type" in worldspawn to designate what type of items should be used. Maybe that isn't quite on-topic since it is QuakeC alone and not related to the engine.

On topic:

FOV Locking (function of CSQC?). For guns and zooming: I wish engines had a way to disable tampering with FOV specifically WHEN using a mod that isn't supposed to allow such tampering. Like if zooming is the function of a weapon and a specific benefit of said weapon. Plus whatever extension is required for properly manipulating client FOV that isn't screwing with the cvar. (Like Half-Life, Turok, every other game known ...)

Crosshair. I guess this falls under CSQC.

Sensitivity scaling when zoomed. Probably falls under CSQC.

Radar generation (limited color). Engine side radar image generation that works with OpenGL 1.2 and is reasonably easy to implement without vertex arrays. MH wrote a radar one requiring vertex arrays ( http://forums.inside3d.com/viewtopic.php?t=1345 ). I think having to have the map provide one like ezQuake is cheesy. Maybe automatic generation in a software renderer would be a pain, though?



Infinite distance topdown projection generation. A true rendering of the map at infinite distance. Again, might be a pain in a software renderer.



Whatever QuakeC extension would be required to detect if a player is walking on a surface that starts with "metal_" or "stone_" for surface flags so custom footsteps can be done.
Back to top
View user's profile Send private message
Chip



Joined: 21 Jan 2009
Posts: 314
Location: Romania

PostPosted: Tue Jan 05, 2010 9:01 am    Post subject: Reply with quote

OK, I'm not an engine coder but I'm a web programmer, so I'm close to these concepts.

What about writing a function, or a routine that loads external modules or extensions in the forms of .c and .h files. This way, an engine coould be modular, and additional functionality could be loaded if desired.

Let's say I want rain, I have rain entities in my mod, and the engine (based on QSB 1.0) does not have rain functionality. I add a require('rain.c') line to a certain file in the engine (similar to progs.src) and voila, I have rain in my mod.

The modules should have standards, too.

Is this a good idea or am I off course?
_________________
My Projects: Quake 1 Mods | OpenQuartz 2 | ChipQuake
Back to top
View user's profile Send private message Visit poster's website
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Tue Jan 05, 2010 9:32 am    Post subject: Reply with quote

Baker wrote:
Radar generation (limited color). Engine side radar image generation that works with OpenGL 1.2 and is reasonably easy to implement without vertex arrays. MH wrote a radar one requiring vertex arrays ( http://forums.inside3d.com/viewtopic.php?t=1345 ). I think having to have the map provide one like ezQuake is cheesy. Maybe automatic generation in a software renderer would be a pain, though?

Hey! Nothing wrong with vertex arrays; they're your friend you know (and they're also as standard in OpenGL as glBindTexture is, going back to 1.1). Use indexed arrays and you're looking at some serious performance boost in maps that traditionally give the Quake engine trouble - now that's something that mappers would like to see becoming commonplace, I am sure.
_________________
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: Tue Jan 05, 2010 9:47 am    Post subject: Reply with quote

Quote:
Use indexed arrays and you're looking at some serious performance boost in maps that traditionally give the Quake engine trouble - now that's something that mappers would like to see becoming commonplace, I am sure.


Er, yes. Good idea.
_________________
ReMakeQuake
The Realm of Blog Magic
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Tue Jan 05, 2010 9:47 am    Post subject: Reply with quote

mh wrote:
Hey! Nothing wrong with vertex arrays; they're your friend you know (and they're also as standard in OpenGL as glBindTexture is, going back to 1.1).


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).



Reckless wrote:
intel cant handle vertex arrays !!! /facepalm well seems laptops with intel chipsets are a nogo atm will try on my friends when he comes to visit maybe i can fix it.


I guess nothing prevents a check extension exception.

http://forums.inside3d.com/viewtopic.php?p=12998
http://forums.inside3d.com/viewtopic.php?p=13992

Remember those threads that caused you to make DirectQ because the OpenGL drivers for Intel wouldn't run MHQuake? Very Happy

Speaking of mini-maps, I had totally forgotten about that topic from a year ago and then checked DirectQ:

DirectQ - toggleminimap feature (click to enlarge)

Back to top
View user's profile Send private message
r00k



Joined: 13 Nov 2004
Posts: 483

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

Well more to the modder's point,
I have to use Qccx hunk hacks to do string manipulation

QuakeC code:
Code:

void () motd_playercount =
{
   if (HUNK_CONTEXT)
   {   
      local float n;
      local string s;
      local string temp;
      local entity e;
      
      e = find_team_entity (TEAM_BLUE);
      if (e != world)
      {
         n = number_teammates(e);
         s = ftos(n);                  
         temp = substr_replace (motd_top4, 10, 1, s);
         strcpy (motd_top4, temp);
      }
      else
      {
         temp = substr_replace (motd_top4, 10, 1, "0");
         strcpy (motd_top4, temp);                   
      }
      
      e = find_team_entity (TEAM_RED);
      if (e != world)
      {
         n = number_teammates(e);
         s = ftos(n);                  
         temp = substr_replace (motd_top4, 23, 1, s);
         strcpy (motd_top4, temp);
      }
      else
      {
         temp = substr_replace (motd_top4, 23, 1, "0");
         strcpy (motd_top4, temp);
      }
      
      e = find_team_entity (TEAM_YELLOW);
      if (e != world)
      {
         n = number_teammates(e);
         s = ftos(n);                  
         temp = substr_replace (motd_top4, 36, 1, s);
         strcpy (motd_top4, temp);
      }
      else
      {
         temp = substr_replace (motd_top4, 36, 1, "0");
         strcpy (motd_top4, temp);
      }
      
      e = find_team_entity (TEAM_GREEN);
      if (e != world)
      {
         n = number_teammates(e);
         s = ftos(n);         
         temp = substr_replace (motd_top4, 49, 1, s);
         strcpy (motd_top4, temp);
      }
      else
      {
         temp = substr_replace (motd_top4, 49, 1, "0");
         strcpy (motd_top4, temp);
      }      
   }
};

This builds a string like "[1] Blue Team [4]" where the 4 is a dynamic number based on how many player joined the match on the blue team...

and heres what substr_replace looks like
Code:

//
//  S U B S T R _ R E P L A C E
//
//  Replace a substring in 'expr' with 'replace'.  The substring is replaced
//  starting at 'offset' characters from the front of the string.  If 'length'
//  is zero, 'replace' is inserted at 'offset'.
//
string (string expr, float offset, float length, string replace)
substr_replace =
{
   local entity hunk;
   local float L1, L2, alloc_hunk;
   local string s;

   L1 = strlen (expr);
   if (!L1)
   {
      dprint ("substr_replace(): expr < 1 or expr > 255\n");
      return string_null;
   }

   L2 = strlen (replace);

   allocate_hunk (L1 + L2);
   alloc_hunk = ALLOCATE_HUNK;
   hunk = Get_Hunk (HUNK_CONTEXT, alloc_hunk);
   if (!hunk)
      return string_null;

   Write_Hunk_String_e (hunk, expr);

   if (offset)
   {
      if (offset < 0)
         offset = fabs (offset);
      if (offset > L1)
         offset = L1;
      hunk = *AddInt (&hunk, offset * %1);
   }

   if (replace)
   {
      Write_Hunk_String_e (hunk, replace);
      hunk = *AddInt (L2 * %1, &hunk);
   }

   if (length)
   {
      if (length < 0)
         length = fabs (length);
      if (length > L1)
         length = L1;
   }

   if (offset + length <= L1)
      L1 = offset + length;

    s = @AddInt (AddInt (AddInt (&expr, PSTRING_TO_PQUAKEC), L1 * %1), PQUAKEC_TO_PSTRING);
   Write_Hunk_String_e (hunk, s);

   return Read_Hunk_String (HUNK_CONTEXT, alloc_hunk);
};


YUK!

If I could just use a standard extension.....

string (string expr, float offset, float length, string replace) substring_replace = #9000;

I could run my mod on FTE or DP etc, if that extension was supported!
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 ... 8, 9, 10 ... 14, 15, 16  Next
Page 9 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