Jump to content

  • Log In with Google      Sign In   
  • Create Account

mark ds

Member Since 07 Jan 2010
Offline Last Active Today, 07:05 PM

Topics I've Started

timeBeginPeriod under Windows 8.1 is always 15ms using GetTickCount?

07 December 2013 - 09:25 AM

I was playing around with some code earlier, and I noticed that whatever value I use for timeBeginPeriod, the OS seems to ignore it, and always use 15ms increments for GetTickCount, but honours it for timeGetTime. Under Windows 7, timeBeginPeriod applied to both GetTickCount and timeGetTime


It's *probably* the same using Win8, but I can't test it.


Can anyone else confirm this behaviour?

Self-shadowing terrain idea - asking for feedback

24 September 2013 - 10:07 AM

I've been wrestling for some time on how to produce decent quality, self-shadowing terrain that effectively shadows all other objects in the world. A couple of days ago I had an idea.


For any given point on the terrain, the direct sunlight contribution can be calculated thus:


While the sun is below the horizon or behind occluders (hill, mountains etc.) it's contribution is 0. We can describe this as a function of time - between 9pm and 10am, for example, a point of the terrain is NOT lit by the sun.


While the sun is fully visible it's contribution is 1. The can happen at between say 10.30am and 8.30pm.


The in between times (as the sun appears over distant peaks) would essentially represent the penumbra period - where we could interpolate, based on time of day, a contribution factor between 0 and 1.


However, whilst the above would work well for the ground, no information would be available to correctly light buildings or other objects.


So my idea is to represent sun light using two height values per point on the terrain (probably per vertex in a heightmap). The first value is the height at which the sun begins to fully light a point above the terrain, and the second value the point below which no sunlight has an effect (the first value would always be higher than the second).


So a fragment shader would effectively be:


if fragment is above first value, sunlight contribution = 1;

else if fragment is below second value, sunlight contribution = 0

else interpolate between the two.


This contribution would be included in a g-buffer (after a depth only pass).


The sun changes position slowly over time, so I think it's perfectly possible to recalculate new values by dealing with a fairly small sector of the 'sunlightmap' each frame and storing the results in a 16-bit RG texture.


I haven't really fleshed out this idea, but I thought I'd throw it out there and hopefully get some feedback.







Events+WaitForMultipleObjects vs IO completion ports?

10 July 2012 - 09:33 AM

I'm frustum culling terrain using a quad tree, which is an obvious candidate for multithreading. In my case, I'm using a precalculated PVS pre-sorted front to back. I'm looking to chop up the PVS and multithread the culling.

Would using completion ports be advantageous over events and wait functions, performance wise? There seems to be mixed opinions on this, with many saying that the maximum number of events being the only downside, which isn't relevant to this example.

Another possibility would be to use PostThreadMessage, though that would probably (?) be least efficient.


DirectX and Win32...worth bothering with?

05 July 2012 - 02:03 PM

Like everyone else, I'm making a game (or trying to!). I'm a fairly strong Win32 programmer, but new to games - although I do have experience with OpenGL 2.1, this is very much a learning curve, and done purely for my own entertainment. Part of the reason I'm doing this is to familiarise myself with modern OpenGL. But, I fully intend to make a Direct3D port too.

Then it dawned on me - is it really worth bothering with D3D on Win32 for a non-commercial endeavour?

With WinRT coming out with Windows 8, which can be used to create both Metro and desktop apps, wouldn't it make more sense to wait and create a WinRT port, rather than Win32?

Also, what's the betting the 'XBox 720', or whatever it will be called, will use WinRT natively - enabling a single development approach to ALL Microsoft platforms?

Any thoughts?

raw input vs getkeyboardstate in windows

13 June 2012 - 07:11 PM

Hello, this is a really simple question (win32 based)

Is their any real reason why one shouldn't use GetKeyboardState, as opposed to the raw input API?

I accept that for a single key GetAsyncKeyState is the better choice. But for 20 odd keys, which is the norm?