Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 24 Apr 2011
Offline Last Active Yesterday, 09:53 PM

Posts I've Made

In Topic: Game Object Update Order

21 June 2016 - 06:39 PM

True dependencies are actually pretty rare in most game logic, in my experience. If your update code is highly order-dependent you might consider using different methods that aren't so fragile.


In this rare case I have to strongly disagree with Apoch unless I'm miss-reading the intentions here or I'm reading more into the question than he was..  Everything is about order and in fact the OP is incorrect about Unity, there is order control built in, you can tell the engine the order of execution you want.  Additionally, when it comes to the future with multi-core, without execution order control you simply can't effectively utilize current CPU's.  (Well, not that I know of 'effectively'.)  I don't disagree in that it *can* be fragile, but it is much like bad patterns in C++, you learn to avoid the parts that cause issues.


Having said that, let me rephrase it so the negatives have some context.  Unity has ordering in terms that you can control which 'components' execute before other components.  I think they call this the priority system or something like that.  The purpose in Unity seems to be making sure that an AI update component can complete making decisions before any movement is calculated in that frame.  This is fairly trivial common sense behavior I would think.  But, perhaps, what Apoch was suggesting is that this is 'system' level dependency and not individual object to object relationship dependency.  What I mean is that i always update AI before physics, I can apply impulses via the AI and have those acted on when physics updates, I never try to interleave AI and physics, this is *system* level dependency.  The other, bad, option is that I write a follow behavior that executes at the same time as the AI for the object I'm following, well, which one updates first changes the behavior of follow since I could be following last frame or next frame's position.  It's just bad news.


So, depending on the OP's intentions, dependency always matters.  It depends on where you apply it as to if it is a problem or not.

In Topic: Work queue with condition variable - design issue

14 June 2016 - 06:48 PM

Generally speaking, I've fiddled with variations of the shutdown problem and come to the conclusion that the best solution of the various ugly ones is to treat the shutdown as nothing more than another task.  So, the loop uses the first variation of "while (running)" without any other special code checks.  The owner of the thread simply implements a special "exit" task which changes the value of running.  With this, 'running' does not need to be volatile since it is modified within thread so it cleans up that little annoyance.  So, shutdown becomes:





That's about as clean as you are going to get with threads in this area.



As to the priorities item.  I will warn you that priority systems are a massive pain to get correct and you might be better off not doing that and reconsidering the issue you are trying to solve.  I gave up on prioritized tasking for a number of reasons, the first reason is simple; doing it correctly is expensive and I wanted the performance back.  Generally speaking, for game work, I look at priorities as a fix for something that breaks my preferred separation of responsibilities approach.  Let me try and explain this a bit better.


So, the basic reasons I ended up wanting priorities turned out that I had some tasks that I didn't care if they finished this frame or a frame or two in the future, but I had a consistent need of many tasks executing in the frame and I could not complete the frame until those finished.  So, after considerable trial and error, I ended up with a frame work system and thread pool working in conjunction.  Making the two items work together is a bit of a trick but generally speaking, much easier than getting priorities correct in a single solution.  Sorry I can't suggest a solution to your actual problem and only suggest a different solution all together..

In Topic: I'm having trouble with constructors and destructors

03 June 2016 - 08:26 PM

First guess: you copy and pasted your include guards from a file named extra's and forgot to change them.  I.e. EXTRAS_H_INCLUDED if that were already included your correct looking class declaration won't be included and as such the compiler doesn't know about Wall and of course declaring the constructor/destructor won't work.


Edit: also note that your drawMe function has no class name in the declaration.

In Topic: Doubts about thread consumption

02 June 2016 - 06:00 AM

The number of threads generally won't matter in such a functional model, so long as you stay in reasonable bounds such as less than 100.  My multicore engine currently starts up 19 utility threads beyond the 1 thread per hw thread (i.e. 6 core ht box, 19+12 total threads) and it works like a charm.  The reason is that the 19 threads are generally all very light weight and primarily IO bound items which run in the small gaps where the multi-core is not 100% active.  This same sort of interleaving will happen in a functionally threaded engine just as well and adding more threads is highly unlikely to be a detriment.

In Topic: Creating Cross-Platform Code

01 June 2016 - 07:16 AM

Figured I would chime in on a couple points here, some of this may rehash the above points but given you requested a how to I'll walk you through what I generally do.  The first thing to mention is that you started at the correct point, cross platform starts and ends with the build setup then the tools you use.  I will obviously be suggesting CMake given that my experience with Premake was great for limited areas but the bugs and lack of support generally made it unusable in the long run, and there are some new reasons for this I'll get into shortly.  While it is an old article, you may take a look at: http://www.gamedev.net/page/resources/_/technical/general-programming/cross-platform-test-driven-development-environment-using-cmake-part-2-r2994 which was where my build system started.  Today I support Windows, OsX, iOs, Android, Linux, XBOne, Ps4 and a bunch of different AR/VR system variations, it started from the presented build system in that article series.


Once you have a build solution working, editors and more importantly debuggers, are your next step to consider.  Being comfortable on multiple platforms takes a while and as such I am always on the lookout for the best tools available.  In the process of looking at recent updates to the Android environment I ran across a very useful tool which allows me to use a single IDE for all platforms other than Windows.  (I could use it on Windows but I prefer VC on that platform.)  Clion, the basis of Android Studio 2+, is a very interesting IDE for other platforms.  First, unlike XCode it doesn't constantly attempt to do things in unusual (and I'd go as far as saying massively annoying) manners, it is more closely aligned with VC and other IDE's in most behavior.  But, more importantly if you decide to use CMake, it doesn't use a typical solution file, it directly works against CMake itself as it's solution file.  So, without inbetween steps, when I go to Linux/OsX, I just open it up and it is ready to go.  This is not the only solution but it is most definitely worth looking into given how easy it is to hop to other platforms and fix the build quickly with low hassle.


With editors out of the way, as others have mentioned, you need an effective method of knowing when you have broken things.  The first thing most folks are likely to suggest will be continuous integration using Jenkins.  I tend to alter that just a bit and suggest TeamCity (https://www.jetbrains.com/teamcity/) for a couple of reasons.  The primary reason is that setting up Jenkins is quite the chore and after it blew up one of my Macs and made me reinstall from scratch I gave up on it.  I had TeamCity up and running in just under 2 hours from initial investigation to CI running on Windows, Os X and Linux.  And, as it happens, the free version has enough allowed agents and configurations to support those platforms as needed so I have not yet purchased an upgrade.  The second reason I ended up with TeamCity is the built in support in Clion, it is very sweet in terms that Clion is a fully integrated solution to managing TC such that it will pick up logs, allow you to start investigations, trigger builds etc all without leaving the IDE.  I'm sure that is all possible with Jenkins, but generally speaking it was a lot of work where this just existed as a benefit after setup and initialization.


Code build/link is of course just one step to having confidence in what you are doing.  Unit testing, integration testing, etc is your next step.  As with the linked article, I generally still use Google Test for C++ code as it is low boilerplate and high utility.  Additionally Jenkins and TC both have direct support such that after my builds complete my unit tests run and I get feedback on the over 500 tests across all platforms.


I'd say at this point you are generally ready to do real cross platform work.  While all these bits and pieces may seem like overkill, I would argue that without them you spend more time jumping around doing repetitive nonsense than you do writing code.  All this setup takes a couple days before it is working smoothly even for a simple hello world test.  But once done you will thank yourself for having set it up because you can focus on the code, where you should be, instead of fighting with different platforms constantly and switching from IDE to IDE.


Hope this helps.