Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 May 2010
Offline Last Active Yesterday, 07:45 PM

Posts I've Made

In Topic: Variable range rope physics.

12 November 2015 - 07:33 PM

You know, I can't actually remember if we did bother with that. I think I still have the code on a branch somewhere so I might just go back and test it to see, but I think we'll roll with this setup from here forward.

In Topic: Variable range rope physics.

10 November 2015 - 07:16 PM

So we were never able to fix the bug with the rope using hinge joints, which is unfortunate because we like the rope's flimsiness when made out of discrete components. What we ended up doing is getting a static image for the rope , stretching it as the player changes the tongue's length. It actually looks moderately decent but still requires some work. The most important thing is that they are stable. What I have also tried just drawing a curved rope based on player's velocity , but it just ended up making the tongue Iook like a PVC pipe.

In Topic: Variable range rope physics.

04 November 2015 - 07:48 PM

That's the issue I'm facing. Under static conditions, the rope works ok. If a player just hangs off of it and nothing changes about the situation, Unity will be able to resolve the simulation correctly. The issue arises when the player's rope/tongue either attaches to a moving platform or gets pulled by some other object like the floating platform in the game prototype above. Unfortunately, that's the main method of locomotion in my game and I'm having a really hard time finding a solution to it.

In Topic: Singletons and Game Dev

01 November 2015 - 01:42 AM

Many successful products have shipped on terrible source code. A finished product built on a house of cards is always better than an unfinished product built on an ivory tower.


Heh, that reminds me of the lugaru source: http://hg.icculus.org/icculus/lugaru/file/97b303e79826/Source/GameTick.cpp#l7276


I guess it really comes down to a works or not result.



Global variables create hidden dependencies, which destorys your capacity to analyse access patterns and control their scheduling.
Hidden dependencies are also evil for countless other reasons too sad.png


I've been feeling this pain ever since I started working at my current job. It's a web application for which the client is written in Javascript. The way it behaves is really unpredictable. A lot of functions have really nasty side effects, and of course no dependencies are made obvious through the function interface because all data is stored in a global variable called "locals" (an oxymoron of the highest order). At least I can grep the source code to find instances of its use, but it's still not a very good "technique", merely kind of a means for brute-force debugging.

In Topic: Singletons and Game Dev

01 November 2015 - 01:22 AM


Ok, how is that not flagged as a bug? That's total bulls***. Is there a reason not to use the stack? I don't think "performance" is even applicable to this situation.


Meh. Dig through Android code sometime. You have to control every allocation to prevent the garbage collector from murdering you, so static float buffers abound.



Since we're dealing with an object reference, can't we encapsulate synchronization methods in the object's implementation, such as for instance using Java's "synchronized" modifiers on non-static methods?


You can make it thread-safe that way, yes. But you can't use it in parallel. Which is kind of the point of having multi-core machines in the first place.



I hear Android is supposed to have a "smart" way of managing memory, but I've never really dug into that. Kind of interesting to find out that even in simple cases like this it can be that troublesome.


I've got to really face-palm here. I very rarely need to work with concurrently executing code, so I somehow failed to realize the difference between just "multithreading" and actual parallel execution. That makes the problem a lot clearer. 



Ok, how is that not flagged as a bug? That's total bulls***. Is there a reason not to use the stack? I don't think "performance" is even applicable to this situation.


That was my first thought, but then I saw it's java. You can't allocate arrays on the stack in java, right? I've done this when using XNA/C# before, to avoid any memory allocations in the game loop... as long as I knew that section of code was not going to be called from multiple threads, or re-entered on the same thread.


That being said, if they really wanted they could just explicitly declare 16 float variables in each method  where this buffer was needed.



Well, you do have to use the "new" keyword when allocating one and in addition to that an array is actually a full object. As far as I'm aware, there's no way to declare member arrays of variable size without using the heap even in C++. If they do somehow manage to do that, I'd sure like to find out how.


> Does anyone how to get rid of this block?