Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Jun 2010
Online Last Active Today, 02:55 AM

Posts I've Made

In Topic: Fast Way To Determine If All Pixels In Opengl Depth Buffer Were Drawn At Leas...

Today, 02:50 AM

Since you're using a Quake 3 map, the classic Quake method of solving this was to precompute a potentially visible set (or PVS) using an offline pre-processor, then do checks against that PVS at runtime to determine what should (or should not) be drawn.


In (very basic) outline, you divide your map into what I'll call "areas"; these could be nodes/leafs in a BSP tree (which was what Quake used), rooms, cubes in a grid, whatever.  Then for each such area, you use some brute-force method to determine what other areas are potentially visible from it (I believe that the "potentially" part is on account of some coarseness in the algorithm, as well as the fact that this stage ignores frustum culling which is still done at runtime).  Store out the result in some fast and compact data format (Quake used a bitfield array).  Then at runtime you're just looking up those stored results, draw calls, overdraw, etc all go down, the map runs faster, and everbody is happy.


The downside is that the pre-processing can take time, needs to be re-run even if you make trivial changes to your map, and needs a custom map format to store the data.  And while we're on the subject of formats, .obj is a horrible, horrible, horrible, horrible, horrible format to use for game maps.  The only reason to use it is if you really love writing text parsers.  The ideal format is where you memory-map a file, read some headers to set up some sizes, then glBufferData the rest.  Simple, quick to load, no faffing about.  And while we're on the subject of glBufferData, if your observation is that VBOs are slower than glBegin/glEnd, then you're using them wrong: probably by writing a glBegin/glEnd-alike wrapper around the VBO API.

In Topic: Directx 11 For Small Scale And Directx 12 For Large Scale.

Yesterday, 02:48 AM

There are plenty of large scale games made using Direct3D 11.

In Topic: Multi Vertex Buffer And Inputlayout

27 July 2016 - 03:32 PM

In D3D10+, which I assume you're using based on the API calls used, you would combine these into a single call, like so:


ID3D11Buffer *buffers[] = {vb1, vb2};

UINT strides[] = {sizeof (vertex1), sizeof (vertex2)};

UINT offsets[] = {0, 0}; // assume - may be different

context->IASetVertexBuffers (0, 2, buffers, strides, offsets);

In Topic: Vulkan is Next-Gen OpenGL

22 July 2016 - 01:13 PM

Axel Gneiting from id Software is porting Quake to Vulkan: https://twitter.com/axelgneiting/status/755988244408381443

Code: https://github.com/Novum/vkQuake


This is cool; it's going to be a really nice working example and we'll be able to see exactly how each block of modern Vulkan code relates to the original cruddy old legacy OpenGL 1.1 code.

In Topic: Your Preferred Os And Why

22 July 2016 - 08:00 AM

Also, I work better with multiple desktops, and last time I checked, Windows didn't have them.


10 has them; check again.


This is actually a major fault that one sometimes sees in Linux-land; people don't keep up to date with the capabilities of Windows and as a result make statements about it that might not have been true for some time.  I recall another example from elsewhere where somebody claimed that Windows, in 2002/2003, still used co-operative multitasking.