Messages

1. if im creating a bat file doing this:
Code: [Select]
c:
cd "C:\Program Files (x86)\Android\android-sdk\platform-tools"
adb.exe install -r "D:\Dokumenter\Programmer\Glbasic\GLBasic\Greedy_Mouse\distribute\Android\bin\glbasic-debug.apk"

Then its seen ABD being much more stable than rather to trying to install with the glbasic default ant. Its still fail, but easier to see when its fail. So Im think a seperate bat file for installing ABD is a better what rater than trying to install directly?

I've found that it's better to uninstall the application before installing it.  This ensures the media folder is cleared out too (which has caused me a few headaches in the past!).  To do this automatically, modify the glb_build.bat file and add the following before ::install (debug?)

Code (glbasic) Select Expand

echo "Uninstalling"
:: uninstall (debug)
call "%ANDROIDSDK%\tools\ant\bin\ant.bat" debug uninstall

You should also refrain from doing anything in onPause() as that is no longer used by SDL (uses a native callback instead and onPause is commented out in newer versions of the beta).

I couldn't get sound/music to work at all in 11.322.  However, it's a moot point as GLB sound wasn't flexible enough (I needed to adjust the volume of sounds already playing).  Instead, I updated the SDLActivity to use SoundPool's and also a Mediaplayer instance for music.

I can now control the volume/rate of sounds already playing and the music plays great - no performance issues and it loops correctly.

Pause/resume seems to work ok on some devices (nexus 7 for example), but will crash the app on others (galaxy s1). 

Andoid is a NIGHTMARE!

Hi Spacefractal,

Wasn't being critical of your code - it's a really helpful routine to get access to otherwise hidden Android tasks and I've recently used it for a project I'm working on.  The updated code I posted helps to prevent against some problems which you may not have detected yet.

The JNI documentation states that you must check for exceptions after calling certain JNI routines (use ExceptionCheck). You must then clear any pending exception with ExceptionClear.  As your code doesn't do this, one mistake can result in an instant crash.  (This also applies to other code in sdlmain.cpp!)

Note: if you detect an exception - don't continue, but do ensure you release any strings/local references before returning

Also, when you call:

strncpy(g_androidJAVACALL, gJNIenv->GetStringUTFChars(res,  0L), 512);

you aren't releasing (or unpinning) the reference from the GetStringUTFChars call.  Again, according to the JNI documentation, you must always call ReleaseStringUTFChars().

If you examine the Android logs (adb shell logcat) then you will most likely see that the garbage collection keeps kicking in - and often.  You can also check memory usage stats using adb - check out the (dumpsys meminfo) adb command. 

Keep up the good work 

//Andy

This is really handy, but be warned:

- check for exceptions!  This could cause all sorts of strange behaviour if you don't - if you're lucky enough for your app to continue working!  You must always check and clear exceptions
- release strings you have created.  If you don't you will eventually get memory leaks and heap overflow
- there's no reason to cast retJava to another jstring (res). 
- Don't rely on strncpy in this case - I've seen memory leaks with its use.  It's better to get the length of the string you are copying and use that - then apply a null character

Here's an updated segment from the sdlmain.cpp:

Code (glbasic) Select Expand



const char* android_JAVACALL(const char* url)
{
const char *textString = NULL;

strcpy(g_androidJAVACALL, "-1");
if (cls==NULL)
{
cls = gJNIenv->FindClass("org/libsdl/app/SDLActivity");
if (cls == NULL)
{
return "Invalid class";
}
mid = gJNIenv->GetStaticMethodID(cls,
   "glb_JAVACALL",
   "(Ljava/lang/String;)Ljava/lang/String;"); // (params;..)return_type
}

if (mid==NULL)
{
return "Invalid method";
}

jstring mystr = gJNIenv->NewStringUTF(url);
if (NULL == mystr)
{
return g_androidJAVACALL;
}
jstring retJava = (jstring)gJNIenv->CallStaticObjectMethod(cls, mid, mystr);
if (gJNIenv->ExceptionCheck()) {
gJNIenv->ExceptionClear();
gJNIenv->DeleteLocalRef(mystr);
return "Exception calling method";
}
if (retJava == NULL)
{
gJNIenv->DeleteLocalRef(mystr);
return g_androidJAVACALL;
}
textString = gJNIenv->GetStringUTFChars(retJava, 0);
if (gJNIenv->ExceptionCheck()) {
gJNIenv->ExceptionClear();
gJNIenv->DeleteLocalRef(mystr);
gJNIenv->DeleteLocalRef(retJava);
return "Exception getting textString";
}

int len = gJNIenv->GetStringLength(retJava);
if (gJNIenv->ExceptionCheck()) {
gJNIenv->ExceptionClear();
gJNIenv->ReleaseStringUTFChars(retJava, textString);
gJNIenv->DeleteLocalRef(mystr);
gJNIenv->DeleteLocalRef(retJava);
return "Exception getting length of return string";
}

strncpy(g_androidJAVACALL, textString, len);
g_androidJAVACALL[len] = 0x00;

gJNIenv->ReleaseStringUTFChars(retJava, textString);
gJNIenv->DeleteLocalRef(mystr);
gJNIenv->DeleteLocalRef(retJava);

return g_androidJAVACALL;
}


The above still isn't perfect, but should provide a bit more protection.

//Andy

Google has decided that, in a future revision of the Android API, it will remove the AbsoluteLayout class.  Until then, it has marked it as "deprecated" which ensures that it will still operate, but they intend to delete at a later date.

It's only a warning and can safely be ignored.  GLB V11 beta removes the need for this code so will be fixed in a future release (if you are using the beta then you can simply remove the import line from SDLActivity.java).

GLBasic implementation of Simplex noise.  2D and 3D noise are supported.  I'll update with 4D when I get time.

Also provided is very basic demo to show how Simplex noise can be used to affect the velocities of particles.

Left mouse button to create particles, right to clear the screen.  Spacebar to toggle the screen hold effect on/off.

I'm sure you guys can put this to better use (generating funky heightmap data etc) and I can't wait to see the results

Cheers,

Andy

The Raspberry Pi build target on V11 doesn't work yet - you'll probably end up with a blue screen and lots of error messages.

Kitty has fixed the errors, but the colours are still wrong and the performance is, well, AWFUL!  Looks like it's dropping to s/w rendering rather than hardware and the texture format could be wrong - but progress is being made

The caanoo port did work a while ago, but again - was painfully slow as it was s/w rendering.  I don't know if it's still possible to get it running.

Is anybody else experiencing issues with sound on V11.322 on Android?  In other words - NO sound at all!

Same program works fine on Android using V10.  All sound plays on Windows, OSX, iPhone etc.

Just seems to be an issue with V11 and Android - has the move to SDL2 broken something?

Note: the output from "adb logcat shell" indicates the audio initialised ok.  However, the output from PLAYSOUND is always -1 (doesn't matter if I'm using .wav of .ogg - same result)

Code (glbasic) Select Expand

V/SDL     (  829): SDL audio: opening device
V/SDL     (  829): SDL audio: wanted stereo 16-bit 44.1kHz, 1024 frames buffer
V/AudioPolicyManager(   83): getDeviceForStrategy() from cache strategy 0, device 2
V/AudioPolicyManager(   83): getOutput() stream 3, samplingRate 0, format 0, channels c, flags 0
V/SDL     (  829): SDL audio: got stereo 16-bit 44.1kHz, 4096 frames buffer
I/glbasic (  829): Init Finalized
V/AudioPolicyManager(   83): startOutput() output 1, stream 3, session 4
V/AudioPolicyManager(   83): getDeviceForStrategy() from cache strategy 0, device 2
V/AudioPolicyManager(   83): getDeviceForStrategy() from cache strategy 0, device 2
V/AudioPolicyManager(   83): getNewDevice() selected device 2
V/AudioPolicyManager(   83): setOutputDevice() output 1 device 2 delayMs 0 force 0
V/AudioPolicyManager(   83): setOutputDevice() setting same device 2 or null device for output 1
D/AudioHardwareALSA(   83): Calling setDevice from write @..1875.
I/AudioHardwareALSA(   83): Initialized ALSA PLAYBACK device AndroidPlayback_Speaker_normal
V/AudioHardwareALSA(   83): Set PLAYBACK PCM format to S16_LE (Signed 16 bit Little Endian)
D/AudioHardwareALSA(   83): Using 2 channels for PLAYBACK.
I/AudioHardwareALSA(   83): DEFAULT_SAMPLE_RATE is 44100, mDefaults->sampleRate is 44100
D/AudioHardwareALSA(   83): Set PLAYBACK sample rate to 44100 HZ
D/AudioHardwareALSA(   83): Buffer size: 4096
D/AudioHardwareALSA(   83): Latency: 92879
W/AudioFlinger(   83): write blocked for 83 msecs, 2 delayed writes, thread 0x2fee8

...

I/glbasic (  829): PLAYSOUND: -1
I/glbasic (  829): LASTERR: 0000 success


I've tried a complete uninstall/reinstall of GLB and have ensured the app is completely uninstalled from the Android device.

I've tested the same on 5 different Android devices with the same result - no sound.

One very simple approach is to use an image to represent your level.  Each pixel represents one tile.  The colour of the pixel indicates the type of tile.

If you need to have more complex layers then you could have further images that represent other information, such as entity locations.

The images are tiny (often a lot less storage space used than XML output from other editors) and it's really easy to implement.

Take a look at the LOADSPRITEMEM() function - this will allow you to read an image into memory and then you loop over the width/heigh of the image and get the colour components.  Compare the r,g,b values with known values in your image and create the tile element in your tilemap arrays.

//Andy

Yep  - looks like I'll need another route to get to the extensions.  Thanks for the heads-up on OpenB3D - will take a look

//Andy

On its own, that inline will compile, but when you try to use it the link error appears.  If I change the types to be the same as you defined then I get the same result I'm afraid.

INLINE
   typedef int             GLsizei;
   typedef unsigned int    GLuint;
   extern "C" void __stdcall glGenBuffers(GLsizei n , GLuint *buffers );
ENDINLINE

FUNCTION glGenBuffers: n, buffers[]
   INLINE
      GLuint* pf=new GLuint[(int)n];
      for(int i=0; i<(int)n; ++i) pf=buffers(i);
      ::glGenBuffers(n, pf);
      delete[] pf;
   ENDINLINE
ENDFUNCTION

linking:
gpc_temp2.o:gpc_temp2.cpp:(.text+0x31b): undefined reference to `_glGenBuffers@8'

The above routine is effectively the same as glGenTextures() found in gl.gbas

Hi All,

Does anybody know how to access OpenGL extensions such as glGenBuffersARB() ?

Specifically, I'm trying to make use of VBO's for which there's no direct access within GLBasic.  gl.gbas doesn't contain any inline code for glGenBuffers or glGenBuffersARB.  The ARB extension can be found in the headers (GLext.h) but I always get link failures if I try to inline:

INLINE
} extern "C" { void __stdcall glGenBuffers( GLsizei n , GLuint *buffers );; }; namespace __GLBASIC__ {
ENDINLINE
FUNCTION glGenBuffers: n, buffers[]
   INLINE
      GLuint* pf=new GLuint[(int)n];
      for(int i=0; i<(int)n; ++i) pf=buffers(i);
      OGL glGenBuffers(n, pf);
      delete[] pf;
   ENDINLINE
ENDFUNCTION

linking:
gpc_temp3.o:gpc_temp3.cpp:(.text+0x3833b): undefined reference to `_glGenBuffers@8'


The same applies for glGenBuffersARB

//Andy

No, not fixed. Definitely still an issue with the latest V11 beta I'm afraid.

I've not experienced any problems on the Galaxy S, S2 or even the Galaxy S3. 

Confirmed as also non-working on the Motorola Atrix (Nvidia gpu).  Unconfirmed report of it failing on Samsung Galaxy Tab too, although this uses PowerVR graphics so is a curiosity.

I've already spoken with Gernot about this issue and I believe he's looking into it.  Will post in bugs section so it doesn't get lost

Min's Q*Boyd uses createscreen/usescreen so suffers this issue.  Shame really as I'd love to play it on my N7

The issue with Nexus 7 is that when using CREATESCREEN/USESCREEN you will get similar errors to:

         I/glbasic ( 8665): glBindRenderbufferExt failed 8cd6

which is: 

         GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT

I believe this is an issue within GLB whereby it's not defining the correct z buffer component (16bits vs 32bits).

If you do NOT use createscreen/usescreen in your app/game, then it will run perfectly fine on the Nexus 7.

Note: The same also applies to the Asus Transformer.