Back from vacation update...

I'm just back from a week vacation in Pennsylvania.  PA is beautiful... and remote.  SO, my connectivity was very limited.  While most of the days were full with my cousin's graduation, I was able to utilize some mornings for development.  I kept a log!  So, I'll dump that below to keep my development blog alive and well......

 

Wed June 3 - I’ve noticed that, even with the UI set to visibility false, I can still happen upon touching, and triggering the buttons.  So, I’ll need to make sure I dispose of the UI every time the app state switches between preview true and false, freeing up memory in the process.  

 

06-03 08:42:47.126: A/libc(25853): Pure virtual function called. Are you calling virtual methods from a destructor?

06-03 08:42:47.126: A/libc(25853): Fatal signal 6 (SIGABRT), code -6 in tid 25877 (GLThread 339867)

 

That’s a new one. I’m calling a virtual method from a destructor?  This is when I call dispose on SettingsModel.  I haven’t disposed for the stage.  It seemed to be causing some issue.  I should come back and try that some more. 

 

Next I guess, is getting the Helmet to load up it’s textures at startup, like everything else.  Though, the default GLSL shader is not doing anything with the normal map.  But, it's good to see Android doesn't mind that big of a texture map.  

Done!

June 4 - added AppDrawerShortcut!  That was easy.  Now, all you have to do is click the app icon and it takes you directly to the live wallpaper preference options.  Much better experience that digging through the settings menu for the wallpaper settings, selecting the UM Livewallpaper, etc, etc.... 

Now...I would love to get the dang Tilt Control working!

One main problem with using the accelerometer over the gyro is the spring-like sensor noise you get when moving the device quickly.... even slowly you see it.  It looks like crap, definitely not usable.  I've implemented a rudimentary low-pass filter function, while that helps (a lot), it's still not where I want it. The movement needs to be silky smooth but responsive enough that tilting the device directly reflects in the movement of the 3D scene.  I think I definitely need the gyro working.  But, libGDX doesn't even have the hardware sensor input available.  Looks like I get to extend the library.  Ahh the joy of open source!  

I need to try finding example source on github that does gyro or accelerometer smoothing well....  There is mind melting math involved... ouch, brain hurts.

Try getting at least the gyro input in on the device.. You’ll have to extend the library, which means you need to sync up.  You’ll actually need to fork and download!  So, you’ll need to find some bandwidth somewhere.

I tried the local wifi, and found all of 2-4 KB/second.  How about that, huh!?!?  Sub-dial-up speeds in 2015, sad.  Thank you for the giggle Dish Network!

I wound up using my 4G Verizon bandwidth to pull down the fork.  But, that swallowed up my entire data bandwidth.  Bummer! 

You also need to figure out the dang shader.  You have something from ThreeJS what WILL work.. you just need to completely rehash the whole damn shader… JOY.

 

June 5:  I’ve cloned a new instance of libGDX from my “snovak” account on github, with the intent of extending the framework with gyroscope capability.  

I’ve updated AndroidInput.java, the IDE seems happy, but I can’t say wether or not I’ll see anything useful on the device side.

 

I should stick in some output log points to see if I’m actually getting the gyro input values.  So far, I’m just mimicking the accelerometer implementation, which I hope will get me close on the first run through.  I only intend on exposing raw sensor input.  

 

That done, I see a bunch of errors in the IDE.  Input.getGyroscopeX, Input.getGyroscopeY, Input.getGyroscopeZ need implementation in all other parts of the library that implements the input sensors.  No worries.

Description Resource Path Location Type

The type GwtInput must implement the inherited abstract method Input.getGyroscopeX() GwtInput.java /gdx-backends-gwt/src/com/badlogic/gdx/backends/gwt line 40 Java Problem

The type GwtInput must implement the inherited abstract method Input.getGyroscopeY() GwtInput.java /gdx-backends-gwt/src/com/badlogic/gdx/backends/gwt line 40 Java Problem

The type GwtInput must implement the inherited abstract method Input.getGyroscopeZ() GwtInput.java /gdx-backends-gwt/src/com/badlogic/gdx/backends/gwt line 40 Java Problem

The type GwtTestWrapper.InputWrapper must implement the inherited abstract method Input.getGyroscopeX() GwtTestWrapper.java /gdx-tests/src/com/badlogic/gdx/tests/gwt line 209 Java Problem

The type GwtTestWrapper.InputWrapper must implement the inherited abstract method Input.getGyroscopeY() GwtTestWrapper.java /gdx-tests/src/com/badlogic/gdx/tests/gwt line 209 Java Problem

The type GwtTestWrapper.InputWrapper must implement the inherited abstract method Input.getGyroscopeZ() GwtTestWrapper.java /gdx-tests/src/com/badlogic/gdx/tests/gwt line 209 Java Problem

The type IOSInput must implement the inherited abstract method Input.getGyroscopeX() IOSInput.java /gdx-backend-robovm/src/com/badlogic/gdx/backends/iosrobovm line 62 Java Problem

The type IOSInput must implement the inherited abstract method Input.getGyroscopeY() IOSInput.java /gdx-backend-robovm/src/com/badlogic/gdx/backends/iosrobovm line 62 Java Problem

The type IOSInput must implement the inherited abstract method Input.getGyroscopeZ() IOSInput.java /gdx-backend-robovm/src/com/badlogic/gdx/backends/iosrobovm line 62 Java Problem

The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files IOSRobovmTests.java /gdx-tests-iosrobovm/src/com/badlogic/gdx/tests line 1 Java Problem

The type JglfwInput must implement the inherited abstract method Input.getGyroscopeX() JglfwInput.java /gdx-backend-jglfw/src/com/badlogic/gdx/backends/jglfw line 48 Java Problem

The type JglfwInput must implement the inherited abstract method Input.getGyroscopeY() JglfwInput.java /gdx-backend-jglfw/src/com/badlogic/gdx/backends/jglfw line 48 Java Problem

The type JglfwInput must implement the inherited abstract method Input.getGyroscopeZ() JglfwInput.java /gdx-backend-jglfw/src/com/badlogic/gdx/backends/jglfw line 48 Java Problem

The type LwjglAWTInput must implement the inherited abstract method Input.getGyroscopeX() LwjglAWTInput.java /gdx-backend-lwjgl/src/com/badlogic/gdx/backends/lwjgl line 65 Java Problem

The type LwjglAWTInput must implement the inherited abstract method Input.getGyroscopeY() LwjglAWTInput.java /gdx-backend-lwjgl/src/com/badlogic/gdx/backends/lwjgl line 65 Java Problem

The type LwjglAWTInput must implement the inherited abstract method Input.getGyroscopeZ() LwjglAWTInput.java /gdx-backend-lwjgl/src/com/badlogic/gdx/backends/lwjgl line 65 Java Problem

The type LwjglInput must implement the inherited abstract method Input.getGyroscopeX() LwjglInput.java /gdx-backend-lwjgl/src/com/badlogic/gdx/backends/lwjgl line 59 Java Problem

The type LwjglInput must implement the inherited abstract method Input.getGyroscopeY() LwjglInput.java /gdx-backend-lwjgl/src/com/badlogic/gdx/backends/lwjgl line 59 Java Problem

The type LwjglInput must implement the inherited abstract method Input.getGyroscopeZ() LwjglInput.java /gdx-backend-lwjgl/src/com/badlogic/gdx/backends/lwjgl line 59 Java Problem

The type MockInput must implement the inherited abstract method Input.getGyroscopeX() MockInput.java /gdx-backend-headless/src/com/badlogic/gdx/backends/headless/mock/input line 28 Java Problem

The type MockInput must implement the inherited abstract method Input.getGyroscopeY() MockInput.java /gdx-backend-headless/src/com/badlogic/gdx/backends/headless/mock/input line 28 Java Problem

The type MockInput must implement the inherited abstract method Input.getGyroscopeZ() MockInput.java /gdx-backend-headless/src/com/badlogic/gdx/backends/headless/mock/input line 28 Java Problem

The type RemoteInput must implement the inherited abstract method Input.getGyroscopeX() RemoteInput.java /gdx/src/com/badlogic/gdx/input line 50 Java Problem

The type RemoteInput must implement the inherited abstract method Input.getGyroscopeY() RemoteInput.java /gdx/src/com/badlogic/gdx/input line 50 Java Problem

The type RemoteInput must implement the inherited abstract method Input.getGyroscopeZ() RemoteInput.java /gdx/src/com/badlogic/gdx/input line 50 Java Problem

 

So far, I’m just mimicking the accelerometer implementation, which I hope will get me close on the first run through.  

Follow the trail of unimplemented functions, and implement them. 

Done.  IDE seems happy now.

This is the current path for the gdx-backend-android file.  

 

/Users/snovak/.gradle/caches/modules-2/files-2.1/com.badlogicgames.gdx/gdx-backend-android/1.5.5/8344027a50c825bc4162070d34bb2a31cf195a4a/gdx-backend-android-1.5.5-sources.jar

 

I need to do one of two things.  

  1. I need to create some sort of test to run on my phone to test the gyro input in the snovak/libgdx project.
  2. I need to redirect the gdx-backend-android jar to my generated jar file in UM3DLWP, I’ll need some guidance there to do it correctly because I'm not certain of how do I safely override the default library package?  

#2 sound like a decent option since I can test it directly with my project, and I’m making continued progress.  Down side is, each time I iterate, I have to recompile and overwrite the jar(s) again and possibly relink it to the project...  Slowing development.  But, I think the upside of testing directly with my project, not having to come up with a standalone test, is good.  

 

Notes:

ant -f fetch.xml

ant

This will first fetch the latest native libraries (compiled C/C++ code for all platforms) from the build server so you don't have to build them yourself. Next it will invoke the main build script to build all the Java parts.

The end result is a zip file called libgdx-version.zip and a folder called dist containing the expanded contents of the zip file, which will essentially be the same as the one you can get from the nightly build server, plus any modifications you made to the source.

The build.xml file has targets for every module. Each target configures a few properties (classpath, output directory, etc.) which are then send as input to the build-template.xmlfile. The build-template.xml is then responsible for compiling the Java source code as well as the native source code. The later is done by invoking an Ant script calledbuild.xml in the jni/ folder of the module. If you use the above method to compile the native builds will not be executed. See below for info on how to compile the native sources.

Since building from source isn’t really going to happen until I get a real internet connection.  I’ll do that at home. 

But, you can move on to modeling Sebastian!!!  So, that’s what you should knock out the rest of the time in PA.  While in PA, modeled two solid mornings and took screenshots along the way.  The head is looking great!  

June 10 @ 7am

 

June 10 @ 10am

June 12 @ 8am

Looking good.  I'm happy with the progress.  I'm eager to get home, finish, and get Sebastian into the app!!

Meanwhile, I've had the live wallpaper installed on my phone for several weeks now.  I notice 0 additional draw on my battery.  When I look into the battery stats, the live wallpaper isn't even ranked/displayed in those readouts.  Bonus!

Here's a screenshot how the app currently looks on the device, with my favorite settings applied so far.  You can see the icon there as well.  Looking good.  smiley

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters shown in the image.