i have the following problem: I'd like to use bullet physics for moving the Character around. so far i have a severe problems with jumping: if i fall on the ground, the body (the Character) sinks into the ground for a couple miliseconds. the longer he falls, the more he sinks. Im using a gravity of 20, a cylindershape, and a groundplane with sleeping thresholds of 0,0. is there any way to fix this?
It sounds like your objects are moving too fast in each simulation step. The result of this could cause the two objects to over-penetrate. In the case of the character controller code provided there is a recoverFromPenetration that is called to move the object that caused the collision backwards (backwards being defined as calculated from the normals of the penetrating polygons) until it is no longer penetrating.
void btKinematicCharacterController::preStep ( btCollisionWorld* collisionWorld)
{
int numPenetrationLoops = 0;
m_touchingContact = false;
while (recoverFromPenetration (collisionWorld))
{
numPenetrationLoops++;
m_touchingContact = true;
if (numPenetrationLoops > 4)
{
//printf("character could not recover from penetration = %d\n", numPenetrationLoops);
break;
}
}
m_currentPosition = m_ghostObject->getWorldTransform().getOrigin();
m_targetPosition = m_currentPosition;
// printf("m_targetPosition=%f,%f,%f\n",m_targetPosition[0],m_targetPosition[1],m_targetPosition[2]);
}
It tries to do this 4 times and if it does not resolve the penetration the recovery code fails and terminates with the objects still penetrating one another. This controller code is not intended to be production code but rather a starting point and framework for further customization and development. It serves its purpose pretty well but as you have discovered there are limitations.
Related
First, sorry if my english is bad and I'm new to Actionscript 3.
I have a movieclip, I give it an instance name "symbol1" which include a code inside it, like this :
var a: int = 2;
var b: int = 3;
var total: int = a + b;
How can I access the "total" integer variable inside that movieclip in the main timeline? I try to trace it but the result is 0. In the main timeline I wrote this code :
trace(symbol1.total);
I appreciate the help, thanks
The "problem" is the order of execution of frames. The parent is executed first.
The value is 0 and not undefined because the property does indeed exist since the creation of the object which happens in a previous separate step.
You should be able to verify that by stepping through your code with the debugger.
I've made 6 games. each game is in the MovieClip including the game functions, times, scores, variables, etc. I want the total score of each game summed outside each MoviClips, which is in the main timeline. is there a solution to that problem?
This makes your timing problem even more apparent.
You arrive at a frame, which contains a game and you immediately want to access the total score of it. It should be obvious that the game first has to be played in order to obtain a score from it.
Asking a newborn baby what his favourite moment in the first 60 years of his live was doesn't make much sense.
You have to notify the main timeline that the game was finished. The best way to do this is to dispatch an Event from the game. Frames are totally unnecessary.
Your code could look something like this:
var game:Game = new Tetris();
addChild(game);
game.addEventListener(GameEvent.FINISH, onFinish);
function onFinish(e:GameEvent):void
{
trace("finished game with score " + game.score);
}
If you want to update the exterior score sum while the game is running (to immediately reflect any change in the score, not just when the game is finished), your best bet is to create a ScoreModel for the score which you pass to the game, the Game. The Game modifies the ScoreModel, which in turn causes it to dispatch Events:
var score:ScoreModel = new ScoreModel();
var game:Game = new Tetris(score);
addChild(game);
score.addEventListener(Event.CHANGE, onScoreChange);
function onScoreChange(e:Event):void
{
trace("score changed to " + score);
}
Both examples are "what your code could look like"-type of examples. There are many questions about how to dispatch events that explain how to do this in more detail.
Something that came up in the comments from #Jezzamon:
I'm pretty sure you're accessing the variable total correctly, otherwise I would expect it to cause an error (you can test this by trying to run trace(symbol1.variableNameThatDoesntExist)).
No, there cannot be an error for accessing a variable as seen in the question. The reason for that is that the property is accessed on a MovieClip object, which is a dynamic class. As such, the compiler doesn't know if accessing a particular property is valid, because that can change at runtime. And because nothing else relies on the value to be valid, there isn't a runtime error either.
Here's some example code to illustrate this:
trace("toString: " + {}.toString); //toString: function Function() {}
trace("bananas: " + {}.bananas); //bananas: undefined
This is one of the reasons why using MovieClip can be a bad idea. In addition to that, the Flash IDE modifies the code behind the scenes. That can lead to unexpected execution of code. A purely code based workflow sure is advantageous in this regard and recommended.
How to implement Undo Redo operation in flex 4 for maintain history?
I'm working with flex UIComponent and DisplayObjects for creating and editing diagrams,but
in flex there is no way to handle user operation history directly.
there is any idea to achieve this?
You could implement the Command Pattern for all actions with execute and undo methods, and queue them up.
so when the user wants to do some thing - lets say create an AddFiveToTotal class and executes:
public method execute():void{
totalModel.add( 5 );
}
This class would then be stored on a FIFO queue.
if the user needs to undo the command would be popped and the undo function called:
public method undo():void{
totalModel.subtract( 5 );
}
for redoability, don't pop, just iterate the queue
also take a look at the Memento Pattern
If you are using any of the currently popular MVC(S) frameworks you will undoubtably find a util that some one has already created
You can acheive with help of memento pattern. It hard to track all properties better you can what are property need to use for undo/redo operation.
Memento Design pattern
Memento pattern
Demo sample with source code http://www.flairpy.com/mementoPattern/MementoSample.html
There are several ways you can address to this problem. First is to keep the states of your whole canvas in a Vector (I mean have a listener for all the things user can do on the stage and saving the state after a change) and then have an index of current state saved, so that you could move through your Vector and put the needed state on the stage. This is the easiest way to approach undo/redo functionality, but beware that you'll have to make clones of objects a lot and this will become a memory hog if you're going to deal with a lot of objects or a lot of undo/redos.
The second approach is to only keep what changed in that vector, so that you won't have to create and clone a lot of objects, but only save one object in your Vector which will contain all the properties that have changed and their last values. This will get you something like this:
private var mHistory:Vector.<Object> = new Vector.<Object>();
private var mCurrentIndex:int = -1;
public function storeState(state:Object)
{
mHistory.push(state);
mCurrentIndex++;
}
public function undo():void
{
if(mCurrentIndex < 1)
return;
mCurrentIndex--;
//here you could test for values that could have changed
var item:DisplayObject = this.getChildByName(mHistory[mCurrentIndex].name);
if(mHistory[mCurrentIndex].x != undefined)
item.x = mHistory[mCurrentIndex].x;
// etc. you get the point. Note that this is only comfortable if only several things can change
}
And the call for storeState function would be like this:
var state:Object = { name:DisplayObjectName, x:120, y:20 };
storeState(state);
Again, you will have to listen to all movement and changes if you want to record them.
Given an interface like
%feature("director") HeldBase;
%feature("smartptr") HeldBasePtr;
typedef SmartPtr<HeldBase> HeldBasePtr; // a minor wrapper around boost::shared_ptr
// Various typemaps that ensure Java-side HeldBase instances are always HeldBasePtr
class HeldBase {
public:
virtual void doSomething(int) = 0;
}
class Holder {
void hold(HeldBasePtr hb);
void release(HeldBasePtr hb);
void clear();
void process(int seconds);
}
Now some code implements the HeldBase, on the java side doing something like:
class MyHeldBase: extends HeldBase {
void doSomething(int i) { System.out.println("Hello whirled"); }
}
Holder h = new Holder();
HeldBase local = new MyHeldBase();
h.hold(new MyHeldBase());
h.hold(local);
h.process(1000000); // presumably doing something with the held things.
The underlying C++ layer deals with the smart pointers "properly", so (for example) destroying the Holder (swig proxy and underlying C++ object) correctly decrements the ref counts on the underlying smart pointers.
Right now the 'local' held base works fine, but the one without a reference held on the java-side gives a "null upcall" error presumably after some gc causes the java instance to go away.
I noticed the generated swigTakeOwnership and swigReleaseOwnership methods, and tracked them down in the code to be toggle whether a GlobalRef or GlobalWeakRef is held by the director. So I did some wrapper code so that calls to hold(HeldBase hb) called hb.swigReleaseOwnership() and release() called hb.swigTakeOwnership(). Looking at the code it seemed that swigReleaseOwnership would convert the underlying director ref to a GlobalRef (so that the C++ layer would hold ownership of the Java MyHeldBase). And vice-versa for swigTakeOwnership.
Unfortunately this didn't work for unrelated reasons... something in our typemaps have rendered the swigTakeOwnership and swigReleaseOwnership uncallable, because they (think they) hold HeldBase * not HeldBasePtr *.
If that is the right way to solve this problem, I'll try to track down why those methods are not being generated correctly. But I still feel like there are unresolved issues (that are hard to think about.)
For example, what about:
HeldBase local = new MyHeldBase()
Holder h1 = new Holder(); Holder h2 = new Holder();
h1.hold(local);
h2.hold(local);
h1.release(local)
local = null;
In this case, the call to swigReleaseOwnership() happens twice, but the second is a noop. When release() call swigTakeOwnership (making the reference back into a GlobalWeakRef) the java layer is once again "owning" and h2 will get a null upcall. Also, if calls to swigTakeOwnership ARE required, then Holder.clear() seems to mean I need to add code to hold all the passed java-extended directors (at which point I can just do that to manage their lifecycle).
It "feels" like when using smart pointers with directors, the C++ side of the director should always just use a GlobalRef and things will "just work" but OTOH it seems that is a memory leak there since then the C++ side will keep the Java proxy alive and vice-versa.
I have just been trying to fix a few memory leaks in my project and have discovered an interesting problem. It seems like a vast majority of my 'Point' objects are not being picked up by the Garbage Collector. Each frame it creates about 5000 new Point objects and less than 10% of them seem to ever get picked up. Even when you use code like this:
var tempPoint :Point = new Point();
tempPoint = null;
Even if I repeat it over 500 times, only a tiny fraction seem to be erased. This is really stating to get on my nerves now and I was wondering if anyone has encountered this before, knows how to solve it / get around it, or cares to enlighten me on what exactly I am doing wrong.
Would love to know anyone's thoughts on this
ps. I am using The Miner to check the resource usage
Edit: Have now done a quick check where I had the program running for about an hour and although the memory usage went up about 140MB it did start garbage collecting at this point and did not go past that. So they will be picked up but not until you have several million created ;)
How long are you waiting for them to be erased?
If you are creating 5000 new objects per frame, it's probably a good idea to use an object pool.
class PointPool {
private var _points:Vector.<Point>;
public function PointPool() {
_points = new Vector.<Point>();
}
public function createPoint(x:Number, y:Number):Point {
var p:Point = null;
if( _points.length > 0 )
p = _points.pop();
else
p = new Point();
p.x = x;
p.y = y;
return p;
}
public function returnPoint(point:Point):void {
_points.push(point);
}
}
Just a thought :)
I will quote Grant Skinner to answer your question:
A very important thing to understand about the Garbage Collector in FP9 is that it’s operations are deferred. Your objects will not be removed immediately when all active references are deleted, instead they will be removed at some indeterminate time in the future (from a developer standpoint).
[...]
It’s very important to remember that you have no control over when your objects will be deallocated, so you must make them as inert as possible when you are finished with them.
So, what's happened with your code? FP created something near 5000 instances of Point. If you look the memory usage over time you may notice that it will drop to the initial value after a few seconds.
The best way to avoid this behaviour is to pool the created objects and reuse them instead of creating a new one.
I'm using Chrome (Version 19.0.1084.46). I enabled the Gamepad API in chrome://flags. I plugged in some game pads, but navigator.webkitGamepads is always an array of length 4 containing only undefined.
navigator.webkitGamepads
GamepadList
0: undefined
1: undefined
2: undefined
3: undefined
length: 4
__proto__: GamepadList
What do I need to do to test out using gamepads? I'm on Ubuntu Linux if that matters.
I was having trouble with this as well (on Ubuntu 10.04 with Chrome 21.0.1163.0 dev). I ran across this from a thread on chromium-discussions:
Note that you need to press a face button on the gamepad before data
will be available. This is due to fingerprinting concerns.
I wrote a quick test page that seems to work if you hold a controller button down while refreshing the page. I'm using a Gamestop-branded Xbox 360 wired controller with the xboxdrv driver.
Also, one other important thing to note - Chrome treats these Gamepad objects like snapshots of the controller state. So if you pass around the actual Gamepad object, you'll never get updated information. Chrome seems to only poll the controller when you call the navigator.webkitGamepads[x] getter (see line 23 in my test page).
SPECIAL NOTE: The GamePad API is handled in two completely different ways by Firefox and Google Chrome. Because of this, you need to include code to test for your browser's identity, and handle the cases accordingly.
When the navigator.getGamePads() method is invoked, an array of objects is returned, and those objects contain information about the identity of your gamepads/joysticks, and the state of the axes/buttons thereof.
Here's the issue: on Firefox, the method hands the array to your calling code, and you can then examine that array repeatedly, to look for changes of axis/button state in your own code. Firefox behaves in the expected manner, and updates the objects you've received with new axis/button data, as and when it becomes available.
Google Chrome, on the other hand, treats the array totally differently. Chrome treats the array as a one-time snapshot of the status of your gamepads/joysticks, and if you want to fetch new data, you have to perform another invocation of navigator.getGamePads(), to fetch a new snapshot, discarding the old one.
As a consequence, you need something like this to make your code work on both browsers (assuming that the variable 'gp' is the variable in which you previously stored the return value from your first invocation of navigator.getGamePads() ...)
var ua = navigator.userAgent;
if (ua.toLowerCase().indexOf("chrome") != -1)
gp = navigator.getGamePads();
Why the two browsers behave so differently, is a topic for another thread, but I suspect it has much to do with the fact that the GamePad API is still somewhat experimental, and the fine detail of the standard applicable thereto has not yet been finalised.
In my case, running Chrome on Windows 7 64-bit (but the 32-bit version, for some strange reason best known to my computer's manufacturer, who installed it in this fashion), the array returned by navigator.getGamePads() currently contains only as many entries as there are actual gamepads/joysticks plugged into my computer. If you're experiencing something different on Chrome under Linux, then you need to take this into account also, by testing to see if you have any null values in the array.
Another factor to take into account, is that when selecting a gamepad/joystick, the standard in place calls for the index property of the GamePad object to be referenced, and used thereafter to index into the array. The reason for this is covered in more detail in this document:
W3C page : Editor's Draft on the GamePad interface
However, whilst the implementation of this works as documented above in my incarnation of Google Chrome, you may have to check your version experimentally to see if it behaves the same as mine. If it doesn't, adjust your code accordingly until such time as the standard is finalised, and proper conformity thereto is enforced in all modern browsers and all OS incarnations thereof.
So, when you're selecting a particular gamepad/joystick to work with, the code will look something like this (with the variable 'gid' as your index selector):
var gLen = this.gamePads.length;
done = false;
idx = 0;
while (!done)
{
if (this.gamePads[idx] !== null)
{
if (gid == this.gamePads[idx].index)
{
//Here, choose this GamePad as the selected GamePad, based upon the index number as per the W3C recommendation ...
selectedGamePadIndex = gid;
selectedGamePad = this.gamePads[idx];
done = true;
//End if
}
//End if
}
//Update counter in case we haven't selected one of the available GamePads above ...
idx++;
if (idx >= gLen)
done = true; //Exit loop altogether if we've exhausted the list of available GamePads
//End while
}
I actually implemented the above code (along with some tidying up at the end) as a method for a custom object, but the principle remains the same regardless of the implementation minutiae. (I'll confess at this juncture that I have a habit of writing my own short libraries to handle tasks like this!)
Another issue to watch out for, is the manner in which the gamepad API maps the physical data sources of your gamepad/joystick to the axis/button elements of the GamePad object, and the values contained therein. I have a Microsoft Sidewinder Pro USB joystick, and the mappings for this device on my computer are seriously weird, viz:
Axes 0/1: Joystick handle (as expected)
Axes 2/3: Not assigned
Axes 4/5: 4 not assigned, 5 assigned to twist grip
Axes 6/7: 6 assigned to round slider, 7 not assigned
Axes 8/9: 8 not assigned, 9 assigned to hat switch (er, WHAT???)
Yes, that's right, analogue axis 9 is assigned to the hat switch, and seriously odd values are returned, viz:
Hat switch centred: +1.2
Hat switch up: -1.0
Hat switch down: +0.1
Hat switch left: +0.7
Hat switch right: -0.42
Quirks like this are something you should be alert to as you experiment with the GamePad API. Even worse, a so-called "standard" GamePad (defined in that document I linked to above) may report as standard on some browsers, but not on others, or worse still, report as standard on browser X in Windows, but not on the same browser X in Linux! While this will induce much hair-tearing frustration as you try to fight your way through this software equivalent of bramble thicket, getting badly scratched by some of the thorns along the way, you can at least take comfort in the fact that browser developers are working to try and ameliorate this, but it'll take time, because other things take priority (such as making sure your browser doesn't become an easy target for ransomware to hijack, which will ruin you day immensely if it happens).
This didn't work for me but maybe it helps you? Pulled from here.
function updateStatus() {
window.webkitRequestAnimationFrame(updateStatus);
var gamepads = navigator.webkitGamepads;
var data = '';
for (var padindex = 0; padindex < gamepads.length; ++padindex)
{
var pad = gamepads[padindex];
if (!pad) continue;
data += '<pre>' + pad.index + ": " + pad.id + "<br/>";
for (var i = 0; i < pad.buttons.length; ++i)
data += "button" + i + ": " + pad.buttons[i] + "<br/>";
for (var i = 0; i < pad.axes.length; ++i)
data += "axis" + i + ": " + pad.axes[i] + "<br/>";
}
document.body.innerHTML = data;
}
window.webkitRequestAnimationFrame(updateStatus);
Or as a hard alternative, there's the Javascript Joystick Plug-in (demo here) but I don't think that works in Linux.