Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Member Since 15 Dec 2001
Offline Last Active Yesterday, 03:55 PM

Posts I've Made

In Topic: The Game Environment: Not just Graphics

16 December 2014 - 03:47 AM

I think humans are mostly visual and that. on average, our eyesight is stronger than our hearing. </speculation>

I think you'll find that's the other way around; our eye sight is pretty poor and limited - good for tracking animals to hunt and to jump between trees, pretty poor otherwise. (Fun fact; when your eyes move your brain stops processing visual data until it stabilises again - so when you look left or right as a car driver all you saw was what was in front of you when you started and where you were looking at the end, your brain made the rest up.)

In fact you'll notice audio drops/glitches much easier than you'll notice visual ones simply because your brain isn't doing as much compensation.
(As for a dog; dog's worlds are very smell directed rather than visual based thus the rabbit problem.)

Graphics are one of those things which are just easier to show off; you get screen shots and wonderful flashy trailers which look good on a 1080p screen and give you lots of Hollywood wiz-bang; where as audio setup for most people tends to suck - $10 speakers attached to an onboard sound system with the same fidelity as an ant blowing into a trumpet.

That said, audio tends to get a fair amount of processing time dedicated to it; in OFP:Red River for every graphics frame we were rendering on the console (30fps) you would see at least 5 audio frames of processing happening and eating pretty much a whole core on the X360 so audio can get a pretty good chunk of resources. (The audio guys also put a lot of work into the sound design, the J-DAM explosion sound was a thing of beauty and worked well with the particle system around it.)

As others have said, the audio design in many games is good, you just don't get it thrown in your face because it tends to be more subtle.
My favourite bit which springs to mind is the background computer chatter in Dead Space; sets the tone really well and when you focus in on it then it is damn creepy... Vampire : Bloodlines also had some pretty cool sound design, in fact I hold up the first mission proper in a haunted hotel as one of the best bits of game design I've encountered as the graphics, sound design and pacing are just spot on.

In Topic: VERY weird error. Structs in std::vector being updated more than once

15 December 2014 - 04:12 AM

Another, slightly more major idea, is to use the remove/erase idiom to deal with the removal and std::foreach to deal with
particleList.erase(std::remove_if(std::begin(particleList), std::end(particleList), [](particleType const &p) { return p->lifetime < 0.0f }), std::end(particleList));
std::for_each(std::begin(particleList), std::end(particleList), [](particleType &p) { p->y += 0.1f});

Lambdas can, of course, be replaced with other function object implementations.

In Topic: Particles: Batching VS instancing

09 December 2014 - 10:22 AM

You don't have to increase your data; you only need one XY value per particle.

In the vertex shader you take the vertex ID as an input (can't recall GLSL for this) and then use that to figure out which particle you are (int id = vertex_ID % 4), and use that to index into the UBO to get the data.

void main(int vertex_id)
int particleID = vertex_id % 4;
vec2 pos = particlePostions[particleID];

// do things...


In Topic: What if game engines were cars?

03 December 2014 - 01:15 PM

I see OP is a "free information" hippie .
Putting the "proprietary engines" in there just ruins the whole article - turns it too "political" .

Errm.. I think you are off base there...

UE4 != free.
Unity = has free edition but doesn't really give you any information..
CryEngine != free

In this case 'proprietary engine' is simply referring to engines you can't get hold of be it EA's Frostbite or Codemasters' Ego engines.

Perfectly valid term.
No hippyness required.

In Topic: OpenGL 5 - Release?

01 December 2014 - 03:23 AM

The reason for a new API, ground up ditch all the shite version, can be surmised quite simply;

Currently OpenGL, OpenGL|ES and D3D11 are the only 3 major APIs in the wild which do not support 'going wide' on their command buffer building or do not see any speed up from doing so. (3 of 9 it should be added.)

Next year OpenGL and OpenGL|ES will be the only APIs not to support this.

CPU archs are wide.
Graphics setup is naturally wide.

So, from just an ease of writing and compatibility mindset OpenGL will require a bunch of hoop jumping just to use sanely; maintaining this going forward is not helpful.