Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 15 Dec 2001
Offline Last Active Private

#5200700 Multi-threading for performance gains

Posted by phantom on 29 December 2014 - 07:14 PM

I'm not sure I buy the latency argument, not when your suggested solution is 'push messages to another thread and have that do some work to kick the read and wait on the result'; the latency difference is unlikely to be all that critical in a game situation anyway when dealing with disk IO which is already pretty high latency.

The solution I came up with, and we are talking a good 3 or 4 years back now so I don't have the code to hand (largely because I'm away from my PC) involved the FileRead family of functions (probably FileReadEx, but I'm not 100% on that).

The code involved was very short, in the order of 10 or 20 lines maybe?, and if memory serves was a case of;
- TTB Task requests chunk of memory to load into and uses FileReadEx to start the async read and record the handle.
- Handles were collected up
- IO check task was used to check the state of the handles (WaitForMultipleObject series, immediate time out)
- For all completed file handles; push tasks into completed task queue for execution

As it was a proof-of-concept it basically only looped on point 3 until all the files were done.

The code really couldn't have been any simpler if I had tried, the most complex bit was setting up the file IO as I seem the recall the docs being a little less than clear at the time; heck that was probably the biggest segment of code in the whole test.

I'd be VERY surprised if you could write something with a lower bug count than that (only likely bugs are going to be post-hand-off in the decoding stage or whatever; memory was owned by a data structure which got passed about so it wasn't like it leaked or anything, was a direct in place load) and I'd be really surprised if the latency was anything to write home about considering that I've got one task on one thread polling at most once a frame.

If I remember I'll try to dig the code up when I get back home, although that's likely only going to happen if this thread is still on the front page as I'm going to be destroying by brain probably 3 more times before I get back to my PC where the code might still live...

#5200473 Is Unity good for learning?

Posted by phantom on 28 December 2014 - 06:58 PM

UDK isn't really a Thing any more; it is no longer being updated.

Instead if you are interested in getting hold of the Unreal Engine to use then you should be looking at UE4 at http://www.unrealengine.com.

#5199921 When to set animations?

Posted by phantom on 24 December 2014 - 08:47 PM

FPS movement would need is_attacking, is_blocking, walk/run/sprint, is_jumping, direction of movement, is_crouching, etc. easier to just fire off the correct ani when you know what ani to play.

Welcome to the world of N-way blending and animation channels.

With a good animation system there should be no conflict and no problems; want to run while drawing a knife? Apply both animations and have your animation system take care of how they are applied; running would apply to legs and arms unless another animation is being applied to the arms which overrides it; in this case the draw knife animation.

While this isn't an easy problem to solve the problem has been largely dealt with already in I'd have said all major engines by now.

#5199702 Is this correct sRGB conversion?

Posted by phantom on 23 December 2014 - 07:41 AM

... all offscreen buffers as non-sRGB ...
... all internal (offscreen buffer) blending will be done linearly...

Unless those offscreen buffers are high precision (R10G10B10A2, float 16 or float 32) then you really don't want to do that; anything which contains diffuse colour information needs to be sRGB encoded when going to RGB8 formats or you'll lose the high end information. (You could do it yourself with a crazy pow2 style thing but the hardware will do it for free and correctly.)

Unless you are on DX9 hardware then you don't have to worry about blending either since DX10-class hardware the blending units all blend in linear space correctly having first converted from sRGB if needed.

So, the practical upshot is, unless you have a higher precision colour buffer just set it to sRGB and let the hardware Do The Right Thing these days.

#5198489 The Game Environment: Not just Graphics

Posted by phantom on 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.

#5198277 VERY weird error. Structs in std::vector being updated more than once

Posted by phantom on 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.

#5197193 Particles: Batching VS instancing

Posted by phantom on 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...


#5195659 OpenGL 5 - Release?

Posted by phantom on 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.

#5195191 OpenGL 5 - Release?

Posted by phantom on 28 November 2014 - 08:24 AM

Wow, for a moderator you are a real ******* (I know I am risking getting banned here, who cares with such a community).

Yep, and I'm ok with it...
(and judging a whole community on one person? really? drama much?)

Also that reply wasn't direct just at you, however I missed an 's' which is why you could take it as such.

Either way I stand by it because frankly I'm bored of the constant 'MS are evil/bad/whatever' narrative which continues to run rampant (in general, not just with GL) and if someone is willing to buy into that without either doing the research or asking a question before putting forward a strong opinion then, well, you'll get such a reply from me.

And as you are apparently new around here; there is an unofficial agreement in place that if a moderator takes part in a thread they will not moderate in that thread, certainly not for things involving them, which is something I've stuck by - if you have a problem with that post, or indeed any post, feel free to report it I won't stop you or act on it and if anyone else in the mod team has a problem with my conduct then they will say something and if needs be I'll give up the position.

#5195145 OpenGL 5 - Release?

Posted by phantom on 28 November 2014 - 05:25 AM

Oh for the love of pete...

Dear Microsoft Conspiracy Theorists,

This is not the 90s or early 200s.
Microsoft have had nothing do with OpenGL since they left the ARB in March 2003 - 11 years ago.
Since then NV, ATI, AMD, Intel and others managed to successfully blunder the development of OpenGL on the desktop platform on their own.
MS don't need to sabotage OpenGL because the ARB and the Khronos board made up of ARB members managed to royally screw that up on their own - D3D won the battle some time ago.

The ONLY thing MS are involved in is their recent sign up to the WebGL group because they are implementing it (as everyone asked them to do...).

Please... just... learn some history and update your mental model... because... well... ugh...

#5195131 OpenGL 5 - Release?

Posted by phantom on 28 November 2014 - 03:03 AM

The more realistic scenario is something more like another bunch of extensions to add to the current mess, and we end up waiting 2/3/4/5 years for Intel and AMD to fully implement them in their drivers.

I guess it all comes down to how serious they were about 'brand new API' in the slides.

My bet on the path would be that next year you get a shiny spec for OpenGL|NG and maybe some implementation but likely not until Siggraph (as that tends to be when OpenGL stuff is announced) along side an OpenGL4.6 spec which adds a bunch of new extensions for many of the things but not all of them.

The thing is the worry about 'backwards compatibility' isn't really a big one; every time DX changes tools get rewritten, games get rewritten, people are willing to take the pain IFF the gains are worth it (thus lack of D3D10 adoption) - game devs have spent some time yelling about this and when Mantle appeared went 'yes... this!' and where heavily critical of the OpenGL approach of 'look, these extensions mean we don't need a new API!' hand waving we got for about a year (until suddenly a new API was a good idea..).

If they haven't learnt from it then OpenGL will remain the ugly child left out in the cold once more, only used when we are forced to.

(And while everyone loves to yell about cross platform compatibility lets not forget that Mobile is the only place OpenGL, in the form of OpenGL|ES, has any real weight. D3D gets you Windows, Windows Phone and Xbox, PS4 uses it's own API, iOS has Metal, WiiU has it's own API and Linux and OSX are still showing very low market shares still for desktop - and OpenGL|ES also suffers the overhead problem (along with general Android cluster-fuckery) - so if they screw up it'll be a screw up which will be largely ignored in the AAA space in favour of the better APIs anyway until we are forced to deal with it, and I personally wouldn't count on seeing OpenGL|NG in whatever form it takes on Android until maybe 2016 or 2017 anyway so...)

#5195015 OpenGL 5 - Release?

Posted by phantom on 27 November 2014 - 12:35 PM

Take in mind it is most likely GL NG will be just GL4.5 without any legacy cruft, with a unified shader compiler or IL, plus some ideas taken from the Mantle API like being multithread friendly, explicit access of DMA engines, and being multi-GPU and multi-monitor aware.

I don't think it will... or rather if it is then I'll slap a bit Failed sign on the API and move on with my life.
OpenGL, as it stands, does not reflect the GPU and just 'dropping the cruft' does not get you the performance you need.

Mantle is a simple API, from someone doing a dump of the entry points it has around 40 entry points, that is it.

OpenGL NG needs to look more like the proposed Mantle/D3D12 model than the current OpenGL model; 'cutting the cruft' isn't going to cut it this time around.

#5195013 UDK 4 vs Unity - Which is better and easier to use to make a first person act...

Posted by phantom on 27 November 2014 - 12:23 PM

*puts on Epic Employee hat*

The last few % in graphical glitz might cost you some $, but as long as you shop smart, its below 100$.... which you also will have to pay over the lifetime of your UE4 usage for upgrades.

Of course those upgrades includes a LOT of stuff; as I said before every 6 weeks or so we are kicking out updates which include performance fixes and new features (a some sizable list of them at that, via community feedback) not just graphical glitz - as to if people think this is worth while or not is another matter but trying to say that a 'few asset store things' is the same as 4 or 5 months of updates is a little misleading imo (more so considering the higher base set you get for your $20 - which can be a one off payment - than the free unity stuff).

#5194822 UDK 4 vs Unity - Which is better and easier to use to make a first person act...

Posted by phantom on 26 November 2014 - 02:04 PM

*puts on Epic Employee hat*

Unreal still requires 5% royalties on gross sales, but the price per seat for developers (considering the feature set) is bound to attract some attention from the indie scene.

Just to clear up A Thing.
The royalties are on a per-quarter amount and you only pay after the first $3,000 (gross) made in that quarter.
In theory this means that you could make $2,999/quarter and not have to pay Epic a dime. If you factor in the 30% cut many places take then you can make $2099.30/quarter before the 5% kicks in and then it is only 5% over the $3,000.

Reading the FAQ it seems to imply that it is per-product, so in theory you could have 4 games out, all pulling in less than $3,000/quarter each so you end up with just over $10K/quarter net income and don't have to pay Epic a dime.
(I'd double check that of course but that's what I read when it says 'per product')

For $20.

(Although personally I'd say if you can afford to keep the subscription do so; we push out updates pretty quickly with release 4.6 due soon and release 4.7 work well under way and there are hot fixes which go out too - plus who doesn't want to follow master and see every live commit? ;))

#5193426 is there a better way top refer to assets in a game?

Posted by phantom on 18 November 2014 - 07:30 AM

if i'm drawing 16,000 non-instanced meshes, i don't want to be looking up the array index for the mesh filename of each one.

Well, no... even if you weren't doing 'data driven' you'd still pre-cache the index on creation because doing it every draw would be dumb dumb dumb - if you are looking up data which can not change every frame on every frame then you are Doing It Wrong regardless of if you are doing the look up via text, id or lasers bounced off the moon.

Also 16,000 draw calls is going to crash your framerate so you've already got problems...