Doom 3 engine release and game code

[revelator]

Not unless ttimo applied those my source is based on his.
Checking non the less would be dumb not to.

[revelator]

Checking yup he applied it :S thanks for the fix.

Now you mentioned it i noticed that some models went black but i suspected myself bugging up some materials somewhere. im happy to know that i was not.

[revelator]

Hmm nice weapon ase models now look really good dunno if a side effect but it sure is visible.

[mh]

Another bugfix. On Windows 7 at least, when running in a windowed mode the cursor can occasionally wander outside of the screen area. In IN_ActivateMouse put this above the win32.mousegrabbed = true line:

Code: Select all

   RECT mouserect;

   // constrain mouse movement to the correct window rect
   GetClientRect (win32.hWnd, &mouserect);

   // sometimes if the mouse wanders to the edge of the rect it can go outside in the time between messages so shrink the rect a little to fix that
   mouserect.left += 5;
   mouserect.right -= 5;
   mouserect.top += 5;
   mouserect.bottom -= 5;

   // this nasty hack works because of the struct layouts
   ClientToScreen (win32.hWnd, (POINT *) &mouserect.left);
   ClientToScreen (win32.hWnd, (POINT *) &mouserect.right);

   ClipCursor (&mouserect);

   // ensure that the cursor stays within the client region (directinput will look after the rest)
   SetCursorPos (mouserect.left + ((mouserect.right - mouserect.left) >> 1), mouserect.top + ((mouserect.bottom - mouserect.top) >> 1));

And this in IN_DeactivateMouse (just above the win32.mousegrabbed = false line):

Code: Select all

   ClipCursor (NULL);

[motorsep]

Are those two bug fixes just for GLSL part or for vanilla Doom 3 ?

[mh]

It's mouse input, it's got nothing to do with GLSL.

[motorsep]

I figured that about mouse but this one I am also referring to:

BUG ALERT!

If you've seen this page: http://www.viva64.com/en/b/0151/#ID0EMEBK you may have implemented some of the fixes in it. There's a further bug in fragment 10: if you just do the obvious and use "memset (ase.currentMesh, 0, sizeof (*ase.currentMesh));" - you'll wipe the transforms and - as these apply to normals - you're going to end up with some models appearing all or mostly black in the game - the little blue/white boxes in many maps, and the floating platforms in Central Processing are two examples.

Suggest something like this instead:

Code: Select all

      ase.currentMesh = &ase.currentObject->mesh;

      // the transform is applied to normals so it must be saved out before we clear the mesh
      idVec3 transform[4];

      transform[0] = ase.currentMesh->transform[0];
      transform[1] = ase.currentMesh->transform[1];
      transform[2] = ase.currentMesh->transform[2];
      transform[3] = ase.currentMesh->transform[3];

      // and now it's safe to clear
      memset (ase.currentMesh, 0, sizeof (*ase.currentMesh));

      // and now we restore the saved out transform
      ase.currentMesh->transform[0] = transform[0];
      ase.currentMesh->transform[1] = transform[1];
      ase.currentMesh->transform[2] = transform[2];
      ase.currentMesh->transform[3] = transform[3];

      ASE_ParseBracedBlock (ASE_KeyMESH);

[mh]

That one applies globally; standard ARB2 as well. Not sure about ARB, but it should also apply to NV10/NV20/R200 as well.

[revelator]

Nice find MH thank you.

[revelator]

btw reverted the vsync stutter fix from jkriege as it makes the game go in slowmotion when fps < 60.
code needs a lookover but else i like the idea.

[revelator]

Atm taking a break but i hope someone picks up and add's newer or better engine code (im also interrested in helping with that).
Things that could use some updates of the top of my head.

jpeg code uses the now ancient jpeg6 source. It would be better to use the much more recent jpeg8 standard.
zlib code also ancient and contains security bugs.
curl ditto.
tga while it certainly works fine with the tga1 version it would probably be better to use the newer tga2 code (implemented in joequake as well as a few others i know of) supports many more types than the tga1 version and doesnt choke on topside down tga images.

defered renderer (must keep compatibility with doom3).
glsl some work allready done.
newer extentions (read up on ARB2 and it seems we got some stuff wrong ARB2 in later incarnations is capable of doing most of what glsl is "most of is litteral" i have this from SGI)
the problem is engine side as doom3 does not have the engine side interfaces for using stuff like ssao etc.
Support for larger outdoor areas (doom3 does an ok job when using megatexture but it does have its limitations and the megatexture version in doom3 is very old so updating it would certainly go along way).

While not perfect as many of the shaders use workarounds for missing interfaces sikk has shown that the doom3 engine can indeed be made to look like an engine for 2012 and with some work even further.

[motorsep]

I don't mean to be a party pooper, but here is OpenGL / OpenGL ES 2.0 port in active development https://github.com/omcfadde/dante

[toneddu2000]

I've to admit it: the idea to swicth from dp to doom 3 for my project is tickling me a lot! but I can't really understand now what's the future of doom 3 modified code. The link you posted, motorsep: is that version capable of accepting GLSL shaders instead of ARB ones?
It's very difficult for a non coder to find a way in this labyrinth of modified engines!

[revelator]

As posted above newer versions of opengl's ARB shader interfaces can do allmost anything the glsl interface can.
There are ofc edge cases but then its just a matter of implementing an interface for those in the idtech4 source.
I suspect the code could be speed up quite a lot by rewriting parts to do batch processing hmm.
Also add newer SSE interfaces for current gen CPU's might give some extra on modern PC's though i doubt it would bring much on platforms with opengl ES.

[motorsep]

OpenGL ES is the same as OpenGL + it runs on iOS and Android. That's what I've been told by the author. I don't get how ARB interface can be newer since it was not touched since GLSL came to be.

@toneddu2000: You don't need to be a programmer to figure out what fork to use based on maturity of the fork and features it offers If you go for Windows, stick with TTimo's branch. If you need to run your game and other platforms, and you are willing to give up original tools - use dhewm3 as it has SDL, 64bit, OpenAL and is cross platform (but totally incompatible with Doom 3 mods)