Doom 3 engine release and game code

[Sikkpin]

Heh i just found Doom3's breaking point for model texture sizes its 1024x1024 for a card with 1 gig texture mem. Going above that will crash both doom3 and the driver ouch.

Are you sure? I have no problem loading 2k x 2k textures (diffuse + normal + spec) for a model.

[revelator]

Raised limits the problem was loading textures above a certain size.

Not sure why my driver refuses to load anything above that but it does and quite heavy handed to since it crashes the driver.
How much Vram do you have sikkpin ?.

Bit strange also since some textures load fine even upto 4096x4096 in textures but it chokes on models :S

[revelator]

Trying to use some code posted by justin marshall but its not working correctly.
Bit of a bummer as it was intended to speed up the renderer a bit :S

Problem is it uses a pointer to idinteractions instead of allocating the chain statically but im running into a roadblock because the pointer returns NULL on empty chains.
I wonder if ID did as they did because of this ?.

heres the patch if someone may have a comment.

Code: Select all

Index: neo/framework/BuildDefines.h
===================================================================
--- neo/framework/BuildDefines.h   (revision 39)
+++ neo/framework/BuildDefines.h   (working copy)
@@ -133,3 +133,5 @@
 #   endif
 #endif
 
+
+#define USE_JUSTINS_SURFACES_OPT
\ No newline at end of file
Index: neo/renderer/Interaction.cpp
===================================================================
--- neo/renderer/Interaction.cpp   (revision 39)
+++ neo/renderer/Interaction.cpp   (working copy)
@@ -539,7 +539,9 @@
          R_FreeInteractionCullInfo( sint->cullInfo );
       }
 
+#ifndef USE_JUSTINS_SURFACES_OPT
       R_StaticFree( this->surfaces );
+#endif
       this->surfaces = NULL;
    }
    this->numSurfaces = -1;
@@ -846,11 +848,17 @@
       shadowGen = SG_STATIC;
    }
 
+
    //
    // create slots for each of the model's surfaces
    //
    numSurfaces = model->NumSurfaces();
+#ifdef USE_JUSTINS_SURFACES_OPT
+   surfaces = (surfaceInteraction_t *)model->GetSurfaceInteractions();
+   memset(&surfaces[0], 0, sizeof(surfaceInteraction_t) * model->NumSurfaces());
+#else
    surfaces = (surfaceInteraction_t *)R_ClearedStaticAlloc( sizeof( *surfaces ) * numSurfaces );
+#endif
 
    interactionGenerated = false;
 
Index: neo/renderer/Interaction.h
===================================================================
--- neo/renderer/Interaction.h   (revision 39)
+++ neo/renderer/Interaction.h   (working copy)
@@ -61,7 +61,7 @@
 } srfCullInfo_t;
 
 
-typedef struct {      
+typedef struct surfaceInteraction_s {      
    // if lightTris == LIGHT_TRIS_DEFERRED, then the calculation of the
    // lightTris has been deferred, and must be done if ambientTris is visible
    srfTriangles_t *      lightTris;
Index: neo/renderer/Model.cpp
===================================================================
--- neo/renderer/Model.cpp   (revision 39)
+++ neo/renderer/Model.cpp   (working copy)
@@ -357,6 +357,10 @@
    if ( surface.geometry ) {
       bounds += surface.geometry->bounds;
    }
+
+#ifdef USE_JUSTINS_SURFACES_OPT
+   interaction.Alloc();
+#endif
 }
 
 /*
@@ -2117,10 +2121,37 @@
    }
    surfaces.Clear();
 
+#ifdef USE_JUSTINS_SURFACES_OPT
+   interaction.Clear();
+#endif
+
    purged = true;
 }
 
+
+#ifdef USE_JUSTINS_SURFACES_OPT
 /*
+================
+idRenderModelStatic::GetSurfaceInteractions
+================
+*/
+const surfaceInteraction_s *idRenderModelStatic::GetSurfaceInteractions( void ) const
+{
+   return interaction.Ptr();
+}
+
+/*
+================
+idRenderModelStatic::AllocInteraction
+================
+*/
+void idRenderModelStatic::AllocInteraction( void )
+{
+   interaction.Alloc();
+}
+#endif
+
+/*
 ==============
 idRenderModelStatic::FreeVertexCache
 
@@ -2145,6 +2176,7 @@
    }
 }
 
+
 /*
 ================
 idRenderModelStatic::ReadFromDemoFile
Index: neo/renderer/Model.h
===================================================================
--- neo/renderer/Model.h   (revision 39)
+++ neo/renderer/Model.h   (working copy)
@@ -58,7 +58,6 @@
 
 #endif
 
-
 typedef struct {
    // NOTE: making this a glIndex is dubious, as there can be 2x the faces as verts
    glIndex_t               p1, p2;               // planes defining the edge
@@ -168,6 +167,10 @@
 // the init methods may be called again on an already created model when
 // a reloadModels is issued
 
+#ifdef USE_JUSTINS_SURFACES_OPT
+struct surfaceInteraction_s;
+#endif
+
 class idRenderModel {
 public:
    virtual                  ~idRenderModel() {};
@@ -309,6 +312,12 @@
    // Writing to and reading from a demo file.
    virtual void            ReadFromDemoFile( class idDemoFile *f ) = 0;
    virtual void            WriteToDemoFile( class idDemoFile *f ) = 0;
+
+#ifdef USE_JUSTINS_SURFACES_OPT
+   // Gets the surface interactions
+   virtual const surfaceInteraction_s *GetSurfaceInteractions( void ) const = 0;
+#endif
 };
 
+
 #endif /* !__MODEL_H__ */
Index: neo/renderer/Model_local.h
===================================================================
--- neo/renderer/Model_local.h   (revision 39)
+++ neo/renderer/Model_local.h   (working copy)
@@ -107,6 +107,11 @@
    idBounds               bounds;
    int                     overlaysAdded;
 
+#ifdef USE_JUSTINS_SURFACES_OPT
+   virtual void AllocInteraction( void );
+   virtual const surfaceInteraction_s *GetSurfaceInteractions( void ) const;
+#endif
+
 protected:
    int                     lastModifiedFrame;
    int                     lastArchivedFrame;
@@ -125,6 +130,10 @@
    static idCVar            r_slopVertex;         // merge xyz coordinates this far apart
    static idCVar            r_slopTexCoord;         // merge texture coordinates this far apart
    static idCVar            r_slopNormal;         // merge normals that dot less than this
+
+#ifdef USE_JUSTINS_SURFACES_OPT
+   idList<surfaceInteraction_s> interaction;
+#endif
 };
 
 /*
Index: neo/renderer/Model_md5.cpp
===================================================================
--- neo/renderer/Model_md5.cpp   (revision 39)
+++ neo/renderer/Model_md5.cpp   (working copy)
@@ -794,6 +794,10 @@
          // Remove Overlays before adding new surfaces
          idRenderModelOverlay::RemoveOverlaySurfacesFromModel( staticModel );
 
+#ifdef USE_JUSTINS_SURFACES_OPT
+         staticModel->AllocInteraction();
+#endif
+
          mesh->surfaceNum = staticModel->NumSurfaces();
          surf = &staticModel->surfaces.Alloc();
          surf->geometry = NULL;


[Spiney]

I experimented with huge textures once, game didn't crash but the swapping in and out of textures into video memory caused noticeable hitches.

[revelator]

Yip also get that from time to time its pretty annoying but my best guess it wont get better untill we have a deffered renderer.
The above patch should also help some if it worked :`(

[mh]

A deferred renderer might help some with the lighting (although it would look very different as a lot of Doom 3's lighting is dependent on projected and falloff textures rather than just using a standard attenuation formula), but it wouldn't be able to handle shadows.

[motorsep]

Can someone please help me to re-enable tools for Windows build in Dhewm3 fork?

[revelator]

look in builddefines.h unless he removed the whole deal the defines for turning on the tools are in there

[revelator]

@Mh true i wonder if the idea of loading textures like discussed in another thread´might be worth it for Doom3.
As i progressed i also noticed that the textures tile very badly most notably with high res ones, maybe a bug ? its very visible on brick textures when looked at from an angle you can see the seems ;S

[motorsep]

He has it there:

#if defined( _WIN32 ) && defined(_MFC_VER) && !defined( ID_DEDICATED )
#define ID_ALLOW_TOOLS
#endif

However, when cmake creates project files and solution for VS2010, there is no trace of the resources, headers and cpp files of the tools in it. Being Linux adept, dhewm3 author despises Microsoft and completely ripped out tools from his fork recently. It's stupid, I know :/ The only way to make his fork suitable for modding is to make tools to be included when cmake generates VS project file and have it compiling under Windows.

[mh]

There are other reasons for removing them besides hating Microsoft. The main one is that they're heavily dependent on MFC, and MFC cannot be used with Visual C++ Express. So if you want to compile the project, and if you don't want to fork out Big Money on a non-Express edition (or can't get one elsewhere), then you're screwed. Secondary reasons are that they bloat the executable (debug builds come in at 30mb) and give compile times that can be measured in epochs. For any kind of serious engine work a fast compile time is utterly essential, otherwise the turnaround time for compile/test iterations is stupid.

For modding you don't need a forked engine build anyway; you can just use the original. There's no benefit to having a modified engine if the tools code is just going to be the very same as it always was. It's also sensible to mod on the original engine so that you can be more certain of your work working with everything. So this is a total non-issue.

[motorsep]

Well, for once dhewm3 debug builds are already 30+ Mb

If we would be able to have tools in dhewm3, I would buy MSVC before we release the game. It's so much better for users to have native tools and be able to work with lights / sounds / etc. in-game vs doing that in notepad and DarkRadiant. Plus AF editor doesn't exist outside of idTech 4.

What's the point of going stand-alone if even a free standalone game will require users to buy Doom 3 to use foll set of tools for modding. Also dhewm3 is 100% incompatible with Doom 3's game libs and _all_ of the mods for Doom 3 (unless those are recompiled against dhewm3).

[WickedShell]

I sorta sit back and read every, but this is something others may appreciate, benefit from, and provide critique upon...

Doom3 uses a weird timing mechanism under Linux, and according to the comment it was to allow for poor performance of the Linux 2.4 scheduler, but the work around results in much worse performance now. Doom3's frame timing under linux was to partition a second into 60 discrete steps, and try and run a frame every step, if you miss one because you took to long, it took the approach that it was best to sleep and wait for the next one, so missing one step would result in skipping to the next time unit, and then making up the number of missed common->Async() and trigger eents (or as many as had been missed) to catch up. This results in framerate stutters as you can suddenly drop down to 30 fps, and generally made doom3 very unpleasant to play for me as it was stuttering around. This is essentially behaved like having your code synced to a second v-sync, where if you miss a frame/timing your framerate halves until you can get back to meeting the sync signal.

The patch below instead determines how long it took to do async and trigger events, and sleeps the remaining time left so that (if the scheduler is cooperating) it will come out of sleep exactly a 60th of a second later. Where the patch changes behavior however, is that if a frame took longer then a 60th of a second it will immediately go around and begins the next round, rather then sleeping. The 60FPS limit still stands with this approach, however the advantage is that a single frame being long no longer induces a stutter. The patch preserves running extra async events directly to catch up in place.

Anywho this patch lets me go from periodically stuttering to 30 fps, to a constant smooth pegged 60, which eliminates my biggest problem with doom3 (A 6 core 3.6Ghz, with an overclocked AMD6970 graphics card clearly should not be having issues maintaining 60FPS)

Code: Select all

    diff --git a/neo/sys/linux/main.cpp b/neo/sys/linux/main.cpp
    index 4e64b8a..3134b33 100644
    --- a/neo/sys/linux/main.cpp
    +++ b/neo/sys/linux/main.cpp
    @@ -60,22 +60,16 @@ Sys_AsyncThread
     */
     void Sys_AsyncThread( void ) {
            int now;
    -       int next;
    -       int     want_sleep;
    +       int start;
    +       int elapsed;
     
    -       // multi tick compensate for poor schedulers (Linux 2.4)
            int ticked, to_ticked;
            now = Sys_Milliseconds();
            ticked = now >> 4;
            while (1) {
                    // sleep
    -               now = Sys_Milliseconds();             
    -               next = ( now & 0xFFFFFFF0 ) + 0x10;
    -               want_sleep = ( next-now-1 ) * 1000;
    -               if ( want_sleep > 0 ) {
    -                       usleep( want_sleep ); // sleep 1ms less than true target
    -               }
    -             
    +               start = Sys_Milliseconds();
    +
                    // compensate if we slept too long
                    now = Sys_Milliseconds();
                    to_ticked = now >> 4;
    @@ -106,8 +100,13 @@ void Sys_AsyncThread( void ) {
                            ticked++;
                            Sys_TriggerEvent( TRIGGER_EVENT_ONE );
                    }
    +
                    // thread exit
                    pthread_testcancel();
    +
    +               elapsed = Sys_Milliseconds() - start;
    +               if(elapsed < 0x10)
    +                       usleep(0x10 - elapsed);
            }
     }


Any remarks/criticisms are definitely welcome.

[motorsep]

I heard about that issue before, but I run Doom 3 on Linux at 60+ fps with _way_ weaker hardware. I am gonna give it a spin and see if it will run at 100+ fps

[WickedShell]

That's not gonna get you to 100... It preserves the 60FPS cap.

I can time demo at 180+ FPS, but I would still randomly drop down when actually playing, (and showed even less less cpu usage when playing). This is only going to help you under Linux, I haven’t looked at any of the other platform specific code.