Jump to content

  • Log In with Google      Sign In   
  • Create Account

Calling all IT Pros from Canada and Australia.. we need your help! Support our site by taking a quick sponsored surveyand win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 27 Aug 2002
Offline Last Active Yesterday, 11:16 AM

#5234835 Game Development Help Please (language choice)

Posted by Krohm 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 Krohm 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 Krohm 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 Krohm 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 Krohm 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 Krohm 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 Krohm 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 Krohm 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 Krohm 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 Krohm 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 Krohm 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 Krohm 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.

#5228302 Can I do MIMD on SIMD architecture?

Posted by Krohm on 10 May 2015 - 11:07 PM

Do superscalar CPUs count as MIMD? Why is this important? How does such example map to real world?

#5227693 How much video memory do I really have?

Posted by Krohm on 07 May 2015 - 03:12 AM

I'm seconding Hodgman. I've personally solved an hang by just compiling x64. Resources were about 700MiB if memory serves, on a 1 GiB card. Yes, it did fit in x64.

#5227144 (In)efficiency of Event Handlers in a flexible game

Posted by Krohm on 04 May 2015 - 09:09 AM

As I said in this topic, I currently have an idea for an exremely modular, flexible game. ... my focus would be on the "plugin/modding" system of the game ... Since the game is a platformer, each entity-type, each platform, etcetera would be an add-on; But the question here is, can the performance keep up?

No. No no no no.


First things first. Your game "as a whole" might be the add-on. In the sense you might have no game-specific logic in (C++, or your lang of choice) code. Your game is not an assembly of add-ons. It is a cohesive blend.


Now that we got out the ideological part, let's get to your question. Will perf keep up?


Be explorative, don't worry too much! Your priority is getting the job done!


More involved answer is: callbacks by themselves won't kill your perf. What it matters is how often they are called and how much they cause you to deviate from the "optimal" path.


In your example, you want to check if "entity1" collides with "entity2".

As far as this is what goes, you might just have the physics processed as usual and then iterate on all resulting contact points to extract the set involving entity1, then checking if it contains entity2. This is doable for a small amount of checks. As the interesting entities grow, it's probably better to go on a "sensors" approach - they are physics rigid bodies which automatically keep track of their contact points so you can just check their internally collected list. Bullet calls them "ghost objects" if memory serves.


In general, if the check to call is trivial (an n-m test like above is not, albeit it might be viable) the cost of the callback depends on how much often it gets called. As long as it's event-based, I've found this to be very viable.


Keep in mind there could be ways to emulate what you need while still being hi-perf. Here's a real world example on a game I used to work a couple of years ago.


I had those things. We'll call them "rollys". Rollys just roll around. BUT they don't fall in the water, turning back to avoid falling into the void/water. There can be 1-8 rollys each "lair" and there are usually 1-4 lairs.

The initial solution involved a per-frame, per-rolly  callback. It involved sweeps and was fairly complicated. Performance was viable albeit far from perfect on the lowest-end devices (Atom).


Solution 2: rollys were updated to include a special "hit descriptor" and the level was annotated with special "rolly only" colliders. Now rollys can just bound off the special colliders - they are the same to them. They still behave the same, but this solution requires way less tests.


Long story short: before going into scripting, ensure you have a decent data-driven design. While you might want to keep game-specific code out of your application (or not) there are features you're going to need and those should be just built-in.