So I have a close friend that works at a studio that had layoffs…. This is unfortunate however it is a blessing they kept him. Having worked with him closely on a few titles I know for a fact he’s a hard worker and will put in extra time to meet deadlines, etc. So even though it’s sad that many good people have lost their jobs its great that the employers still recognized his invaluable contributions and kept him around.
So the message for today is to stay motivated and focused on your work. Work hard to do right by your fellow coworkers because you never know- one day they might be the one making the decision to hire you at another studio in the future. Small world, small industry….
Uploaded a new demo. This version is a significant jump over it’s predecessor in performance and runs a lot more stable. Ah, I’m feeling warm and happy inside
Lately I’ve been thinking about playing around with integrating multicore physics. Currently, the physics system I coded occurs in the main game thread pass. You know the routine. Multicore physics or rather in my case, Multicore Collision Detection would involve the main thread passing collision volumes to a concurrent physics thread. The physics thread takes the velocities of the objects and watches for collisions. When a collision is detected, this information is propagated to the main thread
The gains for the average title might not be all that huge but for a title with hundreds of entities in the physics world the savings might be worth it. In my case though I mostly interested in leveraging more cores.
I’m a little hesitant though to go rip apart my engine yet again to introduce another layer of complexity. Actually, what I really dread is the thought of having to chase a potential read/write data race issue.
But if I do decide to pursue this my thought is that I would write this as a “Job” that runs asynchronously, running the physics simulation on its’ own Core. Essentially it would work like this:
— Check queue for collision volume updates
— Run the physics simulation
—- Copy current state into a list of events that the main thread can query at anytime for current status of the physics world
The only bottleneck here is the last step, when the main thread queries “Physics World” for the current state. But it shouldn’t really be a bottleneck if this is handled properly.
Should be a fairly straight forward thing really unless I’m missing something. The main game thread and physics really shouldn’t be sharing much information beyond the current state of the physics world. If I do implement this will make sure to keep it all configurable so I can switch between single threaded and multi-threaded physics.
Yep, they covered that whole debacle well here already
Yep it was a read/write data race condition that was causing the issues. The render thread was creating Game objects on the heap that represented the DirectX driver. The problem was this game object could be registered while an asynchronous read was taking place in another thread. So the threads were clashing which resulted in the occasional crash I experienced when starting up the game. The only clue I got was that I was seeing impossible memory values for these game objects sometimes.
What blew it only happened in Release. Never could get it to happen in Debug. So it kinda sucked trying to go through that call stack.
Anyway I’m just going to make sure to put some thread checks around the hot spots to insure this won’t happen again.
Happy me, feels great to resolve this issue. Will be uploading a new Demo later tonight / tomorrow
I’ve worked at companies that existed at both extremes of the spectrum on this issue. Most companies do not perform code reviews. However, a few do. I’m indifferent on it’s use (Edit- actually I’m always for code reviews) however I do think it’s very effective for a few reasons:
- When a programmer modifies code in the domain of a peer. This way, this programmer is not unintentionally breaking something the domain expert has implemented. So say, a game programmer should conduct a code review with the graphics programmer when they tresspass into each other’s domain
- When the source codebase is locked down. Programmers can send code reviews which can go up the chain to upper management giving them the opportunity to verify if the feature should go into the build.
- Helps insure coding guidelines are enforced
Those are the main benefits I’ve noticed from integrating applications like CodeReviewer.
Been busy debugging the GODZ demo in my spare time. Noticed every now and then only in Release does it crash sometimes. Grr…. It could be a read/write data race condition or perhaps something else more exotic. Perhaps it could be something as basic as an uninitialized variable. When I get time I’ll try investigating into it more.
Besides that all has been well with the Demo and I’m still excited to finally upload a new build.
Yeah, yeah, yeah I know people come here for the tutorials and plugins I give away. Anyway that doesn’t stop me from being on cloud-9 about my new GODZ demo I just uploaded. When you are this overjoyed and elated, you gotta share the news. The new version might be a little faster then the old one as a result of some optimizations I’ve done.
New stuff- well this is the overhauled engine that uses the new Job Manager system. Some packages are streamed to speed up loading for multi-core systems. Fog now works correctly with dynamic shadows. In the old build, Fog actually disabled dynamic shadows. Duh. Futures and Jobs are employed full force here. Let’s see what else– basically just a huge volume of changes went down behind the scenes. As always, the engine still employs a multithreaded renderer.
One funny thing I noticed. The engine loads so fast you barely see the loading screen… It’s near instant bootup
Hm, just realized I turned off HDR by default. You can go into the .lua file if you want and enable it. You can also turn up the shadow map sizes, play around with Lamda, and do some other stuff.
Programming Tip: Use Enums over Bools
You want to use Enums over bools whereever applicable for function arguments. If there is the slightest possibility the argument might ever expand into more then two options, then you want to use an Enum. This way it’s much easier to update code later plus switch statements can be employed which will work towards generating cleaner code.
void ActiveElevator (bool modeOn)
void ActiveElevator (ElevatorMode mode)
Last night played EVE Online for a bit. I log onto my character and go rat for a bit. Couldn’t really find any good spawns and only 1 other ratter in the system (my corpmate). The night is looking like it will be dead. Then our CEO makes a call-to-arms when Intel reports hostiles. I warp into system and by that time they already have them in Hull and they flee (guess no one had a scram, grrr). The red jumps through the gate (in lowsec now) and we just like stare at each other. At the time, I’m in my ratter (t2 fitted myrm) so I don;t even think this ship can tank the hostile + gate guns. Especially with the drain my t2 hardeners have on my cap
So we don’t fire on each other due to gate guns. Anyway, the red backs up from the gate (pass the 150km range) and starts going at it with my corpmate. Btw, the red was flying a Hurricane. Anyway, my corpmate is taking fire from gate guns. During this time I’m in transit back to the gate in my Taranis (interceptor). The hostile warps away before I can get in range to tackle.
Now to think back on this I should have warped to my fleet member. But I didn’t. I was trying to warp to the hostile….
Man pvp is complex in EVE…. Oh well live and learn