Are there any working SDL Android examples?

[William_Dyce]

Hi again,

Still no real success with either this port or Peyla’s 1.2 branch. I’m
considering switching to OpenGL instead, which will be a real pain, but if I
can’t trust the middle-ware there’s very little I can do as an application
programmer. No offence - I really like SDL but… well, it’s just not
working.
Just to be sure though: are there actually any applications at all, with
source, that use the port? That is, aside from the “Alien Shooter” example
which won’t display graphics on my hardware (“called unimplemented Open GL
ES API”). If I could just get hold of one program that functions correctly I
could figure out what’s going wrong here.

Has anybody succeeded in making this work on real hardware?

William

[Forest_Hale]

I’m not at liberty to show my current work on this, but I can assure you it does work in SDL 1.3…

The Unimplemented OpenGL ES API notices always indicate you have the incorrect context version, which has to be fixed in SDLActivity.java .

Make sure the initEGL function in SDLActivity.java has this code where it calls CreateContext:
int EGL_CONTEXT_CLIENT_VERSION=0x3098;
int contextAttrs[] = new int[]
{
EGL_CONTEXT_CLIENT_VERSION, majorVersion,
EGL10.EGL_NONE
};
EGLContext ctx = egl.eglCreateContext(dpy, config, EGL10.EGL_NO_CONTEXT, contextAttrs);
if (ctx == EGL10.EGL_NO_CONTEXT) {
Log.e(“SDL”, “Couldn’t create context”);
return false;
}

The version I pulled from hg seems to pass null instead of contextAttrs (and does not have the contextAttrs array itself).

Another issue I have come across is lack of multitouch input, all touch events are being passed as mouse events not finger events, I’ll be looking at this issue in the coming days.On 07/25/2011 12:19 AM, William Dyce wrote:

Hi again,

Still no real success with either this port or Peyla’s 1.2 branch. I’m considering switching to OpenGL instead, which will be a real pain, but if I can’t trust the middle-ware there’s very little I
can do as an application programmer. No offence - I really like SDL but… well, it’s just not working.
Just to be sure though: are there actually any applications at all, with source, that use the port? That is, aside from the “Alien Shooter” example which won’t display graphics on my hardware (“called
unimplemented Open GL ES API”). If I could just get hold of one program that functions correctly I could figure out what’s going wrong here.

Has anybody succeeded in making this work on real hardware?

William

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

[Tim_Angus]

It would probably be good to put these things in Bugzilla. Patches/fixes
sent to mailing lists have a tendency to get lost in the noise.On 25/07/2011 10:59, Forest Hale wrote:

The version I pulled from hg seems to pass null instead of contextAttrs
(and does not have the contextAttrs array itself).

Another issue I have come across is lack of multitouch input, all touch
events are being passed as mouse events not finger events, I’ll be
looking at this issue in the coming days.

[William_Dyce]

Sorry Forest, I’ve got the exact same result for the emulator and an instant
crash for the hardware (rather than sound but no images). The difference
between the two seems to be that one runs EGL 1.1 and the other run EGL 2.0,
or at least tries and fail to do so.

There’s a lot at stake here for me: I managed to convince my employers that
C++ with SDL would be a better bet than Unity3D (Free Software FTW!) so if
I’m wrong I’ll most likely lose my summer job, such as it is :-S

I’ll keep digging: I know it has to have something to do with the different
EGL versions: if only I could force the hw to use version 1.1… doing so
seems to make everything crash though.

So nobody has any example they’re willing to expose to the public eye?On 25 July 2011 19:59, Forest Hale wrote:

I’m not at liberty to show my current work on this, but I can assure you it
does work in SDL 1.3…

The Unimplemented OpenGL ES API notices always indicate you have the
incorrect context version, which has to be fixed in SDLActivity.java .

Make sure the initEGL function in SDLActivity.java has this code where it
calls CreateContext:
int EGL_CONTEXT_CLIENT_VERSION=**0x3098;
int contextAttrs[] = new int[]
{
EGL_CONTEXT_CLIENT_VERSION, majorVersion,
EGL10.EGL_NONE
};
EGLContext ctx = egl.eglCreateContext(dpy, config,
EGL10.EGL_NO_CONTEXT, contextAttrs);
if (ctx == EGL10.EGL_NO_CONTEXT) {
Log.e(“SDL”, “Couldn’t create context”);
return false;
}

The version I pulled from hg seems to pass null instead of contextAttrs
(and does not have the contextAttrs array itself).

Another issue I have come across is lack of multitouch input, all touch
events are being passed as mouse events not finger events, I’ll be looking
at this issue in the coming days.

On 07/25/2011 12:19 AM, William Dyce wrote:

Hi again,

Still no real success with either this port or Peyla’s 1.2 branch. I’m
considering switching to OpenGL instead, which will be a real pain, but if I
can’t trust the middle-ware there’s very little I
can do as an application programmer. No offence - I really like SDL but…
well, it’s just not working.
Just to be sure though: are there actually any applications at all, with
source, that use the port? That is, aside from the “Alien Shooter” example
which won’t display graphics on my hardware (“called
unimplemented Open GL ES API”). If I could just get hold of one program
that functions correctly I could figure out what’s going wrong here.

Has anybody succeeded in making this work on real hardware?

William

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/**
darkplaces http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Rene_Dudfield]

The Peyla’s 1.2 branch worked for me on real hardware. I used it through
pygame subset for android.

Good luck!On Mon, Jul 25, 2011 at 1:03 PM, William Dyce wrote:

Sorry Forest, I’ve got the exact same result for the emulator and an
instant crash for the hardware (rather than sound but no images). The
difference between the two seems to be that one runs EGL 1.1 and the other
run EGL 2.0, or at least tries and fail to do so.

There’s a lot at stake here for me: I managed to convince my employers that
C++ with SDL would be a better bet than Unity3D (Free Software FTW!) so if
I’m wrong I’ll most likely lose my summer job, such as it is :-S

I’ll keep digging: I know it has to have something to do with the different
EGL versions: if only I could force the hw to use version 1.1… doing so
seems to make everything crash though.

So nobody has any example they’re willing to expose to the public eye?

On 25 July 2011 19:59, Forest Hale wrote:

I’m not at liberty to show my current work on this, but I can assure you
it does work in SDL 1.3…

The Unimplemented OpenGL ES API notices always indicate you have the
incorrect context version, which has to be fixed in SDLActivity.java .

Make sure the initEGL function in SDLActivity.java has this code where it
calls CreateContext:
int EGL_CONTEXT_CLIENT_VERSION=**0x3098;
int contextAttrs[] = new int[]
{
EGL_CONTEXT_CLIENT_VERSION, majorVersion,
EGL10.EGL_NONE
};
EGLContext ctx = egl.eglCreateContext(dpy, config,
EGL10.EGL_NO_CONTEXT, contextAttrs);
if (ctx == EGL10.EGL_NO_CONTEXT) {
Log.e(“SDL”, “Couldn’t create context”);
return false;
}

The version I pulled from hg seems to pass null instead of contextAttrs
(and does not have the contextAttrs array itself).

Another issue I have come across is lack of multitouch input, all touch
events are being passed as mouse events not finger events, I’ll be looking
at this issue in the coming days.

On 07/25/2011 12:19 AM, William Dyce wrote:

Hi again,

Still no real success with either this port or Peyla’s 1.2 branch. I’m
considering switching to OpenGL instead, which will be a real pain, but if I
can’t trust the middle-ware there’s very little I
can do as an application programmer. No offence - I really like SDL
but… well, it’s just not working.
Just to be sure though: are there actually any applications at all, with
source, that use the port? That is, aside from the “Alien Shooter” example
which won’t display graphics on my hardware (“called
unimplemented Open GL ES API”). If I could just get hold of one program
that functions correctly I could figure out what’s going wrong here.

Has anybody succeeded in making this work on real hardware?

William

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/**
darkplaces http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Forest_Hale]

To be clear I am testing on real hardware too (on a Tegra2 chip in this case), and have the same code running on iOS just as well.

No observed issues with SDL 1.3 other than the context creation versioning and single touch limitation (as described) and the fact I’m not sure how to activate the Android virtual keyboard (likely
need to patch up that too).

I have no experience with SDL 1.2 on android so I can’t speak to that.

Are you quite sure your GLES code is written correctly? There are vast differences between GLES1 and GLES2, is it GLES1 code running on a GLES1 context (as intended)? Or do you have GLES2 code as
well which might be bugged (for example making use of fixed function API features like glMatrixMode and glTexEnv that are present in desktop GL and GLES1 but not in GLES2)?On 07/25/2011 06:10 AM, Ren? Dudfield wrote:

The Peyla’s 1.2 branch worked for me on real hardware. I used it through pygame subset for android.

Good luck!

On Mon, Jul 25, 2011 at 1:03 PM, William Dyce <wilbefast at gmail.com <mailto:wilbefast at gmail.com>> wrote:

Sorry Forest, I've got the exact same result for the emulator and an instant crash for the hardware (rather than sound but no images). The difference between the two seems to be that one runs EGL
1.1 and the other run EGL 2.0, or at least tries and fail to do so.

There's a lot at stake here for me: I managed to convince my employers that C++ with SDL would be a better bet than Unity3D (Free Software FTW!) so if I'm wrong I'll most likely lose my summer
job, such as it is :-S

I'll keep digging: I know it has to have something to do with the different EGL versions: if only I could force the hw to use version 1.1... doing so seems to make everything crash though.

So nobody has any example they're willing to expose to the public eye?



On 25 July 2011 19:59, Forest Hale <@Forest_Hale <mailto:@Forest_Hale>> wrote:

    I'm not at liberty to show my current work on this, but I can assure you it does work in SDL 1.3...

    The Unimplemented OpenGL ES API notices *always* indicate you have the incorrect context version, which has to be fixed in SDLActivity.java .

    Make sure the initEGL function in SDLActivity.java has this code where it calls CreateContext:
                int EGL_CONTEXT_CLIENT_VERSION=__0x3098;
                int contextAttrs[] = new int[]
                {
                EGL_CONTEXT_CLIENT_VERSION, majorVersion,
                EGL10.EGL_NONE
                };
                EGLContext ctx = egl.eglCreateContext(dpy, config, EGL10.EGL_NO_CONTEXT, contextAttrs);
                if (ctx == EGL10.EGL_NO_CONTEXT) {
                    Log.e("SDL", "Couldn't create context");
                    return false;
                }

    The version I pulled from hg seems to pass null instead of contextAttrs (and does not have the contextAttrs array itself).

    Another issue I have come across is lack of multitouch input, all touch events are being passed as mouse events not finger events, I'll be looking at this issue in the coming days.


    On 07/25/2011 12:19 AM, William Dyce wrote:

        Hi again,

        Still no real success with either this port or Peyla's 1.2 branch. I'm considering switching to OpenGL instead, which will be a real pain, but if I can't trust the middle-ware there's very
        little I
        can do as an application programmer. No offence - I really like SDL but... well, it's just not working.
        Just to be sure though: are there actually any applications at all, with source, that use the port? That is, aside from the "Alien Shooter" example which won't display graphics on my
        hardware ("called
        unimplemented Open GL ES API"). If I could just get hold of one program that functions correctly I could figure out what's going wrong here.

        Has anybody succeeded in making this work on real hardware?

        William



        _________________________________________________
        SDL mailing list
        SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
        http://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org <http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>



    --
    LordHavoc
    Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/__darkplaces <http://icculus.org/twilight/darkplaces>
    Co-designer of Nexuiz - http://alientrap.org/nexuiz
    "War does not prove who is right, it proves who is left." - Unknown
    "Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
    "A game is a series of interesting choices." - Sid Meier

    _________________________________________________
    SDL mailing list
    SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    http://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org <http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>



_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

[William_Dyce]

I think that this is more or less where the problem is: something to do with
the differences between GLES 1.1 and 2.0. Trouble is it’s not my GLES
code. I started out trying to get my own SDL project working on Android, but
now I’m just trying to get someone else’s to work so I can examine how it
works and, hopefully, apply the same logic to my original project.

So what I’m trying to run on the Galaxy is actually 100% code taken from the
SDL website, specifically /tmp/android-project.zip Alien Shooter game :-/
Trouble is, since I didn’t write the code in question I don’t know exactly
what I’m looking for or where to find it. It doesn’t help that I’m not
really experienced with OpenGL, let alone GLES.

To sum up (if I understand correctly) it would appear that, somewhere
something has been hard-coded to a set of assumptions that disagree with my
specific hardware/software configuration. Most likely it’s a call to some
function in GLES 2.0 that isn’t in GLES 1.1 or vice-versa.
Hmm… okay, can you think of a sub-set of source files where such a bug
might be hiding, and/or a sub-set of API features that might be causing it?
You just mentioned glMatrixMode and glTexEnv for example…

WilliamOn 26 July 2011 00:33, Forest Hale wrote:

To be clear I am testing on real hardware too (on a Tegra2 chip in this
case), and have the same code running on iOS just as well.

No observed issues with SDL 1.3 other than the context creation versioning
and single touch limitation (as described) and the fact I’m not sure how to
activate the Android virtual keyboard (likely need to patch up that too).

I have no experience with SDL 1.2 on android so I can’t speak to that.

Are you quite sure your GLES code is written correctly? There are vast
differences between GLES1 and GLES2, is it GLES1 code running on a GLES1
context (as intended)? Or do you have GLES2 code as well which might be
bugged (for example making use of fixed function API features like
glMatrixMode and glTexEnv that are present in desktop GL and GLES1 but not
in GLES2)?

On 07/25/2011 06:10 AM, Ren? Dudfield wrote:

The Peyla’s 1.2 branch worked for me on real hardware. I used it through
pygame subset for android.

Good luck!

On Mon, Jul 25, 2011 at 1:03 PM, William Dyce <@William_Dyce<mailto: @William_Dyce>> wrote:

Sorry Forest, I’ve got the exact same result for the emulator and an
instant crash for the hardware (rather than sound but no images). The
difference between the two seems to be that one runs EGL
1.1 and the other run EGL 2.0, or at least tries and fail to do so.

There’s a lot at stake here for me: I managed to convince my employers
that C++ with SDL would be a better bet than Unity3D (Free Software FTW!) so
if I’m wrong I’ll most likely lose my summer
job, such as it is :-S

I’ll keep digging: I know it has to have something to do with the
different EGL versions: if only I could force the hw to use version 1.1…
doing so seems to make everything crash though.

So nobody has any example they’re willing to expose to the public eye?

On 25 July 2011 19:59, Forest Hale <havoc at ghdigital.com <mailto: havoc at ghdigital.com>> wrote:

   I'm not at liberty to show my current work on this, but I can

assure you it does work in SDL 1.3…

   The Unimplemented OpenGL ES API notices *always* indicate you have

the incorrect context version, which has to be fixed in SDLActivity.java .

   Make sure the initEGL function in SDLActivity.java has this code

where it calls CreateContext:
int EGL_CONTEXT_CLIENT_VERSION=__**0x3098;
int contextAttrs[] = new int[]
{
EGL_CONTEXT_CLIENT_VERSION, majorVersion,
EGL10.EGL_NONE
};
EGLContext ctx = egl.eglCreateContext(dpy, config,
EGL10.EGL_NO_CONTEXT, contextAttrs);
if (ctx == EGL10.EGL_NO_CONTEXT) {
Log.e(“SDL”, “Couldn’t create context”);
return false;
}

   The version I pulled from hg seems to pass null instead of

contextAttrs (and does not have the contextAttrs array itself).

   Another issue I have come across is lack of multitouch input, all

touch events are being passed as mouse events not finger events, I’ll be
looking at this issue in the coming days.

   On 07/25/2011 12:19 AM, William Dyce wrote:

       Hi again,

       Still no real success with either this port or Peyla's 1.2

branch. I’m considering switching to OpenGL instead, which will be a real
pain, but if I can’t trust the middle-ware there’s very
little I
can do as an application programmer. No offence - I really like
SDL but… well, it’s just not working.
Just to be sure though: are there actually any applications at
all, with source, that use the port? That is, aside from the "Alien Shooter"
example which won’t display graphics on my
hardware (“called
unimplemented Open GL ES API”). If I could just get hold of one
program that functions correctly I could figure out what’s going wrong here.

       Has anybody succeeded in making this work on real hardware?

       William



       ______________________________**___________________
       SDL mailing list
       SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
       http://lists.libsdl.org/__**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org><

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

   --
   LordHavoc
   Author of DarkPlaces Quake1 engine -

http://icculus.org/twilight/__**darkplaceshttp://icculus.org/twilight/__darkplaces<
http://icculus.org/twilight/**darkplaceshttp://icculus.org/twilight/darkplaces

   Co-designer of Nexuiz - http://alientrap.org/nexuiz
   "War does not prove who is right, it proves who is left." - Unknown
   "Any sufficiently advanced technology is indistinguishable from a

rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

   ______________________________**___________________
   SDL mailing list
   SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
   http://lists.libsdl.org/__**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org><

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/**
darkplaces http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Scott_Smith]

I have not done anything specific in regards to android, but i have used
Opengl-ES on linux distros.

Are you getting a window surface? (Are you using SDL or EGL?)
EGL is basically the same for both 1.1 and 2.0. The process of getting surface
is the same. The main difference is the attrib bits. SDL 1.3 should hide this
part. You wont get a surface to draw to if this doesnt work.

Which GLES lib are you linking to? Typically they are called GLES_CM.so and
GLESv2.so. Make sure your using the right lib for the API your going to use.

Check out this link, it gives some good examples and give some good explanations
on the differences between 1.X ES and 2.0 ES.
http://pandorawiki.org/GLESGAE:Setting_Up_A_Window_and_Context________________________________
From: wilbefast@gmail.com (William Dyce)
To: SDL Development List
Sent: Mon, July 25, 2011 11:10:03 AM
Subject: Re: [SDL] Are there any working SDL Android examples?

I think that this is more or less where the problem is: something to do with the
differences between GLES 1.1 and 2.0. Trouble is it’s not my GLES code. I
started out trying to get my own SDL project working on Android, but now I’m
just trying to get someone else’s to work so I can examine how it works and,
hopefully, apply the same logic to my original project.

So what I’m trying to run on the Galaxy is actually 100% code taken from the SDL
website, specifically /tmp/android-project.zip Alien Shooter game :-/ Trouble
is, since I didn’t write the code in question I don’t know exactly what I’m
looking for or where to find it. It doesn’t help that I’m not really experienced
with OpenGL, let alone GLES.

To sum up (if I understand correctly) it would appear that, somewhere something
has been hard-coded to a set of assumptions that disagree with my specific
hardware/software configuration. Most likely it’s a call to some function in
GLES 2.0 that isn’t in GLES 1.1 or vice-versa.

Hmm… okay, can you think of a sub-set of source files where such a bug might
be hiding, and/or a sub-set of API features that might be causing it? You just
mentioned glMatrixMode and glTexEnv for example…

William

On 26 July 2011 00:33, Forest Hale wrote:

To be clear I am testing on real hardware too (on a Tegra2 chip in this case),
and have the same code running on iOS just as well.

No observed issues with SDL 1.3 other than the context creation versioning and
single touch limitation (as described) and the fact I’m not sure how to activate
the Android virtual keyboard (likely need to patch up that too).

I have no experience with SDL 1.2 on android so I can’t speak to that.

Are you quite sure your GLES code is written correctly? There are vast
differences between GLES1 and GLES2, is it GLES1 code running on a GLES1 context
(as intended)? Or do you have GLES2 code as well which might be bugged (for
example making use of fixed function API features like glMatrixMode and glTexEnv
that are present in desktop GL and GLES1 but not in GLES2)?

On 07/25/2011 06:10 AM, Ren? Dudfield wrote:

The Peyla’s 1.2 branch worked for me on real hardware. I used it through pygame
subset for android.

Good luck!

On Mon, Jul 25, 2011 at 1:03 PM, William Dyce <wilbefast at gmail.com <mailto:wilbefast at gmail.com>> wrote:

Sorry Forest, I’ve got the exact same result for the emulator and an instant
crash for the hardware (rather than sound but no images). The difference between
the two seems to be that one runs EGL
1.1 and the other run EGL 2.0, or at least tries and fail to do so.

There’s a lot at stake here for me: I managed to convince my employers that
C++ with SDL would be a better bet than Unity3D (Free Software FTW!) so if I’m
wrong I’ll most likely lose my summer
job, such as it is :-S

I’ll keep digging: I know it has to have something to do with the different
EGL versions: if only I could force the hw to use version 1.1… doing so seems
to make everything crash though.

So nobody has any example they’re willing to expose to the public eye?

On 25 July 2011 19:59, Forest Hale <havoc at ghdigital.com <mailto:havoc at ghdigital.com>> wrote:

  I'm not at liberty to show my current work on this, but I can assure you 

it does work in SDL 1.3…

  The Unimplemented OpenGL ES API notices *always* indicate you have the 

incorrect context version, which has to be fixed in SDLActivity.java .

  Make sure the initEGL function in SDLActivity.java has this code where it 

calls CreateContext:
int EGL_CONTEXT_CLIENT_VERSION=__0x3098;
int contextAttrs[] = new int[]
{
EGL_CONTEXT_CLIENT_VERSION, majorVersion,
EGL10.EGL_NONE
};
EGLContext ctx = egl.eglCreateContext(dpy, config,
EGL10.EGL_NO_CONTEXT, contextAttrs);
if (ctx == EGL10.EGL_NO_CONTEXT) {
Log.e(“SDL”, “Couldn’t create context”);
return false;
}

  The version I pulled from hg seems to pass null instead of contextAttrs 

(and does not have the contextAttrs array itself).

  Another issue I have come across is lack of multitouch input, all touch 

events are being passed as mouse events not finger events, I’ll be looking at
this issue in the coming days.

  On 07/25/2011 12:19 AM, William Dyce wrote:

      Hi again,

      Still no real success with either this port or Peyla's 1.2 branch. 

I’m considering switching to OpenGL instead, which will be a real pain, but if I
can’t trust the middle-ware there’s very
little I
can do as an application programmer. No offence - I really like SDL
but… well, it’s just not working.
Just to be sure though: are there actually any applications at all,
with source, that use the port? That is, aside from the “Alien Shooter” example
which won’t display graphics on my
hardware (“called
unimplemented Open GL ES API”). If I could just get hold of one
program that functions correctly I could figure out what’s going wrong here.

      Has anybody succeeded in making this work on real hardware?

      William



      _________________________________________________
      SDL mailing list

       SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

      http://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org 

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

  --
  LordHavoc
  Author of DarkPlaces Quake1 engine - 

http://icculus.org/twilight/__darkplaces
http://icculus.org/twilight/darkplaces

  Co-designer of Nexuiz - http://alientrap.org/nexuiz
  "War does not prove who is right, it proves who is left." - Unknown
  "Any sufficiently advanced technology is indistinguishable from a rigged 

demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

  _________________________________________________
  SDL mailing list

   SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

  http://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org 

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo."

• James Klass
  "A game is a series of interesting choices." - Sid Meier

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[William_Dyce]

Scott: as I understand it, SDL works as a wrapper for EGL on Android, so the
actual application is pure SDL in C++. The trouble is that the SDL functions
are not being “served” correctly by the underlying API: I’m other getting no
graphics or, when I tamper inexpertly with the SDL port’s Android-specific
Java layer, segmentation faults.

You may be onto something though. Take a look at the application makefile
(Android.mk). I hadn’t noticed this before but look right down at the
bottom:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := main

SDL_PATH := …/SDL

*LOCAL_C_INCLUDES := *

• $(LOCAL_PATH)/$(SDL_PATH)/include *
• $(LOCAL_PATH)/…/SDL_image *
• $(LOCAL_PATH)/…/SDL_mixer *
• $(LOCAL_PATH)/…/SDL_ttf*

# Add any compilation flags for your project here…
*LOCAL_CFLAGS := *

• -DPLAY_MOD*

# Add your application source files here…
*LOCAL_SRC_FILES := $(SDL_PATH)/src/main/android/SDL_android_main.cpp *

• aliens.c*

LOCAL_SHARED_LIBRARIES := SDL SDL_image SDL_mixer SDL_ttf

LOCAL_LDLIBS := -lGLESv1_CM -llog

include $(BUILD_SHARED_LIBRARY)

I wonder what would happen if I put -lGLESv2 here instead… or better, some
logic to choose the correct library dynamically, since my emulator uses v1
and my hardware uses v2.

God please let this not being another red herring…On 26 July 2011 01:33, Scott Smith wrote:

I have not done anything specific in regards to android, but i have used
Opengl-ES on linux distros.

Are you getting a window surface? (Are you using SDL or EGL?)
EGL is basically the same for both 1.1 and 2.0. The process of getting
surface is the same. The main difference is the attrib bits. SDL 1.3 should
hide this part. You wont get a surface to draw to if this doesnt work.

Which GLES lib are you linking to? Typically they are called GLES_CM.so and
GLESv2.so. Make sure your using the right lib for the API your going to use.

Check out this link, it gives some good examples and give some good
explanations on the differences between 1.X ES and 2.0 ES.
http://pandorawiki.org/GLESGAE:Setting_Up_A_Window_and_Context

---

From: William Dyce <@William_Dyce>
To: SDL Development List
Sent: Mon, July 25, 2011 11:10:03 AM
Subject: Re: [SDL] Are there any working SDL Android examples?

I think that this is more or less where the problem is: something to do
with the differences between GLES 1.1 and 2.0. Trouble is it’s not my GLES
code. I started out trying to get my own SDL project working on Android, but
now I’m just trying to get someone else’s to work so I can examine how it
works and, hopefully, apply the same logic to my original project.

So what I’m trying to run on the Galaxy is actually 100% code taken from
the SDL website, specifically /tmp/android-project.zip Alien Shooter game
:-/ Trouble is, since I didn’t write the code in question I don’t know
exactly what I’m looking for or where to find it. It doesn’t help that I’m
not really experienced with OpenGL, let alone GLES.

To sum up (if I understand correctly) it would appear that, somewhere
something has been hard-coded to a set of assumptions that disagree with my
specific hardware/software configuration. Most likely it’s a call to some
function in GLES 2.0 that isn’t in GLES 1.1 or vice-versa.
Hmm… okay, can you think of a sub-set of source files where such a bug
might be hiding, and/or a sub-set of API features that might be causing it?
You just mentioned glMatrixMode and glTexEnv for example…

William

On 26 July 2011 00:33, Forest Hale wrote:

To be clear I am testing on real hardware too (on a Tegra2 chip in this
case), and have the same code running on iOS just as well.

No observed issues with SDL 1.3 other than the context creation versioning
and single touch limitation (as described) and the fact I’m not sure how to
activate the Android virtual keyboard (likely need to patch up that too).

I have no experience with SDL 1.2 on android so I can’t speak to that.

Are you quite sure your GLES code is written correctly? There are vast
differences between GLES1 and GLES2, is it GLES1 code running on a GLES1
context (as intended)? Or do you have GLES2 code as well which might be
bugged (for example making use of fixed function API features like
glMatrixMode and glTexEnv that are present in desktop GL and GLES1 but not
in GLES2)?

On 07/25/2011 06:10 AM, Ren? Dudfield wrote:

The Peyla’s 1.2 branch worked for me on real hardware. I used it through
pygame subset for android.

Good luck!

On Mon, Jul 25, 2011 at 1:03 PM, William Dyce <@William_Dyce<mailto: @William_Dyce>> wrote:

Sorry Forest, I’ve got the exact same result for the emulator and an
instant crash for the hardware (rather than sound but no images). The
difference between the two seems to be that one runs EGL
1.1 and the other run EGL 2.0, or at least tries and fail to do so.

There’s a lot at stake here for me: I managed to convince my employers
that C++ with SDL would be a better bet than Unity3D (Free Software FTW!) so
if I’m wrong I’ll most likely lose my summer
job, such as it is :-S

I’ll keep digging: I know it has to have something to do with the
different EGL versions: if only I could force the hw to use version 1.1…
doing so seems to make everything crash though.

So nobody has any example they’re willing to expose to the public eye?

On 25 July 2011 19:59, Forest Hale <havoc at ghdigital.com <mailto: havoc at ghdigital.com>> wrote:

   I'm not at liberty to show my current work on this, but I can

assure you it does work in SDL 1.3…

   The Unimplemented OpenGL ES API notices *always* indicate you have

the incorrect context version, which has to be fixed in SDLActivity.java .

   Make sure the initEGL function in SDLActivity.java has this code

where it calls CreateContext:
int EGL_CONTEXT_CLIENT_VERSION=__**0x3098;
int contextAttrs[] = new int[]
{
EGL_CONTEXT_CLIENT_VERSION, majorVersion,
EGL10.EGL_NONE
};
EGLContext ctx = egl.eglCreateContext(dpy, config,
EGL10.EGL_NO_CONTEXT, contextAttrs);
if (ctx == EGL10.EGL_NO_CONTEXT) {
Log.e(“SDL”, “Couldn’t create context”);
return false;
}

   The version I pulled from hg seems to pass null instead of

contextAttrs (and does not have the contextAttrs array itself).

   Another issue I have come across is lack of multitouch input, all

touch events are being passed as mouse events not finger events, I’ll be
looking at this issue in the coming days.

   On 07/25/2011 12:19 AM, William Dyce wrote:

       Hi again,

       Still no real success with either this port or Peyla's 1.2

branch. I’m considering switching to OpenGL instead, which will be a real
pain, but if I can’t trust the middle-ware there’s very
little I
can do as an application programmer. No offence - I really
like SDL but… well, it’s just not working.
Just to be sure though: are there actually any applications at
all, with source, that use the port? That is, aside from the "Alien Shooter"
example which won’t display graphics on my
hardware (“called
unimplemented Open GL ES API”). If I could just get hold of
one program that functions correctly I could figure out what’s going wrong
here.

       Has anybody succeeded in making this work on real hardware?

       William



       ______________________________**___________________
       SDL mailing list
       SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
       http://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org <

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>

   --
   LordHavoc
   Author of DarkPlaces Quake1 engine -

http://icculus.org/twilight/__darkplaces <
http://icculus.org/twilight/darkplaces>

   Co-designer of Nexuiz - http://alientrap.org/nexuiz
   "War does not prove who is right, it proves who is left." -

Unknown
"Any sufficiently advanced technology is indistinguishable from a
rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

   ______________________________**___________________
   SDL mailing list
   SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
   http://lists.libsdl.org/__**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org><

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/**
darkplaces http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Manuel_Massing]

Hi William,

The alien project is probably using either the OpenGL ES 1.1
or OpenGL ES 2.0 accelerated SDL renderer (for blitting etc.).

Make sure that only one of the renderers is registered or the correct one
selected, and take note if it is the gles or gles 2.0 renderer (e.g.
by looking into the SDL source code, in particular renderer/SDL_render.c and
the SDL_config.h used for your build!).

Anyway, I would suggest you start from scratch with a minimal SDL project
instead (lots of sample code), and move up from there.

1. Create your minimal project based on $SDLDIR/android-project.
   Put your source in android-project/jni/src/YourSource.cpp and edit the
   Android.mk accordingly.

2. invoke “ndk-build” then “ant debug” to build it.

In your program, first try creating a simple window and GL context. If
you require GLES 2.0, use the modifications suggested by Forest Hale, or use
the patch I sent you previously (use my patch in conjunction with

    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);

or
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 1);

depending on whether you want to create an OpenGL ES 1.1 or OpenGL ES 2.0
context)

If video init succeeds, test simple OpenGL functionality (e.g. a framebuffer
clear: glClearColor(1,0,0,1); glClear(GL_COLOR_BUFFER_BIT); ).

If you need further suggestions, provide the “logcat *:V” output of
your application startup.

bye,

Manuel

[William_Dyce]

Hi Manuel,

I’ve been trying to avoid using OpenGL directly and I’ve stuck to software
rendering so far - basically just high-level SDL stuff for the application
itself. I had a go at writing a fairly basic test program which should just
draw a small red rectangle on the screen. It runs on the emulator and on
Linux, but on the hardware -you guessed it- no red rectangle, just “called
unimplemented OpenGL ES API”.

Attached is the source, makefile and extract from the logs that should cover
the whole execution, except for a few hundred repetitions of the above error
that I removed for convenience - you can probably skip down to about line 74
for the main thread of execution.

I’ll check out the other stuff tomorrow - it 3am, I should probably get some
sleep :-S

Thanks for the help

WilliamOn 26 July 2011 01:46, Manuel Massing <m.massing at warped-space.de> wrote:

Hi William,

The alien project is probably using either the OpenGL ES 1.1
or OpenGL ES 2.0 accelerated SDL renderer (for blitting etc.).

Make sure that only one of the renderers is registered or the correct one
selected, and take note if it is the gles or gles 2.0 renderer (e.g.
by looking into the SDL source code, in particular renderer/SDL_render.c
and
the SDL_config.h used for your build!).

Anyway, I would suggest you start from scratch with a minimal SDL project
instead (lots of sample code), and move up from there.

1. Create your minimal project based on $SDLDIR/android-project.
   Put your source in android-project/jni/src/YourSource.cpp and edit the
   Android.mk accordingly.

2. invoke “ndk-build” then “ant debug” to build it.

In your program, first try creating a simple window and GL context. If
you require GLES 2.0, use the modifications suggested by Forest Hale, or
use
the patch I sent you previously (use my patch in conjunction with

   SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
   SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);

or
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 1);

depending on whether you want to create an OpenGL ES 1.1 or OpenGL ES 2.0
context)

If video init succeeds, test simple OpenGL functionality (e.g. a
framebuffer
clear: glClearColor(1,0,0,1); glClear(GL_COLOR_BUFFER_BIT); ).

If you need further suggestions, provide the “logcat *:V” output of
your application startup.

bye,

   Manuel

-------------- next part --------------
I/Launcher( 251): onResume(). mIsNewIntent : true
E/Launcher( 251): MTP-LAUNCHER: media scanning not yet finished.
I/Launcher( 251): onResume() ended
I/Launcher( 251): onWindowFocusChanged(true)
D/Launcher( 251): setWallpaperDimension() called
D/Launcher( 251): USE_NON_SCROLLABLE_IMAGE_WALLPAPER is true
D/Launcher( 251): It’s image wallpaper. suggestDesiredDimensions(-1,-1)
I/Launcher( 251): onPause()
I/Launcher( 251): onResume(). mIsNewIntent : true
E/Launcher( 251): MTP-LAUNCHER: media scanning not yet finished.
I/Launcher( 251): onResume() ended
D/ScreenCaptureService( 1571): Starting #2: Bundle[mParcelledData.dataSize=60]
D/ScreenCaptureService( 1571): mType = long_keydown isLongKey = true onCapture = false
D/ScreenCaptureService( 1571): Starting #3: Bundle[mParcelledData.dataSize=56]
D/ScreenCaptureService( 1571): mType = long_keyup isLongKey = false onCapture = false
W/KeyCharacterMap( 251): No keyboard for id 65536
W/KeyCharacterMap( 251): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
D/Launcher( 251): dispatchKeyEvent DOWN KEYCODE_BACK / MainMenu isOpened=false Info=false
D/Launcher( 251): KEYCODE_BACK launcher 2
D/Launcher( 251): dispatchKeyEvent UP KEYCODE_BACK / MainMenu isOpened=false Info=false
V/AudioFlinger( 94): Track constructor name 4098, calling thread 179
V/AudioFlinger( 94): start(4098), calling thread 179
V/AudioFlinger( 94): ? => ACTIVE (4098) on thread 0x18770
V/AudioPolicyManager( 94): startOutput() output 1, stream 1
E/AudioPolicyManagerBase( 94): unknown stream type
E/AudioPolicyManagerBase( 94): unknown stream type
E/AudioPolicyManagerBase( 94): unknown stream type
V/AudioPolicyManager( 94): getDeviceForStrategy() from cache strategy 0, device 2
V/AudioPolicyManager( 94): getNewDevice() selected device 2
V/AudioPolicyManager( 94): setOutputDevice() output 1 device 2 force 0 delayMs 0
V/AudioPolicyManager( 94): setOutputDevice() setting same device 2 or null device for output 1
V/AudioFlinger( 94): mWaitWorkCV.broadcast
V/AudioFlinger( 94): MixerThread 0xbb38 TID 151 waking up
V/AudioPolicyManager( 94): releaseOutput() 1
V/AudioFlinger( 94): remove track (4097) and delete from mixer
V/AudioFlinger( 94): PlaybackThread::Track destructor
E/ATK ( 1562): widget kill start
V/AudioHardwareMSM72XX( 94): open driver
V/AudioHardwareMSM72XX( 94): get config
V/AudioHardwareMSM72XX( 94): set config
V/AudioHardwareMSM72XX( 94): buffer_size: 4800
V/AudioHardwareMSM72XX( 94): buffer_count: 2
V/AudioHardwareMSM72XX( 94): channel_count: 2
V/AudioHardwareMSM72XX( 94): sample_rate: 44100
E/ATK ( 1562): com.google.android.googlequicksearchbox
W/AudioFlinger( 94): write blocked for 166 msecs, 10 delayed writes, thread 0xbb38
E/ATK ( 1562): org.jtb.alogcat
E/ATK ( 1562): com.android.vending
E/ATK ( 1562): com.sec.android.app.unifiedinbox
E/ATK ( 1562): com.android.music
V/AudioFlinger( 94): getNextBuffer() no more data for track 4098 on thread 0xbb38
V/AudioFlinger( 94): stop(4098), calling thread 179
V/AudioFlinger( 94): (> STOPPED) => STOPPED (4098) on thread 0xbb38
V/AudioPolicyManager( 94): stopOutput() output 1, stream 1
E/AudioPolicyManagerBase( 94): unknown stream type
E/AudioPolicyManagerBase( 94): unknown stream type
E/AudioPolicyManagerBase( 94): unknown stream type
E/AudioPolicyManagerBase( 94): unknown stream type
V/AudioPolicyManager( 94): getNewDevice() selected device 0
V/AudioPolicyManager( 94): setOutputDevice() output 1 device 0 force 0 delayMs 150
V/AudioPolicyManager( 94): setOutputDevice() setting same device 0 or null device for output 1
V/AudioFlinger( 94): TrackBase::reset
E/ATK ( 1562): widget kill end
V/AudioFlinger( 94): Audio hardware entering standby, mixer 0xbb38, mSuspended 0
V/AudioFlinger( 94): MixerThread 0xbb38 TID 151 going to sleep
E/AndroidRuntime( 1595): /system/csc/feature.xml ==> cannot open file
E/AndroidRuntime( 1604): /system/csc/feature.xml ==> cannot open file
I/Launcher( 251): onPause()
D/PhoneApp( 247): updateProximitySensorMode: lock already released.
I/Launcher( 251): onWindowFocusChanged(false)
D/Launcher( 251): setWallpaperDimension() called
D/Launcher( 251): USE_NON_SCROLLABLE_IMAGE_WALLPAPER is true
D/Launcher( 251): It’s image wallpaper. suggestDesiredDimensions(-1,-1)
D/SensorManager( 1612): ====>>>>>Num Sensor: 1
D/SensorManager( 1612): ====>>>>>Num Sensor: 2
D/SensorManager( 1612): ====>>>>>Num Sensor: 3
D/SensorManager( 1612): ====>>>>>Num Sensor: 0
W/IInputConnectionWrapper( 251): showStatusIcon on inactive InputConnection
E/SensorManager( 1612): registerListener :: handle = 0 name= BMA220 delay= 60 Listener= org.libsdl.app.SDLSurface at 4a523e18
E/SensorHAL( 179): Sensor Input open fd_compass=95 fd_accel=96
E/SensorManager( 1612): =======>>>Sensor Thread RUNNING <<<========
E/SensorHAL( 1612): __data_data_open 32 34
E/SensorHAL( 179): Write acc delay /sys/class/input/input3/poll_delay <—60
V/SDL ( 1612): pixel format unknown -1
I/SDL ( 1612): SDL_Android_Init()
I/APPLICATION( 1612): >>>>>Initialising SDL video: Okay
I/SDL ( 1612): [STUB] GL_LoadLibrary
V/SDL ( 1612): Starting up OpenGL ES 2.0
I/ActivityManager( 179): Displayed activity org.libsdl.app/.SDLActivity: 482 ms (total 482 ms)
I/SDL ( 1612): [STUB] GL_SetSwapInterval
I/SDL ( 1612): [STUB] GL_GetSwapInterval
E/libEGL ( 1612): called unimplemented OpenGL ES API
E/libEGL ( 1612): called unimplemented OpenGL ES API
E/libEGL ( 1612): called unimplemented OpenGL ES API
E/libEGL ( 1612): called unimplemented OpenGL ES API
E/libEGL ( 1612): called unimplemented OpenGL ES API
E/libEGL ( 1612): called unimplemented OpenGL ES API
E/libEGL ( 1612): called unimplemented OpenGL ES API
E/libEGL ( 1612): called unimplemented OpenGL ES API
I/APPLICATION( 1612): >>>>>Creating window: Okay
I/APPLICATION( 1612): >>>>>Main initialisations: Okay
E/libEGL ( 1612): called unimplemented OpenGL ES API
E/libEGL ( 1612): called unimplemented OpenGL ES API

** REPEATED THOUSAND OF TIMES

E/libEGL ( 1612): called unimplemented OpenGL ES API
E/libEGL ( 1612): called unimplemented OpenGL ES API
D/PhoneApp( 247): updateProximitySensorMode: lock already released.
D/PhoneWindow( 1612): couldn’t save which view has focus because the focused view org.libsdl.app.SDLSurface at 4a523e18 has no id.
I/SDL ( 1612): [STUB] GL_UnloadLibrary
I/APPLICATION( 1612): >>>>>Shutting down: Okay
-------------- next part --------------
A non-text attachment was scrubbed…
Name: main.cpp
Type: text/x-c++src
Size: 2960 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110726/2d3c803d/attachment.cpp
-------------- next part --------------
A non-text attachment was scrubbed…
Name: Android.mk
Type: application/octet-stream
Size: 450 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110726/2d3c803d/attachment.obj

[Manuel_Massing]

William,

first thing you should try is to disable OpenGL ES 2.0
support in SDL_config_android.h (#undef SDL_VIDEO_RENDER_OGL_ES2)
and rebuild SDL.

From the log it is clear that SDL tries to initialize an OpenGL ES 2.0
context, although the unpatched android/SDL glue code is only
capable of correctly initializing OpenGL ES 1.1, probably resulting
in a mismatching renderer or invalid GL context.

good luck,

Manuel

[Dimitris_Zenios]

Try not to use SDL compat mode.On Mon, Jul 25, 2011 at 8:28 PM, Manuel Massing <m.massing at warped-space.de> wrote:

William,

first thing you should try is to disable OpenGL ES 2.0
support in SDL_config_android.h (#undef SDL_VIDEO_RENDER_OGL_ES2)
and rebuild SDL.

From the log it is clear that SDL tries to initialize an OpenGL ES 2.0
context, although the unpatched android/SDL glue code is only
capable of correctly initializing OpenGL ES 1.1, probably resulting
in a mismatching renderer or invalid GL context.

good luck,

? ? ? ?Manuel

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[William_Dyce]

Dimitris: so avoid legacy functions like SDL_SetVideoMode? I’ve actually
been unable to find any example code that uses SDL_CreateWindow, even in the
SDL1.3 examples directory. Could you give me an example, and is there
anything I should try to strip out?

Manuel: I did as you said - I’m not getting any more calls to unimplemented
APIs, OpenGL ES 1.1 is started and the application itself logs all the
various initialisations are successful. That said there’s still no red box
being drawn on screen.
I compared the log output of the emulator (which works) and the hardware
(which doesn’t work). Here are a few lines missing from the hardware’s log,
in chronological order:
D/ libEGL: egl.cfg not found, using default config
D/ libEGL: loaded /system/lib/egal/libGLES_android.so
I/ ARMAssembler: generated scanline___000… etc

And here are the entries present in the hardware and absent from the
emulator:
I/ ActivityThread: queueIdle
V/ ActivityThread: Reporting idle of ActivityRecord (…) org.libsdl.app
(…)
W/ ActivityNative: send ACTIVITY_IDLE_TRANSACTION
W/ ActivityNative: RCV ACTIVITY_IDLE_TRANSACTION

Still not sure what’s going on here - perhaps I need to get rid of all the
legacy code as Dimitris suggested?

WilliamOn 26 July 2011 06:35, Dimitris Zenios <dimitris.zenios at gmail.com> wrote:

Try not to use SDL compat mode.

On Mon, Jul 25, 2011 at 8:28 PM, Manuel Massing <m.massing at warped-space.de> wrote:

William,

first thing you should try is to disable OpenGL ES 2.0
support in SDL_config_android.h (#undef SDL_VIDEO_RENDER_OGL_ES2)
and rebuild SDL.

From the log it is clear that SDL tries to initialize an OpenGL ES 2.0
context, although the unpatched android/SDL glue code is only
capable of correctly initializing OpenGL ES 1.1, probably resulting
in a mismatching renderer or invalid GL context.

good luck,

   Manuel

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Dimitris_Zenios]

William

check out http://immersedcode.org/2011/4/25/sdl-on-ios/ .Its for
iphone but there is example code which will help you alsoOn Tue, Jul 26, 2011 at 7:10 AM, William Dyce wrote:

Dimitris: so avoid legacy functions like SDL_SetVideoMode? I’ve actually
been unable to find any example code that uses SDL_CreateWindow, even in the
SDL1.3 examples directory. Could you give me an example, and is there
anything I should try to strip out?

Manuel: I did as you said - I’m not getting any more calls to unimplemented
APIs, OpenGL ES 1.1 is started and the application itself logs all the
various initialisations are successful. That said there’s still no red box
being drawn on screen.
I compared the log output of the emulator (which works) and the hardware
(which doesn’t work). Here are a few lines missing from the hardware’s log,
in chronological order:
D/ libEGL: egl.cfg not found, using default config
D/ libEGL: loaded /system/lib/egal/libGLES_android.so
I/ ARMAssembler: generated scanline___000… etc

And here are the entries present in the hardware and absent from the
emulator:
I/ ActivityThread: queueIdle
V/ ActivityThread: Reporting idle of ActivityRecord (…) org.libsdl.app
(…)
W/ ActivityNative: send ACTIVITY_IDLE_TRANSACTION
W/ ActivityNative: RCV ACTIVITY_IDLE_TRANSACTION

Still not sure what’s going on here - perhaps I need to get rid of all the
legacy code as Dimitris suggested?

William

On 26 July 2011 06:35, Dimitris Zenios <@Dimitris_Zenios> wrote:

Try not to use SDL compat mode.

On Mon, Jul 25, 2011 at 8:28 PM, Manuel Massing <m.massing at warped-space.de> wrote:

William,

first thing you should try is to disable OpenGL ES 2.0
support in SDL_config_android.h (#undef SDL_VIDEO_RENDER_OGL_ES2)
and rebuild SDL.

From the log it is clear that SDL tries to initialize an OpenGL ES 2.0
context, although the unpatched android/SDL glue code is only
capable of correctly initializing OpenGL ES 1.1, probably resulting
in a mismatching renderer or invalid GL context.

good luck,

? ? ? ?Manuel

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[icculus]

Dimitris: so avoid legacy functions like SDL_SetVideoMode?

In theory, if all you want is the 1.2 API, SDL_SetVideoMode() should
do the right thing…it just wraps the 1.3 API with some limitations
(like the inability to have multiple windows, etc).

That being said, the 1.2 emulation is not perfect in places, so you’re
probably safer using the 1.3 API directly if you can.

I’ve actually been unable to find any example code that uses
SDL_CreateWindow, even in the SDL1.3 examples directory. Could you give
me an example, and is there anything I should try to strip out?

SDL/test/testgles.c

Sadly, all the important parts are all abstracted out to common.c (where
it handles multiple windows and all sorts of options you don’t care
about, etc), but you should be able to find what you need easily enough.

Using the SDL 1.3 API isn’t much more complicated that 1.2:

// this is untested, so forgive minor typos, please…

// just like 1.2 (but DO check return values!)
SDL_Init(SDL_INIT_VIDEO);
SDL_GL_LoadLibrary(NULL);

// Make a window…
win = SDL_CreateWindow(“My Application”,
SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED,
640, 480,
SDL_WINDOW_FULLSCREEN | SDL_WINDOW_SHOWN |
SDL_WINDOW_OPENGL);

// Create a GL context for that window…
SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
// etc…

// Make the major version 2 if you want GLES2 on Android.
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 0);
ctx = SDL_GL_CreateContext(win);
SDL_GL_MakeCurrent(win, ctx);

// You might want this to turn on/off vsync…
SDL_GL_SwapInterval(1); // 1 == vsync, 0 == no vsync.

// Now you can draw with OpenGL calls.

// Use this instead of SDL 1.2’s SDL_GL_SwapBuffers()…
SDL_GL_SwapWindow(win);

// At shutdown, you clean up…
SDL_GL_MakeCurrent(NULL, NULL);
SDL_GL_DeleteContext(ctx);
SDL_DestroyWindow(win);

// And finally, just like 1.2…
SDL_Quit();

Some of this was just being pedantic (you don’t actually have to do the
SDL_GL_MakeCurrent() calls), but that’s about all you need to know about
SDL’s video subsystem to move a 1.2 OpenGL app to 1.3.

That being said, I can’t account for bugs in our Android port. If you
find one, please report it.

I was really worried for a long time about moving from the 1.2 API,
which I’m extremely comfortable with, to 1.3, but the API is
surprisingly comfortable too…it feels easy like 1.2, but without 1.2’s
limitations.

–ryan.

[Manuel_Massing]

William,

I suspect you’re rendering into a double-buffer (even if not explicitly
requested). Try requesting a double-buffered surface explicitly using the
SDL_DOUBLEBUF | SDL_OPENGL flags, and call SDL_GL_SwapBuffers /
SDL_GL_SwapWindow after each frame.

Or use a renderer with SDL_RenderFillRect, SDL_RenderPresent, see
example code at http://wiki.libsdl.org/moin.cgi/SDL_RenderPresent

Manuel

[William_Dyce]

You beauty

I combined the Dimitris and Ryan’s examples (attached): I’ve never been so
happy to see a red rectangle The next step is getting an image to draw,
then I’ll give input a shot. That is, after I do a bit of probing to figure
out why it’s working now when it wasn’t before. I think it may be that we’re
now calling OpenGL functions like *glClearColor *and *SDL_GL_SwapWindow *rather
than the higher-level SDL_FillRect, and SDL_Flip.

Any reason why SDL_Flip might not be working? This all has me very
curious… I’ll need to get SDL 1.3 set up so I can test things on Linux as
well - pity you can’t just be a noob install it through Synaptic (which is
what I’ve generally done for 1.2).

WilliamOn 26 July 2011 17:09, Ryan C. Gordon wrote:

Dimitris: so avoid legacy functions like SDL_SetVideoMode?

In theory, if all you want is the 1.2 API, SDL_SetVideoMode() should do
the right thing…it just wraps the 1.3 API with some limitations (like the
inability to have multiple windows, etc).

That being said, the 1.2 emulation is not perfect in places, so you’re
probably safer using the 1.3 API directly if you can.

I’ve actually been unable to find any example code that uses

SDL_CreateWindow, even in the SDL1.3 examples directory. Could you give
me an example, and is there anything I should try to strip out?

SDL/test/testgles.c

Sadly, all the important parts are all abstracted out to common.c (where it
handles multiple windows and all sorts of options you don’t care about,
etc), but you should be able to find what you need easily enough.

Using the SDL 1.3 API isn’t much more complicated that 1.2:

// this is untested, so forgive minor typos, please…

// just like 1.2 (but DO check return values!)
SDL_Init(SDL_INIT_VIDEO);
SDL_GL_LoadLibrary(NULL);

// Make a window…
win = SDL_CreateWindow(“My Application”,
SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED,
640, 480,
SDL_WINDOW_FULLSCREEN | SDL_WINDOW_SHOWN |
SDL_WINDOW_OPENGL);

// Create a GL context for that window…
SDL_GL_SetAttribute(SDL_GL_**RED_SIZE, 8);
// etc…

// Make the major version 2 if you want GLES2 on Android.

SDL_GL_SetAttribute(SDL_GL_**CONTEXT_MAJOR_VERSION, 1);
SDL_GL_SetAttribute(SDL_GL_**CONTEXT_MAJOR_VERSION, 0);
ctx = SDL_GL_CreateContext(win);
SDL_GL_MakeCurrent(win, ctx);

// You might want this to turn on/off vsync…
SDL_GL_SwapInterval(1); // 1 == vsync, 0 == no vsync.

// Now you can draw with OpenGL calls.

// Use this instead of SDL 1.2’s SDL_GL_SwapBuffers()…
SDL_GL_SwapWindow(win);

// At shutdown, you clean up…
SDL_GL_MakeCurrent(NULL, NULL);
SDL_GL_DeleteContext(ctx);
SDL_DestroyWindow(win);

// And finally, just like 1.2…
SDL_Quit();

Some of this was just being pedantic (you don’t actually have to do the
SDL_GL_MakeCurrent() calls), but that’s about all you need to know about
SDL’s video subsystem to move a 1.2 OpenGL app to 1.3.

That being said, I can’t account for bugs in our Android port. If you find
one, please report it.

I was really worried for a long time about moving from the 1.2 API, which
I’m extremely comfortable with, to 1.3, but the API is surprisingly
comfortable too…it feels easy like 1.2, but without 1.2’s limitations.

–ryan.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

-------------- next part --------------
A non-text attachment was scrubbed…
Name: main.cpp
Type: text/x-c++src
Size: 1534 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110726/66ce91e9/attachment.cpp

[Dimitris_Zenios]

William you can create a renderer for the window and do render present
on the renderer.hat way you will not need the opengl code.You will use
the SDL rendering apiOn Tue, Jul 26, 2011 at 10:54 AM, William Dyce wrote:

You beauty

I combined the Dimitris and Ryan’s examples (attached): I’ve never been so
happy to see a red rectangle The next step is getting an image to draw,
then I’ll give input a shot. That is, after I do a bit of probing to figure
out why it’s working now when it wasn’t before. I think it may be that we’re
now calling OpenGL functions like glClearColor and SDL_GL_SwapWindow rather
than the higher-level SDL_FillRect, and SDL_Flip.

Any reason why SDL_Flip might not be working? This all has me very
curious… I’ll need to get SDL 1.3 set up so I can test things on Linux as
well - pity you can’t just be a noob install it through Synaptic (which is
what I’ve generally done for 1.2).

William

On 26 July 2011 17:09, Ryan C. Gordon wrote:

Dimitris: so avoid legacy functions like SDL_SetVideoMode?

In theory, if all you want is the 1.2 API, SDL_SetVideoMode() should do
the right thing…it just wraps the 1.3 API with some limitations (like the
inability to have multiple windows, etc).

That being said, the 1.2 emulation is not perfect in places, so you’re
probably safer using the 1.3 API directly if you can.

I’ve actually been unable to find any example code that uses
SDL_CreateWindow, even in the SDL1.3 examples directory. Could you give
me an example, and is there anything I should try to strip out?

SDL/test/testgles.c

Sadly, all the important parts are all abstracted out to common.c (where
it handles multiple windows and all sorts of options you don’t care about,
etc), but you should be able to find what you need easily enough.

Using the SDL 1.3 API isn’t much more complicated that 1.2:

?// this is untested, so forgive minor typos, please…

?// just like 1.2 (but DO check return values!)
?SDL_Init(SDL_INIT_VIDEO);
?SDL_GL_LoadLibrary(NULL);

?// Make a window…
?win = SDL_CreateWindow(“My Application”,
? ? ? ? ? ?SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED,
? ? ? ? ? ?640, 480,
? ? ? ? ? ?SDL_WINDOW_FULLSCREEN | SDL_WINDOW_SHOWN |
? ? ? ? ? ?SDL_WINDOW_OPENGL);

?// Create a GL context for that window…
?SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
?// etc…

?// Make the major version 2 if you want GLES2 on Android.
?SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1);
?SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 0);
?ctx = SDL_GL_CreateContext(win);
?SDL_GL_MakeCurrent(win, ctx);

?// You might want this to turn on/off vsync…
?SDL_GL_SwapInterval(1); ?// 1 == vsync, 0 == no vsync.

?// Now you can draw with OpenGL calls.

?// Use this instead of SDL 1.2’s SDL_GL_SwapBuffers()…
?SDL_GL_SwapWindow(win);

?// At shutdown, you clean up…
?SDL_GL_MakeCurrent(NULL, NULL);
?SDL_GL_DeleteContext(ctx);
?SDL_DestroyWindow(win);

?// And finally, just like 1.2…
?SDL_Quit();

Some of this was just being pedantic (you don’t actually have to do the
SDL_GL_MakeCurrent() calls), but that’s about all you need to know about
SDL’s video subsystem to move a 1.2 OpenGL app to 1.3.

That being said, I can’t account for bugs in our Android port. If you find
one, please report it.

I was really worried for a long time about moving from the 1.2 API, which
I’m extremely comfortable with, to 1.3, but the API is surprisingly
comfortable too…it feels easy like 1.2, but without 1.2’s limitations.

–ryan.

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[William_Dyce]

Dimitris: never actually used the renderer before. The
documentationhttp://wiki.libsdl.org/moin.cgi/SDL_CreateRendereris
pretty good though. I’m guessing SDL_RENDERER_ACCELERATED
isn’t going to work, any suggestions for what kind?

Just trying to get Code::Blocks to compile my project using SDL 1.3 rather
than 1.2 so I can do some tests on Linux as well as Android. This is looking
good so far though guys - thanks very much for all of you help

WilliamOn 26 July 2011 18:28, Dimitris Zenios <dimitris.zenios at gmail.com> wrote:

William you can create a renderer for the window and do render present
on the renderer.hat way you will not need the opengl code.You will use
the SDL rendering api

On Tue, Jul 26, 2011 at 10:54 AM, William Dyce <@William_Dyce> wrote:

You beauty

I combined the Dimitris and Ryan’s examples (attached): I’ve never been
so
happy to see a red rectangle The next step is getting an image to
draw,
then I’ll give input a shot. That is, after I do a bit of probing to
figure
out why it’s working now when it wasn’t before. I think it may be that
we’re
now calling OpenGL functions like glClearColor and SDL_GL_SwapWindow
rather
than the higher-level SDL_FillRect, and SDL_Flip.

Any reason why SDL_Flip might not be working? This all has me very
curious… I’ll need to get SDL 1.3 set up so I can test things on Linux
as
well - pity you can’t just be a noob install it through Synaptic (which
is
what I’ve generally done for 1.2).

William

On 26 July 2011 17:09, Ryan C. Gordon wrote:

Dimitris: so avoid legacy functions like SDL_SetVideoMode?

In theory, if all you want is the 1.2 API, SDL_SetVideoMode() should
do

the right thing…it just wraps the 1.3 API with some limitations (like
the

inability to have multiple windows, etc).

That being said, the 1.2 emulation is not perfect in places, so you’re
probably safer using the 1.3 API directly if you can.

I’ve actually been unable to find any example code that uses
SDL_CreateWindow, even in the SDL1.3 examples directory. Could you give
me an example, and is there anything I should try to strip out?

SDL/test/testgles.c

Sadly, all the important parts are all abstracted out to common.c (where
it handles multiple windows and all sorts of options you don’t care
about,

etc), but you should be able to find what you need easily enough.

Using the SDL 1.3 API isn’t much more complicated that 1.2:

// this is untested, so forgive minor typos, please…

// just like 1.2 (but DO check return values!)
SDL_Init(SDL_INIT_VIDEO);
SDL_GL_LoadLibrary(NULL);

// Make a window…
win = SDL_CreateWindow(“My Application”,
SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED,
640, 480,
SDL_WINDOW_FULLSCREEN | SDL_WINDOW_SHOWN |
SDL_WINDOW_OPENGL);

// Create a GL context for that window…
SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
// etc…

// Make the major version 2 if you want GLES2 on Android.
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 0);
ctx = SDL_GL_CreateContext(win);
SDL_GL_MakeCurrent(win, ctx);

// You might want this to turn on/off vsync…
SDL_GL_SwapInterval(1); // 1 == vsync, 0 == no vsync.

// Now you can draw with OpenGL calls.

// Use this instead of SDL 1.2’s SDL_GL_SwapBuffers()…
SDL_GL_SwapWindow(win);

// At shutdown, you clean up…
SDL_GL_MakeCurrent(NULL, NULL);
SDL_GL_DeleteContext(ctx);
SDL_DestroyWindow(win);

// And finally, just like 1.2…
SDL_Quit();

Some of this was just being pedantic (you don’t actually have to do the
SDL_GL_MakeCurrent() calls), but that’s about all you need to know about
SDL’s video subsystem to move a 1.2 OpenGL app to 1.3.

That being said, I can’t account for bugs in our Android port. If you
find

one, please report it.

I was really worried for a long time about moving from the 1.2 API,
which

I’m extremely comfortable with, to 1.3, but the API is surprisingly
comfortable too…it feels easy like 1.2, but without 1.2’s limitations.

–ryan.

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org