Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Dec 2001
Offline Last Active Private

#5050727 Advanced Particle Engine

Posted by on 06 April 2013 - 07:29 PM

Games tend to have some form of 'particle editor' which allows you to setup various parameters (which might change in a linear fashion or on a curve of some sort) for emitters and then those emitters would be combined together for an 'effect' of some sort.

So a fire + smoke effect might be made up for 3 emitters (fire, smoke, embers) all with varying parameters.

#5049883 Expert question: How to get a better time delta?

Posted by on 04 April 2013 - 04:38 AM

But even at these extremes, it was still hard to tell what was wrong -- it just didn't feel like a 60Hz game (although Fraps will tell you it's rendering at 60Hz). It's only when I record a video of the game at 60Hz and then step through the video frame by frame that it's obvious that every 3rd frame is a duplicate of the one before it.

For various reasons I wouldn't really trust fraps to be telling you the whole truth of what is going on anyway; http://anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps

#5046170 Setting the same texture multiple times - overhead ?

Posted by on 24 March 2013 - 04:11 AM

It is highly likely that the driver will detect this and no actual sampler binding will take place; in fact this is so basic that re-binding a texture will likely cost close to nothing.

It might not cost you GPU time but it WILL cost you CPU time; due to a lack of redundant state checking on texture bindings for a while on our last game (which was targeting 60fps...) we were losing a lot of CPU time each frame due to repeatedly setting the same texture and taking a trip into the driver.
(We, of course, fixed this... and by 'we' I mean 'me'... ;))

Doing redundant work and hoping the driver will 'sort it out' isn't a good plan at all.

#5044538 Should a game engine support "general" file formats at runtime?

Posted by on 19 March 2013 - 05:49 AM

A resounding no here as well.

The effort you put into supporting all the other non-game ready formats (be it textures or mesh data) could be directly sunk into a command line tool to convert the source data from the start.

You'll be doing no more 'real work' - infact you'll do less as you won't have to remove it later from the runtime.
You won't get tempted to leave it in 'for now' - because we all know it doesn't work that way in reality
You'll speed up your start up times - data is built rarely, but if you are transcoding on every start up your start up times can/will suffer, certainly in debug mode if you are doing any heavy lifting with containers etc and memory allocations.
You'll simplify your engine code - with 'one way' to get data in you won't have to deal with debugging multiple paths.

This isn't to say you can't have code at runtime to construct small assets, in our new renderer most of our 'test demos' use internally generated vertex data and texture data in lieu of disk based assets. Even the resource system testing demos do that (although they present the data as if it came from disk).

But everything is treated as if it is a 'game ready' format once it hits the engine.

#5039027 Engine/Framework software design/engineering questions

Posted by on 04 March 2013 - 07:25 AM

However, note that a nerfarious programmer can still create a "null reference"...

People have pointed this out to me before as an example of why pointers are better than references, to which I normally point out "Yes, and I can always turn up at said programmer's home in the small hours with a pointy stick to help me teach them the error of their ways" ;) biggrin.png

#5038702 GPU geometry shader particles frustrum culling?

Posted by on 03 March 2013 - 04:39 AM

Unfortunately the geometry shader is horrendous when it comes to performance and the general IHV advice is generally "really, don't use it..." - if you are doing a particle system then you'd be better off instancing a single quad or indeed doing the work in the tessellation stages rather than us the geo. shader.

(I've promised people at work that if they use a GS in the shaders the very first thing to happen is I will appear behind them with a flaming sword demanding the reason why they need to use it... dry.png)

#5038234 OpenGL Programming Guide 4.3

Posted by on 01 March 2013 - 07:31 PM

AMD have GL4.2 support, so while some 4.3 functionality is currently missing there is no reason to only focus on 3.x...

#5036148 Get unique IDs by reading the Instruction Pointer Register

Posted by on 24 February 2013 - 01:02 PM

This... is a horrible idea...

You have 3 'button' widgets; you run the code to get the instruction pointer - what makes you think this will be different for each instance, given they are running the same code...

Just use an int and have someone increment it each time you create a control... if you really think 32bit is too small then you could always use a 64bit int..

#5033320 What's your preferred way of letting objects affect the game?

Posted by on 17 February 2013 - 04:12 AM

Apoch has covered design nicely, but I think this is still worth calling out.

But games are complicated. Objects interact with each other and the entire game's state regularly throughout the game. Units collide, one unit attacks another, a building makes units, a unit can create projectiles, and those projectiles can affect a large number of other units, etc. In other words, when programming this, you need a way for one object to be able to affect another object (or the game state itself, possibly by creating other units or projectiles). But it's not just a one-time case; many different units have different affects and interactions, which can result in messy code when trying to make all these possible interactions and events possible.

The bold section, in particular the end, is key to this I feel; a single object in the game is not going to touch the whole game state. Not ever and certainly not directly. This is something you go on to basically say yourself with the list of interactions below and this is a key place to start when thinking about it - each object has a pre-defined interaction with the world. If you were going to make an RTS game, for example, your 'tank' super-object (super-object => collection of parts) isn't suddenly going to be marrying The Hulk any time soon ;)

If we take a closer look at one of the examples you gave, "a building makes units", as a typical factory in an RTS game.
While this might look complicated it isn't really, at the highest level the building does one thing 'creates a unit', at which point beyond throwing out a few notifications it is done.

Its output might simply be a message (in the generic sense, not a 'message system' sense) which says "I've made vehicle <type> at location <here> for <player>". Other systems would be listening for that event and respond accordingly; a player's unit collection might update and the unit spawner might create a new object so it can be rendered.

At which point the messages could ripple further afield (unit collection => UI to display message/icon; spawner to any AI and physics systems to insert it into their world view; and so on) but the key interaction is done.

As to how you expose this... well, there is the erstwhile mentioned 'message system' which you could route all the messages to - however this global routing might not be what you want. Your 'factory' super-object might contain a list of delegates/functions to call when certain events happen and systems 'subscribe' to them or you could abstract the whole thing and come up with a processing graph which represents spawning in data; this would require your super-class still outputs events but the hookup of those input and output pins becomes data driven and potentially modified per level.

The key thing, however, is that each unit has a predetermined level of interaction with the world so it can't mutate all the state itself nor does it have to deal with every possible thing that can happen. Even something as simple as 'collision' isn't really the units problem as it is a problem for the physics under the hood.

#5033186 stack vs heap

Posted by on 16 February 2013 - 06:01 PM

The funny thing is with the speed difference between CPUs (and the fact they are out of order monsters) and memory access you are probably better off worrying about your memory layout before worrying about every CPU cycles.

Sure, don't do more work than is required but often data access patterns can make a bigger difference than your instruction count.

#5032876 PC vs Console

Posted by on 15 February 2013 - 06:47 PM

But I also know that a lot of games (not sure of the percentage) are developed on the XBox and then ported over (I know Skyrim was, hence it's terrible UI for PC).

Ugh... I hate how this myth persists... in most cases the console and PC games are developed at precisely the same time from the same code base and the same basic asset sets - there is no 'porting' of code going on. In our games ~95% of the code base is the same between platforms and at any point during development you could compile the game for the target platform and it would run.

If the UI is 'bad' it is because it was a design choice made which probably had very little to do with what platforms were being targeted.

I put up with this myth/misunderstanding on gamer forums, because frankly those guys are laughably clueless at times, but it shouldn't be something which persists on a development forum...

#5032076 Game development on: Linux or Windows

Posted by on 13 February 2013 - 05:51 PM

it isn't perfect, but it works.

Well, "works" in that you have to use it as you've no other choice than to suck the pain and live with it.

That's the thing about OpenGL; it's the best choice if you have no choice.

(OpenGL is also the ONLY API to enforce this model; PS2, PS3, X360, Wii/WiiU, D3D9/10/11 - none of these use this model.)

yes, but the issue is being either tied to Windows or having to write/maintain 2 versions of a renderer isn't ideal either.

The point is that better programming models exist; pointing out minor unrelated flaws with D3D's API (COM & 'not modern C++') does not detract from OpenGL's model being fundamentally broken which was the original point which apparently triggered the rage.

For the record; I'd personally do two API level interfaces. If you are targeting D3D11 and OpenGL then the workload isn't going to be that high and the rest of your renderer is likely to swamp it out code wise.

(I'm currently involved in a complete ground up re-build of our renderer at work and we've taken the path of doing a renderer backend per platform, which means we need to support at least 4 code paths but it does mean we can do API and platform specific optimisations and paths while getting the best from each API. Unfortunately at some point this will probably mean I'll have to touch OpenGL|ES... *sigh*)

#5031936 Game development on: Linux or Windows

Posted by on 13 February 2013 - 12:44 PM

If you love perspective so much, you should read further then this post, for example at the extremely biased posts by phantom, where my post was mainly made in response of. Calling things 'pants-on-head retarded' is typical behaviour of trolling fanboys. Maybe I should have been more clear in stating who I responded to, but it's odd how trolling fanboys are allowed to post garbage, but it's not allowed to post a response to it in the same manner.

The difference is my post is commenting on a fundamental flaw in the OpenGL programming model where as yours touches upon COM (a minor point of D3D11 coding, mostly related to start up) and C++ form which OpenGL also doesn't prompt in sensible way.

If you can convince me that having to bind a resource to the pipeline in order to edit it is a good idea then I'll be impressed.
Not to mention that binding anything makes it editable which can lead to fun such as when you bind a VAO you can, via a bug, accidently change its content just because it is bound.

Pants. On. Head.

D3D programming model, on the other hand, has both immutable objects AND doesn't require you to have a resource bound to edit it. The rest of the API over that is just gravy.

Oh, and for the record, I spent about 8 years working exclusively with OpenGL, including writing a chapter on GLSL for a book back in 2005, until the ARB finally screwed up one time to many (see GL3.0/Longs Peak) and I took a look at the D3D world where, since D3D10, things are saner to work with.

#5031264 Game development on: Linux or Windows

Posted by on 11 February 2013 - 06:09 PM

If the fact that the Windows SDK and the DirectX SDK are separate (as they very-well should be)

Although they aren't any more; June 2010 was the last DX SDK update for DX11.
With Windows 8 DX/D3D is now part of the platform SDK and will be updated (or not) as that is updated smile.png

#5030489 OpenGL and Mac: No D3D11 level functionality?

Posted by on 09 February 2013 - 03:40 PM

However the number of games currently supporting the feature set is somewhat unimportant; if the feature set isn't exposed then no one can create games which target it anyway...