I'm creating and android game powered by andengine framework the box2d extension
I'm getting "Fatal Signal 11" which seems to happen out of nowhere (I guess you can call it randomly)
there no clues (at least, I don't aware to any clues to help me solve this problem)
my guesses are:
1) I'm creating game's entities using TimerTask class
2) maybe it has something to do with concurrency?
what do you think?
thanks,
socksocket
You could still use a TimerTask, you just need to be sure to call anything relating to AndEngine (creating or deleting sprites, etc) on the AndEngine update thread - you can use
runOnUpdateThread(new Runnable() {
#Override
public void run() {
// TODO Auto-generated method stub
// do your stuff in here
}
});
I had the same issue and fixed it by taking the TimerTask out of the equation.
it says touchEvent...maybe you set your density value of your FixtureDef too high....
try to set the density value <=1000 like below:
FixtureDef wallFixtureDef = PhysicsFactory.createFixtureDef(1000, 0.0f, 1.0f);
Body mGoundBody=PhysicsFactory.createBoxBody(this.mPhysicsWorld, ground, BodyType.StaticBody, wallFixtureDef);
hope this information can help you...
Related
Been testing a new system for increasing/decreasing the audio within my JavaSwing application using a fade in and fade out effect. This works on one hand though by doing my own research, it's not as optimal as one hoped to be since it utilizes Thread.sleep(x); rather than using Timer(); from JavaSwing.
FloatControl gainControl = (FloatControl) clip.getControl(FloatControl.Type.MASTER_GAIN);
value = (value <= 0.0) ? 0.0001 : ((value > 1.0) ? 1.0 : value);
try {
float db = (float) (Math.log(percent) / Math.log(10.0) * 20.0);
gainControl.setValue(db);
} catch (Exception ex) {
ex.printStackTrace();
}
}
public static void shiftVolumeTo(double value) {
value = (value <= 0.0) ? 0.0001 : ((value > 1.0) ? 1.0 : value);
targetDB = (float)(Math.log(value)/Math.log(10.0)*20.0);
if (!fading) {
Thread t = new Thread();
t.start();
}
}
public static void run() {
FloatControl gainControl = (FloatControl) clip.getControl(FloatControl.Type.MASTER_GAIN);
fading = true;
if(currDB > targetDB) {
while (currDB > targetDB) {
currDB -= fadePerStep;
gainControl.setValue(currDB);
try {
Thread.sleep(10);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
} else if (currDB < targetDB) {
while(currDB < targetDB) {
currDB += fadePerStep;
gainControl.setValue(currDB);
try {
Thread.sleep(10);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
fading = false;
currDB = targetDB;
}
public static void volTest() {
setVolume(1);
shiftVolumeTo(.2);
run();
}
Again, this works properly when run(); is called, but it puts the entire application to sleep within the duration of the while loop's runtime. Which is what I'm having an issue with. I've tried setting up a JavaSwing Timer(); within the code though I couldn't figure out how to set it up properly to make the delay run like the Thread.sleep(x); method. Whether it is adding the code from run(); into the ActionListener created or utilized by the timer or just having run(); within the ActionListener. Unlike Thread.sleep(x);, the program will just jump values without taking it's time to decrease the volume as there's no delay between the incremental increase/decrease of the while loop.
What would be the optimal way to utilize a JavaSwing Timer(); that would work similar to a Thread.sleep(x); in this situation?
I'm not clear what you are doing from the given code. I suspect you are mixing up aspects of the util.Timer with the swing.Timer (not uncommon).
With the util.Timer, one extends TimerTask, and within that, one overrides the run() method. The run() method is never static, afaik.
With the swing.Timer, the code to be executed resides in the actionPerformed() method of the ActionListener.
Another alternative, and likely a better way to manage the separate thread would be to use a ScheduledThreadPoolExecutor.
I'd consider using the util.Timer in this case. I think the calls to change the value of the FloatControl could be set up to be thread safe if you are careful about limiting the calls to a single sound at a time. (Here is a link for more about Swing's Event Dispatch Thread) It would be necessary to use the swing.Timer if thread safety is an issue.
But you understand here that you can only fade in or out a single sound at a time, and ALL sounds playing at that moment will also be affected? The FloatControl.MASTER_GAIN controls all playing sounds. Also, I don't think there are no guarantees that the FloatControls are implemented on a given computer. There are many listed in the documentation that I have discovered do not function on various PCs I own.
Another issue is that sometimes it can be difficult to find the best interval for the updates and corresponding amount to vary the volume. Sometimes we get as soft, fast sequence of clicks, like the sound of scraping a thumbnail over the tines of a comb, if the individual volume changes are too large.
I'd like to mention a library for you to consider that bypasses the use of the FloatControl: AudioCue. The class is basically a rewrite of the Clip but with a built in, dynamic, volume controller. When you alter the volume of a given playback instance, it will only affect that single instance. (The class supports playing back concurrent instances.) All the amplitude computations are done internally, within the code of the class.
The library can be run as a Maven resource. The project is a work in progress: I've just added a lot of test code that I'm about to push to the master. I'm working to publish it on Maven Central. (Learning as I go.) But if you fork the project and run the Maven install command, it will create a resource that you can reference locally via the Maven pom file.
I'm considering adding an optional duration argument to the dynamic controls. Then (if implemented) one could specify both the desired volume and the number of frames or milliseconds over which the change should be applied. Seems like a good addition for version 1.2 (after 1.1 is up on Maven central!)
With AudioCue, changes are applied per individual frames. I'm not sure what the situation is with FloatControl and Clips. The changes might be limited in granularity to some internal buffer size.
I'm using a JOGL FPSAnimator and Apple's FullScreenUtilies class. I implemented this some time ago, and it worked fine. Here is my code for enabling the native OS X fullscreen capability, similar to other code on SO and around the web:
String className = "com.apple.eawt.FullScreenUtilities";
String methodName = "setWindowCanFullScreen";
try {
Class<?> clazz = Class.forName(className);
Method method = clazz.getMethod(methodName,
new Class<?>[] { Window.class, boolean.class });
method.invoke(null, frame, true);
} catch ...
It also works fine in the context of a simple test program I made in an attempt to isolate the issue. I'm not sure at what point the behaviour changed - I haven't spotted anything incriminating in SVN logs. It's likely that I first implemented the feature on an earlier version of OS X, and have also upgraded JOGL version and MyDoggy which we use for docking since. However, all of these things work with fullscreen in the context of other applications.
When I press the green fullscreen button, the usual OSX fullscreen transition starts (it gets its own desktop space), but the window appears frozen from that point on.
The main AWT Event thread carries on running, and I can see that my GLEventListener.display() method is being regularly called. I've tried adding a return to the beginning of that method to eliminate the impact of my rendering code, this unsurprisingly made no difference.
For testing purposes, I added a FullScreenListener:
FullScreenUtilities.addFullScreenListenerTo(frame, new FullScreenAdapter() {
#Override
public void windowEnteringFullScreen(FullScreenEvent arg0) {
log(">>> Entering fullscreen... <<<");
}
#Override
public void windowEnteredFullScreen(FullScreenEvent arg0) {
log(">>> Entered fullscreen. <<<");
}
});
As anticipated, I get the entering fullscreen event, but not the entered one.
It's a fairly large program, but there should be a fairly small surface of things that are potentially relevant here... unfortunately I haven't managed to trace them down. Happy if anyone has any pointers.
My project is trying to implement java processing.core.Papplet to display a graphics with different color( Random color changing by times). It is so weird that I can only use:
applet.mousePressed();
to refresh my applet.
And I also tried:
applet.redraw();
applet.updatePixels();
applet.loop();
applet.redraw();
applet.noLoop();
applet.redraw();
applet.draw();
But neither of them works in my project. This means I can refresh my Papplet by either Robot mouse click or mouse click to make my applet refresh.
Does anybody know what's going on?
Appreciate for your great help.
BTW, I have tried the invoke method:
SwingUtilities.invokeLater(new Runnable(){
#Override
public void run() {
// TODO Auto-generated method stub
target.refresh();
previewController.render(target);
applet.redraw();
}
});
It can force flash the applet, but with some error image. I don't know what's going on with Papplet mousePressed.
I know this is an error with accessing memory outside the readspace but i have absolutely no idea how to fix this. I'm new to android, so i don't exactly know how to print out a more detailed error list from logcat in eclipse. I've tried everything from disposing literally everything, to calling System.gc to setting all my variables to null. However, whenever i switch screens the fatal signal occurs. I just need someone to tell me what exactly is going on or how i could get more details about the error.
I had the same error, what solved it was to make sure i'm on the UI thread, like this:
Gdx.app.postRunnable(new Runnable() {
#Override
public void run() {
// Your crashing code here
}
});
In my case i received same error when i try to create a new body and attach it's fixture, from beginContact (inside Contact Listener). After i moved outside Contact Listener my body creation everything was ok. Probably some conflict appears in Fixture createFixture (FixtureDef def) because according to manual: Contacts are not created until the next time step.
I'm using a Service that displays a view using WindowManager, and animation occurs every time I change the view's size using
windowManagerLayoutParams.height = newHeight;
((WindowManager) getSystemService(WINDOW_SERVICE)).updateViewLayout(mMainLayout, windowManagerLayoutParams);
If I disable manually the scale animations, no animation occurs.
Scale animation disabled manually like so:
http://www.cultofandroid.com/11143/android-4-0-tip-how-to-find-and-disable-animations-for-a-snappier-experience/
Is there a way to disable the window scale animations for my application programmatically?
I just had this same problem while working on a system overlay in the SystemUI package and decided to dig through the source to see if I could find a solution. WindowManager.LayoutParams has some hidden goodies that can solve this problem. The trick is to use the privateFlags member of WindowManager.LayoutParams like so:
windowManagerLayoutParams.privateFlags |= 0x00000040;
If you look at line 1019 of WindowManager.java you'll see that 0x00000040 is the value for PRIVATE_FLAG_NO_MOVE_ANIMATION. For me this did stop window animations from occurring on my view when I change the size via updateViewLayout()
I had the advantage of working on a system package so I am able to access privateFlags directly in my code but you are going to need to use reflection if you want to access this field.
As #clark stated this can be changed using reflection:
private void disableAnimations() {
try {
int currentFlags = (Integer) mLayoutParams.getClass().getField("privateFlags").get(mLayoutParams);
mLayoutParams.getClass().getField("privateFlags").set(mLayoutParams, currentFlags|0x00000040);
} catch (Exception e) {
//do nothing. Probably using other version of android
}
}
Did you try Activity#overridePendingTransition(0, 0)?
Check out the documentation:
Call immediately after one of the flavors of startActivity(Intent) or finish() to specify an explicit transition animation to perform next.