TDWorld Development Thread

Networking & Multiplayer
#41

Working on my “nautical” to “game-world” space translation bounding box checks, created a fun to look at visualization. You can see toward the bottom of the map the bounding box checks return the wrong result. Debugging that. This is all part of the “get the attacks on the server and client synchronized”.

visualize-test-results
visualize-test-results1912×934 128 KB

If we increase the number of testing points, we can see more patterns (as well as the problem not just near the bottom of the map):

visualize-test-results-2
visualize-test-results-21857×932 477 KB

EDIT:

We can look at the data and see that latitude normalization is broken - oops!

lat: 90.0 lng:180.0 32767.0 -5188.264000000003
lat: 80.0 lng:180.0 32767.0 3678.4840000000004
lat: 70.0 lng:180.0 32767.0 7333.518292682926
lat: 60.0 lng:180.0 32767.0 9515.18472222222
lat: 50.0 lng:180.0 32767.0 11113.903887688986
lat: 40.0 lng:180.0 32767.0 12405.718041704444
lat: 30.0 lng:180.0 32767.0 13519.735417919423
lat: 20.0 lng:180.0 32767.0 14525.581378163679
lat: 10.0 lng:180.0 32767.0 15469.878889378582
lat: 0.0 lng:180.0 32767.0 16385.0
lat: -10.0 lng:180.0 32767.0 17298.121110621418
lat: -20.0 lng:180.0 32767.0 18242.41862183632
lat: -30.0 lng:180.0 32767.0 19248.264582080577
lat: -40.0 lng:180.0 32767.0 20362.281958295556
lat: -50.0 lng:180.0 32767.0 21654.096112311014
lat: -60.0 lng:180.0 32767.0 23252.81527777778
lat: -70.0 lng:180.0 32767.0 25434.481707317074
lat: -80.0 lng:180.0 32767.0 29089.516
lat: -90.0 lng:180.0 32767.0 27577.735999999997

2 Likes
#42

Yay!

visualize-test-results-3
visualize-test-results-31897×937 1.04 MB

(blue dots mean match is correct)

Trying out a different algorithm. Looks good so far. Have to finish fixing my tests from ripping out the old RTree library and then will see if client can predict attacks on server within 10% yet.

5 Likes
#43

Nice.
java.lang.ArrayIndexOutOfBoundsException: 420

#44

Update video coming soon.
Another milestone reached.
Attacks and creep movement between server and client is within 1% accuracy (tested over 30mins so far). Only took working from like 9AM to 8:30PM on a Sunday…

[com.winricklabs.tdworld.util.CreditSyncDebugger] Credit delta, Server=[1500] Client=[1495] Accuracy=[100.33444816053512]
[com.winricklabs.tdworld.util.CreditSyncDebugger] Credit delta, Server=[1500] Client=[1500] Accuracy=[100.0]

Creep movement has also been “smoothed” on the client. Before it would appear that the creeps moved one “step” and then stopped and moved again. The interpolation has been improved, so there’s no stopping now.

2 Likes
#45

Some days are like that!

1 Like
#46

Indeed!
Up next is testing building for Android and iOS, and adding the “location based” aspect so that moving your phone around changes your view into the world.

1 Like
#47

Trying to build for Android, anyone ever get this?
I’ve tried clearing Gradle cache, Invalidate/Restart IDE, played with the activity class path…

Activity class {com.winricklabs.tdworld/com.winricklabs.tdworld.AndroidLauncher} does not exist.

Verified these items: https://github.com/facebook/react-native/issues/14952#issuecomment-314683712

#48

Tried my other computer. I can’t get gradle to run the Android build with Intellij 2020.2, Gradle 6.1.1., and Java 1.8.

I get this:

Could not open cp_init remapped class cache for bl3ndxec306ta9f2jnqm0ilm3 (C:\Users\winri\.gradle\caches\6.1.1\scripts-remapped\ijresolvers_82otrqblfrs7r0ll85yaxma37\bl3ndxec306ta9f2jnqm0ilm3\cp_init3607aee355f62839c5e6f549478ccc87).
Could not open cp_init generic class cache for initialization script 'C:\Users\winri\AppData\Local\Temp\ijresolvers.gradle' (C:\Users\winri\.gradle\caches\6.1.1\scripts\bl3ndxec306ta9f2jnqm0ilm3\cp_init\cp_init3607aee355f62839c5e6f549478ccc87).
Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7

Gradle/Java version:

C:\Users\winri\Documents\GitHub\tdworld-libgdx>gradlew --version

------------------------------------------------------------
Gradle 6.1.1
------------------------------------------------------------

Build time:   2020-01-24 22:30:24 UTC
Revision:     a8c3750babb99d1894378073499d6716a1a1fa5d

Kotlin:       1.3.61
Groovy:       2.5.8
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          1.8.0_265 (Eclipse OpenJ9 openj9-0.21.0)
OS:           Windows 10 10.0 amd64
#49

One piece of advice was to rebuild the android submodule. Trying to do so via right click -> rebuild in Intellij gives me:

Execution failed for task ':core:clean'.
> java.io.IOException: Unable to delete directory 'C:\Users\winrid\Documents\tdworld-libgdx\core\build'
    Failed to delete some children. This might happen because a process has files open or has its working directory set in the target directory.
    - C:\Users\winrid\Documents\tdworld-libgdx\core\build\libs\core-1.0.jar
    - C:\Users\winrid\Documents\tdworld-libgdx\core\build\libs

Not sure yet what is using files in that directory.
It feels like this stuff is fighting me every step of the way…

EDIT: Was able to stop the gradle daemon:

 WMIC PROCESS where "Name like 'java%' AND CommandLine like '%GradleDaemon%'" Call Terminate

Then delete the “build” directory with Intellij closed.
Now it builds with the warning:

WARNING: Compatible side by side NDK version was not found. Default is 21.0.6113669.
Compatible side by side NDK version was not found. Default is 21.0.6113669.
Unable to strip the following libraries, packaging them as they are: libgdx-box2d.so, libgdx-bullet.so, 
libgdx-freetype.so, libgdx.so.
Compatible side by side NDK version was not found. Default is 21.0.6113669.

EDIT
And it still doesn’t run, I still get:

Starting: Intent { cmp=com.winricklabs.tdworld/.AndroidLauncher }
Error type 3
Error: Activity class {com.winricklabs.tdworld/com.winricklabs.tdworld.AndroidLauncher} does not exist.
#50

Thanks to myke on the libgdx Discord server I found that it does work via the terminal:

gradlew android:installDebug android:run

Why must you do this to us Intellij/Gradle?

Anyway after that I got this fun error at runtime:
java.lang.NoSuchMethodError: No static method metafactory(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String

Had to go back to Java 1.8 in my system’s PATH… when will libgdx support a version newer than 1.8, I wonder.

#51

As an Android developer myself, I can say that it has nothing to do with LibGDX. It is caused by the Android SDK itself which doesn’t support Java 9+. They might have updated, but then there is a court case running between Oracle and Google and hence they couldn’t update.

If you must use Java 9+, I suggest trying out any AOT solutions (Azul has got one I guess, not sure) and run it using NDK (Native Development Kit). Another easier option is to move to Kotlin, so you can have all the latest language features and yet compile to native SDK.

#52

Great follow up and information, thanks!

1 Like
#53

The game is now fully location based, with the camera at the ground, and orientation based on the device, for Android.

Going to get iOS working next, then likely will be working on the animation to zoom out to strategic view, and finally starting to put the UI together.

2 Likes
#54

I’ve noticed a pretty frequent flicker on Android, which I’m thinking is the GC, so investigating that today hopefully.

#55

The camera can now be animated into different positions! This will be used for jumping out to “strategic” view:

            Vector3 position = new Vector3(currentPosition.x, cameraY, currentPosition.y);
            Vector3 endPosition = new Vector3(currentPosition.x, 3.5f, currentPosition.y);
            float animationTargetRunTime = 2000f;
            animationLoopRunner.addJob(new AnimationJob(animationTargetRunTime, (duration, isDone) -> {
                position.interpolate(endPosition, duration / animationTargetRunTime, Interpolation.smooth);
                cameraY = position.y;
                perspectiveCamera.position.set(position.x, position.y, position.z);
                perspectiveCamera.lookAt(currentPosition.x, 0, currentPosition.y);
                if (isDone) {
                    handleViewPortChange();
                }
            }));
1 Like
#56

Was trying to see why the strategic view crashes with my flagship phone (S20+ Ultra).

tdworld-strategic-dense-city
tdworld-strategic-dense-city1397×774 90.3 KB

Oof!!

Have some work to do :slight_smile:

#57

Much better!

tdworld-strategic-dense-city-2
tdworld-strategic-dense-city-21219×805 82.3 KB

1 Like
#58

Had a try/catch in my main render loop, which I didn’t like. I’d at least like to go through that again before launch and see what issues I’m masking. I think the last issue is this, not sure why the DefaultRenderableSorter is not comparing consistently…:

2020-11-01 15:45:17.581 26210-26266/com.winricklabs.tdworld E/AndroidRuntime: FATAL EXCEPTION: GLThread 100875
    Process: com.winricklabs.tdworld, PID: 26210
    java.lang.IllegalArgumentException: Comparison method violates its general contract!
        at com.badlogic.gdx.utils.TimSort.mergeHi(TimSort.java:791)
        at com.badlogic.gdx.utils.TimSort.mergeAt(TimSort.java:449)
        at com.badlogic.gdx.utils.TimSort.mergeCollapse(TimSort.java:387)
        at com.badlogic.gdx.utils.TimSort.doSort(TimSort.java:129)
        at com.badlogic.gdx.utils.Sort.sort(Sort.java:59)
        at com.badlogic.gdx.utils.Array.sort(Array.java:424)
        at com.badlogic.gdx.graphics.g3d.utils.DefaultRenderableSorter.sort(DefaultRenderableSorter.java:36)
        at com.badlogic.gdx.graphics.g3d.ModelBatch.flush(ModelBatch.java:198)
        at com.badlogic.gdx.graphics.g3d.ModelBatch.end(ModelBatch.java:218)

EDIT: I think I’ve fixed this by ensuring disposed entities are not rendered, but we’ll see.

#59

I’m still a little worried about memory usage, and am seeing 400-600mb used just by “Native” when running on Android, so debugging that to see what things I’m rendering are causing such high native memory usage. The memory usage by my code directly is in the 2-300mb range so far in testing.

#60

So, I did a dumb thing. I replaced some “Vector3.dst” calls with “.dst2”, which caused much more data to be loaded into the viewport (basically beyond what I could see) because the calculation is different. Now native memory usage tops out at 200mb in strategic view, vs 600mb before… :slight_smile:

1 Like