Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Future Tutorial Ideas ... Goto page 1, 2, 3, 4 Next

| Inside3d Forums Forum Index -> Engine Programming

View previous topic :: View next topic
Author | Message
--- | ---
Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Sun Nov 23, 2008 3:32 am Post subject: Future Tutorial Ideas ... |

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

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Fri Nov 28, 2008 7:53 am Post subject: |

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 |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Fri Nov 28, 2008 4:56 pm Post subject: Re: Future Tutorial Ideas ... |

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 |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Fri Nov 28, 2008 6:17 pm Post subject: |

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 |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Fri Nov 28, 2008 6:48 pm Post subject: |

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 |

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

Posted: Sat Nov 29, 2008 11:05 pm Post subject: |

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 _________________ bah

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Sat Nov 29, 2008 11:29 pm Post subject: |

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

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 |

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

Posted: Sun Nov 30, 2008 7:49 pm Post subject: |

why not a tutorial on how to get Darkplaces servers compatible with a server window ? _________________ QuakeDB - Quake ModDB Group

Back to top |

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

Posted: Mon Dec 01, 2008 8:50 am Post subject: |

wonder how hard it would be to implement basic csqc support... _________________ What's a signature?

Back to top |

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

Posted: Mon Dec 01, 2008 10:31 am Post subject: |

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

i was gonna ask that :0
_________________
bah

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Mon Dec 01, 2008 6:35 pm Post subject: |

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

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 |

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

Posted: Thu Dec 04, 2008 2:05 am Post subject: |

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 |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Thu Dec 04, 2008 2:49 am Post subject: |

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 |

r00k Joined: 13 Nov 2004 Posts: 483 |

Posted: Thu Dec 04, 2008 4:35 am Post subject: |

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.

Back to top |

metlslime Joined: 05 Feb 2008 Posts: 177 |

Posted: Thu Dec 04, 2008 7:02 am Post subject: |

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 |

Display posts from previous:

| 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