Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


JarkkoL

Member Since 20 Jan 2009
Offline Last Active Jan 19 2013 03:22 PM

Posts I've Made

In Topic: Questions about encapsulation, resource management, global variables* and the...

03 January 2013 - 01:08 PM

infact there are better solutions.

Oh, you misunderstood what I said. I didn't advocate design where physics code has dependencies to audio code, but that having global access to resources doesn't hide such a dependency any more than explicitly passing the resources to the code. It means that some physics programmer doesn't accidentally write dependencies to audio code because of global resources, but that he needs to also access audio API's anyway thus is well aware of making such a dependency. And you are absolutely right that such a connection between the engine sub-systems should be made at a higher level.

 

I think global resources have their proper uses, but you need to weigh pros vs cons to see if they are the best solution for given problem. No one is saying you should make everything global ;)


In Topic: Questions about encapsulation, resource management, global variables* and the...

02 January 2013 - 11:48 PM

While I agree with your principle in general, there are practical scenarios where global access to resources is much more pragmatic solution. When you find the need to access a resource in the depths of the code, it can be very cumbersome to change all the interfaces & functions to pass the resource all way through the necessary callstack. You may even have some very generic functions in the callstack where it makes no sense to change the interface to pass specific resources through the interfaces.

 

If you have need to play sound in the depths of physics code, global access to sound resources doesn't endanger modularity any more than explicitly passing the resources. In both cases you need to #include sound code in your physics code, which should be enough of a red flag.


In Topic: Questions about encapsulation, resource management, global variables* and the...

31 December 2012 - 08:12 PM

It's perfectly fine to use globals in C++, though instead of accessing them directly you should access them via functions to provide some level of encapsulation. It's just good practice to minimize the number of globals to avoid your code becoming an unmanagable spaghetti mess. For resource management, I personally use globals since passing pointers to resource repositories everywhere where needed would be much worse option.

 

Cheers, Jarkko


In Topic: How to get area of a convex mesh?

29 August 2011 - 05:43 AM

How does that even make sense?...

What do you mean? I assume you know how QuickHull algorithm in 3D works.

Cheers, Jarkko

In Topic: How to get area of a convex mesh?

29 August 2011 - 05:32 AM

I have to use QuickHull to create the convex mesh anyway. It's cheaper to just use the tetrahedrons that my QuickHull functions iterates over instead of reiterating over them in a second pass to compute the volume.

It's faster to calculate the volume of the convex mesh in separate pass than integrate the calculation into the QuickHull algorithm. When you calculate the volume in a separate pass you need to only iterate through polygons of the convex mesh, while when integrated into QuickHull you need to calculate much more volumes. Also a word of warning, implementing robust QuickHull is major pain in the ass because of numerical precision issues.


Cheers, Jarkko

PARTNERS