[Mark SiblyKeymaster]

Note: I do have a DK2 and tried to get it working recently with ‘open vr’ (the vive/valve API) but with no joy – apparently a known issue. Next step is to try the oculus api I guess, but I am less excited about that due oculus’ ‘walled garden’ approach, although I’m not not really sure what the ramifications are for publishers actually, maybe nothing?

[Mark SiblyKeymaster]

You only have to open the project once in android studio. After that you can just alt-tab between ted2go and android studio, building in one, running in the other. Ditto with xcode.

This way, you can modify the project, change test devices, sign builds easily, get nice logcat output with filtering and maybe even c++ debugging once I work out how! And the next time google break everything, you’re still good to go.

Up to you of course, but I found the whole command line build/debug process really crappy. Maybe its easier if you know what yer doing though!

[Mark SiblyKeymaster]

I would love to but don’t currently posses a usable VR unit.

I could get a stero display going I guess, but the units do all sort of other fancy crap these days too like time/space warp and the barrel distortion.

[Mark SiblyKeymaster]

Ok, cheers, turns out Texture.Flags setter was completely borked – getting some nice ‘outrun’ style pixels now!

I’ll also add a textureFlags param to SpriteMaterial.Load, but being able to modify flags is way cool.

[Mark SiblyKeymaster]

Just having a play with sprites…

How do you set the texture flags on a sprite? Setting the flags on SpriteMaterial.ColorTexture didn’t have an effect.

This should work, which flags were you trying to use.

[Mark SiblyKeymaster]

I just tried the PromptInvasion banana on an x86 emulator running lollipop (api 21) again and all is still fine here.

I’ve posted the ‘view details’ output from the virtual device manager below. You could perhaps try to create an identical virtual device and run PromptInvasion on it.

Also, your env_windows.txt file has MX2_ANDROID_APP_PLATFORM=20 which looks unusual and is not what I have here (android-14). Any reason you changed this? Have you tried MX2_ANDROID_APP_PLATFORM=android-14? you’ll need to rebuild all modules etc, and delete any .products files.

And that’s me about out of ideas, sorry.

Emulator details (mostly default settings):

Monkey

Name: Nexus_5X_API_21 CPU/ABI: Intel Atom (x86) Path: D:\devtools\Android\.android\avd\Nexus_5X_API_21.avd Target: default [] (API level 21) Skin: nexus_5x SD Card: 100M hw.dPad: no runtime.network.speed: full hw.accelerometer: yes hw.device.name: Nexus 5X vm.heapSize: 256 skin.dynamic: yes hw.device.manufacturer: Google hw.gps: yes hw.initialOrientation: Portrait image.androidVersion.api: 21 hw.audioInput: yes image.sysdir.1: system-images\android-21\default\x86\ tag.id: default showDeviceFrame: yes hw.camera.back: emulated hw.mainKeys: no AvdId: Nexus_5X_API_21 hw.camera.front: emulated hw.lcd.density: 420 avd.ini.displayname: Nexus 5X API 21 hw.gpu.mode: auto hw.device.hash2: MD5:1be89bc42ec9644d4b77968b23474980 hw.ramSize: 1536 hw.trackBall: no PlayStore.enabled: false hw.battery: yes hw.cpu.ncore: 2 hw.sdCard: yes tag.display: runtime.network.latency: none hw.keyboard: yes hw.sensors.proximity: yes disk.dataPartition.size: 800M hw.sensors.orientation: yes avd.ini.encoding: UTF-8 hw.gpu.enabled: yes

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

Name: Nexus_5X_API_21 CPU/ABI: Intel Atom (x86) Path: D:\devtools\Android\.android\avd\Nexus_5X_API_21.avd Target: default [] (API level 21) Skin: nexus_5x SD Card: 100M hw.dPad: no runtime.network.speed: full hw.accelerometer: yes hw.device.name: Nexus 5X vm.heapSize: 256 skin.dynamic: yes hw.device.manufacturer: Google hw.gps: yes hw.initialOrientation: Portrait image.androidVersion.api: 21 hw.audioInput: yes image.sysdir.1: system-images\android-21\default\x86\ tag.id: default showDeviceFrame: yes hw.camera.back: emulated hw.mainKeys: no AvdId: Nexus_5X_API_21 hw.camera.front: emulated hw.lcd.density: 420 avd.ini.displayname: Nexus 5X API 21 hw.gpu.mode: auto hw.device.hash2: MD5:1be89bc42ec9644d4b77968b23474980 hw.ramSize: 1536 hw.trackBall: no PlayStore.enabled: false hw.battery: yes hw.cpu.ncore: 2 hw.sdCard: yes tag.display: runtime.network.latency: none hw.keyboard: yes hw.sensors.proximity: yes disk.dataPartition.size: 800M hw.sensors.orientation: yes avd.ini.encoding: UTF-8 hw.gpu.enabled: yes

[Mark SiblyKeymaster]

Have you updated to latest Android Studio, NDK etc?

Everything works fine here on both my nvidia shield and the emulator.

How have you configured the emulator?

Can you perhaps send me a zip of the Android Studio project somehow?

[Mark SiblyKeymaster]

Please try monkey2 v1.1.06, available from blitzresearch.itch.io

[Mark SiblyKeymaster]

What version of android does your device run? What version of monkey2 are you using?

There is a bug in one version of android that can cause libraries to fail to load if they are not loaded in correct dependancy order by the app. This has been fixed in more recent versions of monkey2 though. I recommend trying monkey2 v.1.1.06 if your not already. Otherwise, we have a problem!

[Mark SiblyKeymaster]

Still can’t decide how much/if I like that.

It doesn’t help that the example doesn’t make any sense (where is InfoLabel declared?) but I can’t really see myself using it, I guess if I had to initialize a massive struct or something…

Any other opinions on this? I think Amiga blitz actually had something like this, but it looks like it didn’t have much of an impact on me!

[Mark SiblyKeymaster]

I’m a bit unclear on what you’re actually doing here, ie: what are you using 3d for? Maybe just go with a 2d system?  You can always draw 2d stuff to a 3d texture, ala insectoids demo in b3d. If you’re using images, you’re really in the 2d realm anyway I guess.

There’s still no transparency in 3d yet because I would like to try to make it ‘more correct’ (probably wont be 100% correct however I do it) than I have in the past and aren’t quite sure show yet (!) – but it’s likely to be overkill for your needs here I suspect!

[Mark SiblyKeymaster]

HANDLE should be:

Alias HANDLE:Void Ptr

[Mark SiblyKeymaster]

Yes, the values of these consts are already defined in windows.h!

[Mark SiblyKeymaster]

I use s,t,p,q for texture coordinates because that’s what opengl/glsl use.

If it’s a huge hassle I can change it I guess, or even add u ,v, overloads?

[Mark SiblyKeymaster]

> I don’t get why some things are written:

Mainly because this is how it’s written in the .h files, ie: the equivalent ‘c’ is probably something like:

Monkey

struct HWND__{ }; typdef HWND__ *HWND; typedef struct _RECT{ DWORD l,t,r,b; //no idea about this actually... }RECT;

1 2 3 4 5 6 7

struct HWND__{ }; typdef HWND__ *HWND;   typedef struct _RECT{    DWORD l,t,r,b; //no idea about this actually... }RECT;

It’s wildly inconsistent, but that’s how windows is written and it has it’s own sort of logic.

The goal here is to come up with monkey2 code that matches the meaning of the actual ‘c’ code in windows.h so the compiler accepts the output monkey code.

Where to look it all up is a bit tricky. Header files are a good start, and googling ‘msdn HWND’ etc still works pretty well a lot of the time. I should be able to do most the HWND etc type stuff myself, and after that it’s just a matter of entering the APIs.

This is kind of one level of abstraction away from how blitzmax worked, where you had to declare structs very precisely so that struct byte sizes and field offsets were exactly right or all hell would break lose at the binary level. With monkey2, you really just have to get types and names right or things break at the compiler level instead!

[Author]

Posts