Inside3D!
     

Future Tutorial Ideas ...
Goto page 1, 2, 3, 4  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming
View previous topic :: View next topic  
Author Message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Sun Nov 23, 2008 3:32 am    Post subject: Future Tutorial Ideas ... Reply with quote

I thought this might eventually evolve to be an interesting thread.

I also want to list the ones that I am considering personally contributing to the mix, either because it involves something interesting to me or that I want to study.

1. Adding Half-Life map support

(I find Half-Life .bsp to be intriguing Wink Not because it is Half-Life, but because if most of the changes in Quakeworld were Quake 1.5, Half-Life would be Quake 1.9 as it extended base Quake to new places. )

2. Adding scoreboard ping display to standard Quake

(I'd like to completely deconstruct how it works in ProQuake and then maybe improve it slightly based off DarkPlaces implementation).

3. Adding external .ENT support (this makes life so much easier, every engine should have this).
4. Fixing GLQUAKE so it color maps dead player bodies (LordHavoc did this way back in 2000).
5. Fixing the half-underwater rendering in GLQUAKE where it looks all distorted. [It may have been in quakesrc.org forums, but if so, it is dead].

This probably died in the Quakesrc.org implosion, but it doesn't exist now so #5...

6. Fixing GLQUAKE function as a dedicated server. (it's quite easy)

Recently I've played around with NPRQuake and something I'd think would be fun to do is isolating various renderers. In the past, I would have added JoeQuake to the following list, but I'm not sure there is much of a different between it and standard GLQuake except the fullbright and overbright support plus the "half in the water" rendering fix:

7. Adding the NPRQuake "sketch" renderer as native. (The .dll method that NPRQuake uses is very slow. And NPRQUAKE's .dll files aren't coded to support interpolation, for instance, and altering them would be a pain. Although they put a lot of work into exporting the rendering into a .dll, which was cool .. the speed for some reason isn't high.)
8. Adding only the FitzQuake 3D rendering portion to GLQUAKE.
9. Going historical and isolating DarkPlaces rendering in old DarkPlaces builds and doing the same.

(FitzQuake and DarkPlaces make the environment look a lot richer and really, I think a client that could switch between a few diffferent renderers would be cool. Especially in real-time via a toggle.).

And then as a huge fan of Fitzquake's texture manager:

10. Adding only the FitzQuake Texture manager to GLQUAKE.

^ Now the above has a interesting application. You could make a brightness slider that doesn't use hardware gamma while having an exact GLQUAKE look as well by clearing and reloading the textures with alterations to palette gamma modifier. An added benefit of not using hardware gamma is that it doesn't mess up brightness in Windows if a crash occurs AND it can adjusted independently from the Windows desktop. Yeah, it'd be a little slower during the adjustment, but a fun experiment.

[ezQuake does the above, but not with the care and concern of the purpose of the FitzQuake texture manager Wink I like the touchy feely hands-on approach of touching, categorizing and making available the texture information.]

11. "copy edicts" or "condump edicts" capability. The copy command idea can be found here and a perfectly good any-engine condump can be found in the FitzQuake source in cmd.c. Anyway, it is somewhat annoying that typing the "edicts" even in DarkPlaces can't display the whole list of entities and their states (something that would help me with a rare and weird problem in an obscure engine project where the e4m4 silver key doesn't display! wtf!). My theory is that by allocating memory running an edicts command to get the size and dynamically allocating a string, copying it to the clipboard, and releasing it might provide a way to make the current states of all entities easily available. A theory at this point, since I haven't tried it. "edicts" would be a specially treated extra command argument.

12. Display mode switching in-game. Although I already have this and so do most other currently developed engines, it isn't as hard as it sounds. As long as you don't allow changing of the bpp ...

13. Intel display adapter fix. Again, most engines have this fixed now. But if you don't have the fix, your engine will crash and burn with certain [older] Intel display adapters. This really was a plague that helped destroy Quake, because they shipped with every new computer by Intel and could run Quake 3 and nearly every other game but not glquake. [How many people would buy a video card for a single old game when every other game works? Not many.]

/end ideas for now
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Fri Nov 28, 2008 7:53 am    Post subject: Reply with quote

Chase cam research.

Type chase_active 1 in the console while watching the old e1m3 demo1 play and you'll see some terrible "the camera goes outside the map" problems.

Only DarkPlaces is fixed. I've checked virtually ever engines and none are.

This is a BIG problem for any third-person-view mod and really annoying when using chase_active 1 in general.

Apparently LordHavoc was obsessed with this and nearly 8 years ago half-fixed it. And then it appears by late 2003, he had it fully fixed.

The important date and notes:

Quote:
2000-10-21 03:25 lordhavoc

* chase.c: fixed chase_active (TraceLine no longer returns '0 0 0'
when there was no impact)

2000-10-21 03:24 lordhavoc

* view.c: fix for player model tilting in chase_active mode

2003-08-23 03:19 havoc

* chase.c: fix severe bug that made chase_up continually increase
up to 118

2003-11-14 06:02 havoc

* chase.c


Yellow marks the first fully chase_active 1 fixed version of DarkPlaces.

The prior ones even dating back to version 73 (really, really old) had partial chase cam fixes better than any non-DarkPlaces engine, but you could still fiddle around and get the camera to poke outside the map in some rare situations.
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Fri Nov 28, 2008 4:56 pm    Post subject: Re: Future Tutorial Ideas ... Reply with quote

Baker wrote:
5. Fixing the half-underwater rendering in GLQUAKE where it looks all distorted. [It may have been in quakesrc.org forums, but if so, it is dead].

Find the mid-point of each surf and warp that, rather than warping the actual verts. Downside is it results in greater tesselation.

A bigger bug is that bmodel surfs in GLQuake aren't marked with SURF_UNDERWATER, which plays all manner of havoc if you want to combine underwater effects with translucent water.
_________________
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
leileilol



Joined: 15 Oct 2004
Posts: 1321

PostPosted: Fri Nov 28, 2008 6:17 pm    Post subject: Reply with quote

Baker wrote:
Chase cam research.

Type chase_active 1 in the console while watching the old e1m3 demo1 play and you'll see some terrible "the camera goes outside the map" problems.

Only DarkPlaces is fixed. I've checked virtually ever engines and none are.

FrikaC did a tutorial on fixing this several ages back (before Darkplaces had the fix), and several engines have implemented this including TomazQuake, so your "every engine = qrack, fitz, joequake, ezquake, darkplaces" scope is limited.
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Fri Nov 28, 2008 6:48 pm    Post subject: Reply with quote

Before I wrote this up, I checked Telejano which is based on TomazQuake and it isn't chase cam fixed.

I loaded up TomazQuake 1.48 and I see the chase camera going outside the map or into the wall.



TomazQuake might have a couple of those chasecam fixes that nearly every engine has, but it doesn't have the DarkPlaces "never allow the camera to go through the walls fix".

I'm not so familiar with TomazQuake, I wasn't around back then, so if there is a later version I should check, let me know.
Back to top
View user's profile Send private message
MeTcHsteekle



Joined: 15 May 2008
Posts: 397
Location: its a secret

PostPosted: Sat Nov 29, 2008 11:05 pm    Post subject: Reply with quote

do u take suggestions?

if you do how bout getting rid of the need for the mesh things, the ones that make it so if there is a changed model it comes out as a blob of manged vertexes Very Happy
_________________
bah
Back to top
View user's profile Send private message AIM Address
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Sat Nov 29, 2008 11:29 pm    Post subject: Reply with quote

MeTcHsteekle wrote:
do u take suggestions?

if you do how bout getting rid of the need for the mesh things, the ones that make it so if there is a changed model it comes out as a blob of manged vertexes Very Happy


I'll write up one for that in a couple of days. I learned the process from some writeup at in the QuakeSrc.org [lost] forums.
Back to top
View user's profile Send private message
ceriux



Joined: 06 Sep 2008
Posts: 969
Location: Florida, USA

PostPosted: Sun Nov 30, 2008 7:49 pm    Post subject: Reply with quote

why not a tutorial on how to get Darkplaces servers compatible with a server window Very Happy ?
_________________
QuakeDB - Quake ModDB Group
Back to top
View user's profile Send private message Yahoo Messenger
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Mon Dec 01, 2008 8:50 am    Post subject: Reply with quote

wonder how hard it would be to implement basic csqc support...
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
MeTcHsteekle



Joined: 15 May 2008
Posts: 397
Location: its a secret

PostPosted: Mon Dec 01, 2008 10:31 am    Post subject: Reply with quote

Spike wrote:
wonder how hard it would be to implement basic csqc support...


i was gonna ask that :0
_________________
bah
Back to top
View user's profile Send private message AIM Address
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Mon Dec 01, 2008 6:35 pm    Post subject: Reply with quote

Baker wrote:
MeTcHsteekle wrote:
do u take suggestions?

if you do how bout getting rid of the need for the mesh things, the ones that make it so if there is a changed model it comes out as a blob of manged vertexes Very Happy


I'll write up one for that in a couple of days. I learned the process from some writeup at in the QuakeSrc.org [lost] forums.

Easiest one in the world. ;D

Code:
void GL_MakeAliasModelDisplayLists (model_t *m, aliashdr_t *hdr)
{
   int      i, j;
   maliasgroup_t   *paliasgroup;
   int         *cmds;
   trivertx_t   *verts;
   char   cache[MAX_QPATH], fullpath[MAX_OSPATH], *c;
   FILE   *f;
   int      len;
   byte   *data;

   aliasmodel = m;
   paliashdr = hdr;   // (aliashdr_t *)Mod_Extradata (m);

   BuildTris ();      // trifans or lists

   // save the data out

   paliashdr->poseverts = numorder;

   cmds = (int *) Hunk_Alloc (numcommands * 4);
   paliashdr->commands = (byte *)cmds - (byte *)paliashdr;
   memcpy (cmds, commands, numcommands * 4);

   verts = (trivertx_t *) Hunk_Alloc (paliashdr->numposes * paliashdr->poseverts
      * sizeof(trivertx_t) );
   paliashdr->posedata = (byte *)verts - (byte *)paliashdr;
   for (i=0 ; i<paliashdr->numposes ; i++)
      for (j=0 ; j<numorder ; j++)
         *verts++ = poseverts[i][vertexorder[j]];
}


Just remove the check-for-file/write-to-file parts and you're done.
_________________
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
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Thu Dec 04, 2008 2:05 am    Post subject: Reply with quote

A tutorial showing how to implement a reliable way in GLQuake to change screen resolution and modes on the fly. I tried copying this from some engines but it was erratic to say the least (and usually just crashed when running in older GL cards and/or with buggy drivers).
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Thu Dec 04, 2008 2:49 am    Post subject: Reply with quote

frag.machine wrote:
A tutorial showing how to implement a reliable way in GLQuake to change screen resolution and modes on the fly. I tried copying this from some engines but it was erratic to say the least (and usually just crashed when running in older GL cards and/or with buggy drivers).


Yeah, I can do that one.

I got obsessed with it earlier in the year and took FitzQuake and Qrack (which had very recently added the feature) and disassembled them.

I'll write up a tutorial on that some time within the next week.

Meanwhile, you can see the implementation of it that I've done (download | src | info).

Like FitzQuake 0.80, it will double initialize the video mode. It will load up and then after reading the config.cfg will reinitialize if the values are different. I'd like to get rid of the double initialization.

But anyways, you can press ALT-ENTER to switch from fullscreen to windowed mode and all that jazz.

When I was adding the feature, I carefully stored the before and after sources with only that single change.

You won't be able to switch bits per pixel in video options, changing the bits per pixel would require the sbar pics and the other 2d graphics to be reloaded (= extra work I haven't bothered to do yet). As a result, I have it default to the desktop bpp instead of 16 so ALT-ENTER can switch (if a user sets a bpp by command line that isn't desktop bpp, I have it disable the fullscreen <--> windowed switch).
Back to top
View user's profile Send private message
r00k



Joined: 13 Nov 2004
Posts: 483

PostPosted: Thu Dec 04, 2008 4:35 am    Post subject: Reply with quote

In my addition to adding alt-enter,
i had to implement this bit
Code:

      case WM_ACTIVATE:
         fActive = LOWORD(wParam);
         fMinimized = (BOOL) HIWORD(wParam);
         AppActivate(!(fActive == WA_INACTIVE), fMinimized);
      // fix the leftover Alt from any Alt-Tab or the like that switched us away
         Key_ClearAllStates();
         //R00k re-init the mouse after alt-tabbing please... (v1.9)
         if (!mouseactive)
         {
            IN_Shutdown ();
            IN_StartupMouse();
            IN_ActivateMouse ();
            IN_HideMouse ();
         }
         break;


Quote:

You won't be able to switch bits per pixel in video options, changing the bits per pixel would require the sbar pics and the other 2d graphics to be reloaded (= extra work I haven't bothered to do yet).

This would make a nice tutorial. Very Happy
Back to top
View user's profile Send private message
metlslime



Joined: 05 Feb 2008
Posts: 177

PostPosted: Thu Dec 04, 2008 7:02 am    Post subject: Reply with quote

If you do a tutorial, don't forget to fix the bug in fitz 0.80 video switching is that -dinput mouse dies after a restart, because the mouse has to be reinitialized.

My fix was, in VID_SetMode:

Code:
   //johnfitz -- re-initialize dinput becuase it's tied to the "mainwindow" object
   if (COM_CheckParm ("-dinput"))
      IN_InitDInput ();
   //johnfitz

Insert that right before this line:

Code:

   window_width = DIBWidth;
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming All times are GMT
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
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