I’m confident if I looked through my old applications there must have been some float stuff. But the weirdest thing is this may exist only on specific devices.
Here is the entire project on my github if you want to take a look at it and see if it is really a device issue.
It seems to be related to materials, perhaps a new material is being created in the update.
Edit: I can see the joystick! That was it XD thanks
@BigBob said: @t0neg0dI’m confident if I looked through my old applications there must have been some float stuff. But the weirdest thing is this may exist only on specific devices.
Here is the entire project on my github if you want to take a look at it and see if it is really a device issue.
It seems to be related to materials, perhaps a new material is being created in the update.
Edit: I can see the joystick! That was it XD thanks
The value eventually alters the clipping which is a Vector4f. As far as I can figure with the testing I’ve been able to do with a friends phone now and then, it seems to revolve around casting int to float.
Were you able to run the update loop if you actually change the variable type of firelevel to float?
@BigBob said: @t0neg0dUnfortunately changing the wood and fireLevel to a float didn’t change anything
Ok… so… you can set the value outside of the update loop without a hitch… however, setting it within the update loop causes an oom exception on your device.
Lemme see what I can figure out with this.
int to float casting should not cause allocation as it’s low-level enough to have byte code for it. It should just be a stack operation.
If you see otherwise then it would be interesting to see the code so someone might spot the real issue. Int to float causing memory leaks really is one of those “abandon all hope” situations because if that’s not right then really nothing else is.
@BigBob said: @t0neg0dUnfortunately changing the wood and fireLevel to a float didn’t change anything
Ok… I think I see the issue (possibly… it’s another guess… but it looks promising)… I can’t test it and I likely won’t get an update for the plugin out until tomorrow night (surgery is at 1pm tomorrow… have to be at the hospital at 11… it supposed to take about 2-3 hours and then I’m home… out of it… in pain… but home). If you are using the repo to pull the library from, I can push out the update there and see if it works.
@BigBob said: @t0neg0dIf I can just get the jar I’m sure I can reference it properly.
Ok… I’m currently in the process of adding a bunch of additions for Android… like:
Fling scrolling,
Input scaling (this is neat because you can have your main activity scale the render area to say 85% of the actually resolution, then initialize your Jme app–happens in onCreate… not after the update loop). You can make up for lost performance by slightly scaling back the render size of your application and the screen class with scale the input in reverse. So… 50% of resolution = input.mult(2), etc.)
And a few other tricks that are useful and cool.
I’ll update the downloadable jar after I have made sure nothing is critically broken by the changes. =) I’ll post when it’s available.
Ok… you can grab it here:
https://sourceforge.net/projects/tonegodemitter/upload/
just add the jar as a library to your project (instead of the plugin for now)… and I’ll let you know when the plugin is updated with the changes available in this so you can set it back to the plugin.
EDIT: If this works, this very well may be the same issue I was seeing in the Galaga type game on the Note2. I took a look around for potential problem areas, but I’m not spotting this issue right off. Hopefully it is related at least. What I really need is about 3 solid hours to run tests on one the “special” devices to try each piece of the 2D frame work until I can narrow down where I made a mistake.
What’s killing me is, AnimElement is the basis for EVERYTHING in the framework… TextElement is backed by AnimElement as well. I’ve been able to use TextElement with no issues on the Note2 (though text is relatively static where animated stuff is constantly changing). I’m hoping that somewhere I am unintentionally triggering a shader recompile–which is what was happening in Indicator.
@BigBob said: @t0neg0dEdit: Found it and got it.
Same thing same error. It crashes
Argh… well… either way… the recompile was pointless and and not great on FPS. Ok… gonna look through your code again, see if I spot anything there (which is 99.9% not going to be the issue) and then go back the indicator.
Would you be willing to run another test for me? It’s pretty simple but will give me an idea of what the problem might be.
[java]
// Create an AlertBox
AlertBox alert;
boolean dir = true;
// in simple init
// first initialize your screen
alert = new AlertBox(screen, new Vector2f(screen.getWidth*(),screen.getHeight()));
// Set the message to some decent length string (something that invokes the vertical scroll bar
alert.setMsg(“Some really long string in here”);
// The run this as your simple update:
@Override
public void simpleUpdate(float tpf) {
dir = !dir;
if (dir) {
alert.resize(alert.getX()+400, alert.getY()+400, Borders.SE);
} else {
alert.resize(alert.getX()+200, alert.getY()+200, Borders.SE);
}
}
[/java]
This will adjust the clipping every update. Not sure why this would be any different than manually resizing the screen (which should work fine), but… at least it narrows it down to an issue with Vector4f usage.
I get AlertBox is abstract and cannot be instantiated.
O.O
Did I break something, Im fairly certain Im importing the right thing
@BigBob said: @t0neg0dI get AlertBox is abstract and cannot be instantiated.
O.O
Did I break something, Im fairly certain Im importing the right thing
Make sure the import is pointing to my library and not Nifty or something else. (I mean for AlertBox)
I also have the setMsg as setMessage (I updated above… sorry).
Use this instead:
[java]
alert = new AlertBox(screen, Vector2f.ZERO) {
@Override
public void onButtonOkPressed(MouseButtonEvent evt, boolean toggled) {
hideWithEffect();
}
};
alert.setWindowTitle(“Test Alert Box”);
alert.setMsg(“This is a test of the AlertBox Control.This is a test of the AlertBox Control.This is a test of the AlertBox Control.This is a test of the AlertBox Control.This is a test of the AlertBox Control.\n\nThis is a test of the AlertBox Control.This is a test of the AlertBox Control.This is a test of the AlertBox Control.\n\nThis is a test of the AlertBox Control.This is a test of the AlertBox Control.This is a test of the AlertBox Control.This is a test of the AlertBox Control.”);
alert.setButtonOkText(“Close”);
alert.setLockToParentBounds(true);
alert.setClippingLayer(alert);
alert.setMinDimensions(new Vector2f(150,180));
[/java]
Flashing alertbox working just fine on the upper left corner of the screen 
Closed and opened correctly
Resized like crazy
@BigBob said: @t0neg0dFlashing alertbox working just fine on the upper left corner of the screen
Closed and opened correctly
Resized like crazy
Thanks… this removed one of the possible problems from the list of things I need to check =) Ok… back on my head. I’ll post if/when I am able to find it… or have some other idea of what it may be.
