Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Aug 2002
Offline Last Active Sep 24 2016 03:22 AM

#5235519 What performance will AMD's HBM bring for graphics programmers?

Posted by on 18 June 2015 - 10:16 AM

This does not belong to this forum.


The thing is simple: you already get +75% bandwidth so you can get up to 75% more perf as long as you are bandwidth-limited and fit the memory budget.

It seems there's also an improvement in latency.


It might be a game-changer for manufacturing but it really isn't much from programming point of view. It's "just" faster memory. Except it's way faster. And as a flagship, it's fairly affordable.

#5234932 Game Development Help Please (language choice)

Posted by on 15 June 2015 - 12:10 PM

But for some insane reason they built the game you linked to in flash - very odd considering you can do all that with js, css and html no probs.
No problems now, but a quick search suggests the game was originally launched in June 2011. HTML5 was far from being stable at the time, not to mention the state of JavaScript engines. We could discuss whatever it's stable now. Their decision was appropriate at the time considering they've been churning profits for years. I've seen this game being advertised on mass media!

#5234836 trying to make GPU physics deterministic

Posted by on 15 June 2015 - 12:51 AM


can you give an example plz, don't understand, are there other int operations that aren't deterministic?

Last time I tried stuff like 2147483000u * 10u I got garbage instead of the expected 4294960816u. Can't remember the exact operation. I think it may have been bitshifts instead of multiplications.


Is there any chance this could have been a driver/compiler issue? On the OpenCL compiler I've seen it forgetting about data hazards. It eventually got fixed.

#5234835 Game Development Help Please (language choice)

Posted by on 15 June 2015 - 12:44 AM

For stuff running in browsers you have Javascript and Javascript. HTML5, some CSS...

But if you have no idea what you're doing, perhaps you should stick to some engine such as the above mentioned Game Maker. Try to hack something with Unreal Blueprints, something along those lines.

#5234419 Need advice on GameObject handling.

Posted by on 12 June 2015 - 03:46 AM

Neither. In C++ terms, I'd suggest an std::vector<std::unique_ptr<GameObject>>. You cannot go wrong with persistent stuff.

What GameObject really is depends on what it does. To check for clicks, you just need a click area, for animations you need another interface, you can work on inheriting interfaces or by composition.


At the level of abstraction you're talking now there's no point in writing much. Maybe you have your needs clear in mind; I sure don't.

#5233744 Bullet Physics Character Controller

Posted by on 09 June 2015 - 04:22 AM

In the Bullet manual, they have a graph which explicitly tells you to use btBvhTriangleShape for static objects.
Are you referring to the graph in "Collision shapes" section?

Indeed, it seems to be different from what I recalled. At the time I was targeting 1st gen Intel Atom and I could get a nice benefit with hulls, even though the world geometry was very simple. I suspect I might have to test again.

#5232134 Guilty Conscience

Posted by on 01 June 2015 - 05:12 AM

Nice idea.


Perhaps some objects could disappear or be broken on first try if an agent has not slept in a long time.


For example in infiltrating a condo, they might be requested to pull down an emergency stair. But as the agent cannot sleep due to his inner demons he might fail to see them (they're effectively removed/alpha'd out) or he might require to pull the action trigger 13 times as a minor annoyance.

#5232128 signal() : any performance impact ?

Posted by on 01 June 2015 - 04:35 AM

Considering this thread is tagged C++, I'd suggest OP to look at some other possibilities.

signal() is definitely not the C++ way of signaling errors. The canonical way is exception-driven handling, albeit they have their own set of caveats. In general I don't recall many cases in which an appropriate shared state was insufficient.

#5230819 "Nested" Instanced Models

Posted by on 25 May 2015 - 06:00 AM

Nothing beats pre-transforming everything in advance. As long as you have memory you should do it. 20k unique vertices is still viable!

Batching the various "sub-tree" models seems sound!


As to when to switch to hardware instancing, there wasn't a clear cut. It depends on the drivers and the hardware. Since the models are fairly large, I don't think there's much point in instancing them once pre-transformed as we're talking about 40 drawcalls. D3D9 is slow, but not SO slow.

#5230198 Communication between objects and systems in Game engines.

Posted by on 21 May 2015 - 12:12 AM

A specific example of this would be for a raycast. If I have a player who needs to care about whether or not their on the ground for example, when I update the player I'm going to want them to shoot a raycast down to see if there is in fact something beneath them. This would mean that the object needs to know about the physics systems existence, a dependency that I'd rather avoid!

But, for this specific example, you cannot.


It is intrinsic in your problem you want to shoot a ray which somehow "hits" your collide-able world. It already knows something physics exists.

Ok, ok, let's stop the nitpicking.


Your solution is: interfaces. In the sense of base classes with virtual function calls.

WAIT! Isn't virtual call super expensive?

It is, but not to the point you want to sacrifice your mental health. In my experience the cost of raycasts and sweeps is way, way higher and that specific inefficiency gets easily lost in the great scale of things.


But perhaps the most important part is


write games, not engines


don't make your decision based on example. Don't let your target be out of your vision. What your final product is, that's what it should drive your decisions and your efforts. Use real world data.

So, if you have to do a raycast (per frame I assume) a solution might be viable. One per entity... perhaps you might start looking in a different direction. Several per entity, per frame... you'll need to get smart.


But again, your question has a general solution: with no hard data to talk about, just use virtual base classes.



Am I just being too paranoid about this?

Most likely. Explore your problem first and then attack it with a better understanding and data. You'll get ahead faster and hopefully the end result will be better as well.



Last note: in theory since C++11 you can do function objects (without going crazy with the syntax). In practice, std::function / lambdas are even more powerful than function overriding however I often find more convenient to go with base class interfaces as there are often relations between the various calls.

#5229987 Thoughts and Ideas about optimizing 2D Per Pixel Collisions

Posted by on 20 May 2015 - 12:58 AM

Krohm, 1600x3200 is sprite sheet, its processed once to get collision masks for all frames, then when collision is checked only the current displayed frame in this image will be processed which is like 800x800 along with the small intersected area between Rects, so its not a problem and actually fast, havent noticed any peaks and lags in frametimes and CPU usage is actually 30%-50% on one core and other cores are drinking tea at 3%, but i still dont get the part of forcing CPU/GPU full sync, could you please explain as it seems a very important note?
If you are doing the actual collision testing on the GPU you'll have to pull back the results somehow. The act of pulling back the collision list forces the GPU to execute its queued command until completion and initiate a transfer. I don't recall any way in D3D9 to do this without stalling. This is truly bad for performance but if you do it every frame, you might get consistent framerate anyway.

#5229540 what Motor/ Cognitive skills are required in this game?

Posted by on 17 May 2015 - 11:54 PM

It has been way too much time since I've had my HCI training but I just wanted to say I totally liked this.

#5229539 Thoughts and Ideas about optimizing 2D Per Pixel Collisions

Posted by on 17 May 2015 - 11:51 PM

In my experience, per pixel collision is viable for small sprites but at 1600x3200 you're way, way beyond what I would consider. 

I'm not quite sure how D3D even takes part in this. I would do it all on CPU (except perhaps the mask generation).

Keep in mind that to get back the results from collision testing those huge masks you force a full CPU/GPU sync. That's like nailing yourself to the floor.

#5228954 What models are these, 2d or 3d

Posted by on 14 May 2015 - 08:08 AM

That looks like some fine 2D to me. I don't think some of the fine details and the amount of particles required for the fire can be made on browsers yet given the average hardware.


But: web browsers can do 3D and it can also get pretty complicated.

#5228905 (Best Practice) Multithreading instantiation

Posted by on 13 May 2015 - 11:54 PM

Yet another fine piece of advice above from Sean above.


I've found C++11 threads very convenient. Futures were, in my case, not much of a point. I plan to use them soon but I haven't had the chance to work on that part yet.


However, from a bigger picture, I have to warn you might be looking in the wrong direction. Fact is you can get plenty of mileage out of single-threading on everything that is at least K10 core; avoid the error to do multi-thread to hide inefficiencies.


For example: I've found my physics loading process to be really fast (Bullet). By contrast, I have observed GPU transfer to be quite faster when uploading multiple textures. The difference is especially noticeable for small textures. Anyway, given my assets, I had no need to do either.


At last: multithreading + OpenGL = nononono and multithreading + D3D9 = no thanks.