Messages

its seen its possible to have more than one joypad, which mean keydown and keyup() might not been the best option for 2 player action. There is no way to call c++ back from java to extractly those function (functions I cant implement myself), so the user could use the JOY commands directly. Howover its would been possible to send the whole to a string instead and retrieve that by a java call and then use a function.

For the touchpad, its property possible to call onNativeTouch().

Im wont trying blind implement this SDK, until glbasic can works with the official SDK android-16 (or android-15) as a new platform (the barebone one) first. Im tried to copy sdk android-16 and then remove android-8 folder, but its failed to compile due build.xml error and want to use android-8 (and I could not replace that one too). You can't just change in the manifest file.

OUYA support require a new platform anyway and wont trying to update the existing v2.2 one, its due its only support one templatefolder. Its simply stupid to merge the existing one and OUYA as same platform due many required changed to the activity java file.

Ps. V2.2 works of course, but I'm also pretty sure some features won't work correctly (as its happens with ads services).

oops :-D.

Also these days I looking how I can turn my Greedy Mouse game into a freemium model rather than premium only game. When its turns to the required freemium, then its could been cool porting to this console. The only minus is the game free content mightbeen bigger than I orignally want, but that it when its freemium rather than light.

but only android-8 is installed in the glbasic platform folder.... its not just setting targetnumber to a higher number. howover its would been nice is a another sdk could been used, such of android-15 in the sdk directly.

also its would been nice to possible to NOT copy the templateproj folder when compiling, because the UOYA would require its own android profile, because its require a lots of changes to supports its controller in SDLActivity.java (due game controller support as well inapp purchases, which is required here, since all titles require "free to play" style.

armv6 is today no longer supported and hence if you want to dev for ios 6, then you need to scrap arm6 and devices older than 3gs.

with other word, Apple have dropped arm6 support in the newest xcode versions.

Yes, its might support it allready, but those applications cannot been fully supported (me thinks property the touchpad function, some game buttons, drm, inapp purchase and some UI thing, but thoses a only shoots).

So its still best to uses a newer SDK than the "outdated" v2.2. Howover I dont want to see v2.2 removed of course (its works nicely), but just added as a new platform named "Jelly Bean".

When that SDK works correctly on normal android device (not UOAY), then rest would been pretty easy.

This is also make sure the modifications required to java activity file dont breaks SDK v2.2 for those which just use "Jelly Bean" for UOYA.

Glbasic only uses sdk 2.2, so sadly its cannot work with glbasic, until Gernot do a SDK upgrade to sdk 4.1.

That why I want to see the possible to upgrade SDK, named as a "Jelly Bean" as a new platform.

When compiling for that SDK works for a regular tablet (etc HP Touchpad with installed Jelly Bean), then Im pretty sure rest of the UOYA support would been pretty easy by doing some changes to java activity as well using the java communication system I created for the past. Here I would look on that when possible (even I dont have the console, buts its looks awesome).

Unicode would property never been supported in glbasic, since its use a bitmap font system, not true type system and strings is 8 bit.

Still you can use mid, for and dim functions to doing by your self, so don't except this to been (quickly) fixed.

Should been pretty easy to do that.

or uses a square call which is pretty fast and then pixel detect it. I believe glbasic does that allready and its why its pretty fast, due its dosent pixel detect anything.

Its still a cool game and I like the explodsion of them.

howover pixel detection might not like some older android phones, but I dont believe its would been a problem in this game at all, if its either use square detection or pixel detection.....

All the game need is a cool retro 8 bit music, hehe.

Or write a function to that, eventuelly with inline. It's also not work with Danish, but it's pretty normal it's happens in most languages.

even the subject could been change for more ontypic with this game, but very welcome to the forum  .

That test game seen looks retro well and play cool for your first game (even its unfinished yet, but its a test)!

Good luck with your defender clone, its look ace.

Even prototyping dosent take very much time, but polising, design etc does take much longer time as excepted. That was happens with my first glbasic game (which started by a different game as well).

Most of color anim seen to been roll over, which is not possible on touch, but its different look very very cool and nice.

Was gack not got rejected due using copyrighted or to much inspiration of Atari/Nintendo games? They are very offensive to close down those assest, so better to use completly original assest files. Even they are old, they still copyrighted.

I have not have any issue with my game, which they was some times too fast to approval, hehe (in one instance, they should have rejected it). It's a different story.

Windows 8 store would been great to been support.

eventuelly its could been done via a little wrapper in a another language to support the modern UI. I thinks we actuelly does not need those live tiles, but just something icon so we can launch the lecancy appm but here doing that by a wrapper.

So for normal Windows 8 platform, this could been the best way to go without requiring a new platform and using its store.

but for Windows RT, its a different story of course. so If Windows RT is supported in a future glbasic, then Windows Phone 8 should been no brainer at all. Windows Phone 7 is out.

Im pretty sure this require a new activity, while the sld actiity layer is still not handled correctly. I have those kind of issues when i tried to implemented kiip moment system, but the sld kidding me too much.

When that was more stable, I'm pretty sure it's could been done using the java communication directly.

http://www.glbasic.com/forum/index.php?topic=8621.msg73172#msg73172

Is a fix to checks it's current orientation. Howover there is a swap y/x issue, which need to been fixed first. It's fixed long time ago, but still no new beta.

Etc display.getOrientation() is required to been used to check current orientation.