Another Roundup

Keep the comments coming in; they're providing a great source of information on what does or doesn't work.  I don't always get the chance to reply directly to each, but all feedback and bug reports are definitely welcome and everything will be considered.

I've been playing a little with D3D11 instancing lately, and thinking over how it compares with both D3D9 and OpenGL.  My general opinion is that D3D's separation of vertex layout from buffer and offset specification (which is present in both 9 and 11) is superior to OpenGL, but instancing is one case where the OpenGL method is cleaner and clearer.

My current thinking is that I'm going to use an instanced path for all MDLs and Sprites.  I already have instancing written and working for sprites, but just drawing one sprite per-instance, so the batching element remains to be done.

Of course instancing has it's own overhead, but this is a balancing act.  You can switch between instanced and non-instanced drawing, but then you get the overhead of this switching to handle as well.  You also need to consider where to set the cutoff point beyond which you switch to instancing.  Keeping everything on the instanced path and hoping that the runtime and drivers handle it sensibly seems a better approach overall.

This may change of course depending on how benchmarks work out. :)

Particles are something else that may benefit from instancing, but I'm leaning more towards keeping my current geometry shader approach.  There is a certain amount of extra calculation that needs to be done per-particle, and not using a GS means that it would need to be done 4 times (once per-vertex) rather than just once.  It's worth noting that I use instancing for particles in my GL3.3 Quake II engine, but that still performs all of the gravity/velocity calculations on the CPU (DirectQ 2.0.0 does them on the GPU, which is where most of the extra calculation I mentioned comes from).  DirectQ 1.9.x and earlier also used a form of instancing for particles, but it was a bit hacky (mostly to still support SM2 hardware).

I'm removing geometry shaders from the 2D GUI stuff and from Sprites (the latter already done).  It's unfortunate that I'd let myself get so far down this route, particularly with the 2D stuff, as there is quite a job of work now involved in their removal, but it's the right decision.  The initial use of geometry shaders for these was one of those "hey, I wonder if you can do this..." moments rather than being based on sound technical reasoning.

The filesystem code is likely to make a transition to using memory-mapped files, which should result in much improved loading times.  I currently have a naive implementation of this written and working, which just creates a memory mapping, maps the file, allocates a buffer, copies the file into the buffer, then takes everything down.  It's no faster nor slower than using classic file I/O, so that's a good indication that improvements will come when I do it right.  In particular I intend leaving PAK file handles open and memory mappings active throughout the lifetime of the engine running (no, this doesn't use any additional memory; that only happens when you map a view) so a lot of extra setup and tear-down work involved in loading a file will go away.

These advantages will only apply to PAK files - PK3s are a little more complex owing to the need to go through unzipping code, and it's unrealistic to leave file handles open for raw filesystem files.

Some framerate-dependencies in some areas have been identified and removed.  Generally these occurred in cases where a delta frametime was accumulated rather than an absolute difference between current time and a start time being used.  One slightly embarrassing consequence of that was that bonus and damage flashes lasted a LOT shorter than they should have when you were running fast (and a lot longer if running slow).  All fixed now.

I'm considering removing the host_maxfps cvar.  This is just a thought that occurred to me rather than something I'm set on doing, but a lot of things would get simpler if it went away.  What would happen instead is that the engine would by default run flat-out, and various other methods of throttling framerate (if you don't want to run your GPU too fast, for example, or if you were running on battery) would be available.

These would include enabling vsync or using the new sys_sleep cvar to specify an amount of time to sleep for each frame.  I've tested both of these on a netbook and they work great, with the engine still feeling incredibly smooth and responsive (and generating next to no extra heat!)

(Aside: one of the really nice things about D3D11 is that vsync is just a parameter to the Present call, so it doesn't require a mode change to enable/disable, and can be easily and automatically switched off when you're running a timedemo.)

By contrast, host_maxfps 72 will just spin in a tight loop, so it doesn't achieve much to save on either CPU usage or battery, and has nowhere near the same smoothness.  Even vsync enabled with a refresh rate of 60 feels just as smooth as smooth as running at 1000fps.

Like I said, I'm still not totally set on this approach, so I'm open to comments and suggestions here.  Any arguments in favour of host_maxfps versus vsync and/or sys_sleep?

More later.