Hi,
I’ve noticed when testing the demo apps on the iPhone 4, there appears to be an issue when returning to an app after you have pressed the home button.
It appears that once you return to the app, the position of the main SDL_Window moves up and right, so what used to be the bottom left pixel of the screen, now sits at the center.
It does not do this on the simulator, only on the device.
Has anyone else noticed this or found the solution?
Thanks
entry = (entry->next == entry)?(NULL):(entry->next);
a hackish solution, but hey.------------------------
EM3 Nathaniel Fries, U.S. Navy
Well, I’ve tracked it down to the SDL_UpdateFullscreenMode function in SDL_Video.c.
Basically SDL is taking the max resolution for Apples retina display (640, 960) as the resolution to use upon a restore, instead of the 320x480 resolution I gave it at startup. If I hardcode my resolution right into the SDL_UpdateFullscreenMode function then it restores correctly. Obviously there’s a correct place to get the resolution from, I’m just totally inexperienced with SDL so I don’t know where it is (SDL_GetDisplayModeSomethingOrOther?). I’ll try and track it down as my caffeine high allows.
On another note. When I minimize AGAIN, after having min/maxed once already, then the SDL_DisplayMode->driverdata (a UIScreenMode instance) is null and causes an exception in UIScreen -setCurrentMode: function. This happens in the current SDL version out of the box, without my resolution hardcoding nonsense.
Thanks for a great library! I’ll try to do my part and get back with some more solid info so we can patch this soon.
NOOOOOOOO! NEW BUG!
Code:
entry = rdata->program_cache.head;
while (entry)
{
if (entry->vertex_shader == vertex && entry->fragment_shader == fragment)
break;
entry = entry->next;
}
My app never leaves this loop! (SDL_render_gles2.c, GLES2_CacheProgram function).
Bad day for me 
BUMP! Me too. Anyone have any insights? Only on device, using iOS 4.2 latest SDL 1.3 build.
Wow, debugging other peoples code is so much easier than debugging mine. I guess we are most blind to the mistakes we make (duh!).
Anyways, I found the missing UIScreenMode instance. In the UIKit_AddDisplay function in SDL_uikitvideo.m, you create desktop_mode and current_mode SDL_DisplayMode instances without assigning them driver data. Later on UIKit_SetDisplayMode expects them to have valid driver data. I just changed
Code:
UIKit_AddDisplay(UIScreen *uiscreen, int w, int h)
to
Code:
UIKit_AddDisplay(UIScreen *uiscreen, UIScreenMode *uimode, int w, int h)
and plopped a retained UIScreenMode in the driver data slot. Now my SDL app can minimize and maximize to hearts content with no crashes! YAY![/code]
Hi,
Make sure to file a bug for this.
Regards,
Armin
hey good job fixing the bug! mind sharing the patch or link us to your repo?
i quote Armin and hope that you’ll open bugs for such problems
bye
VittorioOn Mon, Apr 25, 2011 at 9:21 AM, eclectocrat wrote:
Wow, debugging other peoples code is so much easier than debugging mine.
I guess we are most blind to the mistakes we make (duh!).Anyways, I found the missing UIScreenMode instance. In the UIKit_AddDisplay
function in SDL_uikitvideo.m, you create desktop_mode and current_mode
SDL_DisplayMode instances without assigning them driver data. Later on
UIKit_SetDisplayMode expects them to have valid driver data. I just changedCode:
UIKit_AddDisplay(UIScreen *uiscreen, int w, int h)
to
Code:
UIKit_AddDisplay(UIScreen *uiscreen, UIScreenMode *uimode, int w, int h)
and plopped a retained UIScreenMode in the driver data slot. Now my SDL app
can minimize and maximize to hearts content with no crashes! YAY![/code]
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I don’t even know how to ‘patch’ and have never had a ‘repo’. I’m from what some people have called the command line challenged generation, I rarely leave the comfort of a GUI IDE (Many developers are appalled at my lack of devtools savvy). I did manage to post bug reports on bugzilla, so I’m learning! Now I’m off to google for some resources on patching and diff files and generally contributing to open source projects embarrassed grin.
“hg diff > fixingiOS.patch” should do the trick, if I’m not mistaken
If you have TortoiseHg, should be able to save the diff by going to TortoiseHg->Visual Diff, which brings up KDiff, and going to file->save as
Don’t worry, I’m also from that generation, but I do happen to be a very good googler.------------------------
EM3 Nathaniel Fries, U.S. Navy
A bit of help:
Any serious open-source project these days is going to be run off a repository,
a server that holds source control data for the project. There are several
types of repositories; the most common these days are Subversion (SVN), Git and
Mercurial. You can get clients for each of these (well, for SVN and Mercurial
at least, and probably for Git as well) that integrate directly into Windows as
shell extensions. They can keep track of what you’ve changed locally and create
a diff file that describes the changes, which you can submit to Bugzilla, or
apply a diff file to your local copy of the code.
Also, if you’re at all serious about contributing to an open-source project, I
recommend you get yourself a copy of BeyondCompare, from Scooter Software. It’s
hands down the best diff/merge tool around and will greatly simplify the process
of working with version control. It’s not free, but it’s not expensive either.
There are Windows and Linux versions available, and I know the principal author
and he’s planning on releasing a Mac version soon, most likely towards the end
of this year. Once you’ve used it for a few weeks, it ends up being one of
those “how did I ever get by without this?” tools.________________________________
From: jurksztowicz@gmail.com (Jeremy Jurksztowicz)
Subject: Re: [SDL] SDL 1.3 and iOS - Returning to an app issue.
I don’t even know how to ‘patch’ and have never had a ‘repo’. I’m from what some
people have called the command line challenged generation, I rarely leave the
comfort of a GUI IDE (Many developers are appalled at my lack of devtools
savvy). I did manage to post bug reports on bugzilla, so I’m learning! Now I’m
off to google for some resources on patching and diff files and generally
contributing to open source projects embarrassed grin.
as another option, you could even post here the whole file(s) you modified
or at worst zip the sdl folder and upload it somewhere on the net
VittorioOn Thu, Apr 28, 2011 at 3:08 AM, eclectocrat wrote:
I don’t even know how to ‘patch’ and have never had a ‘repo’. I’m from what
some people have called the command line challenged generation, I rarely
leave the comfort of a GUI IDE (Many developers are appalled at my lack of
devtools savvy). I did manage to post bug reports on bugzilla, so I’m
learning! Now I’m off to google for some resources on patching and diff
files and generally contributing to open source projects embarrassed grin.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Hello!
I mucked around with the SDL_render_gles2.c file and managed to make a workaround for the GL program caching infinite loop. It’s not really a fix, because I haven’t addressed the fundamental problem of the linked list being constructed incorrectly.
In the GLES2_CacheProgram change:
Code:
/* Check if we’ve already cached this program */
entry = rdata->program_cache.head;
while (entry)
{
if (entry->vertex_shader == vertex && entry->fragment_shader == fragment)
break;
entry = entry->next;
}
To:
Code:
/* Check if we’ve already cached this program */
entry = rdata->program_cache.head;
while (entry)
{
if (entry->vertex_shader == vertex && entry->fragment_shader == fragment)
break;
/* Quick 'n dirty hack! The linked list is not managed properly. */
if(entry == rdata->program_cache.tail)
{
entry = 0;
break;
}
entry = entry->next;
}
I’m working off an old snapshot and still haven’t learned about patching and diff files [Embarassed], too much of my own work to wrap my head around, but this little tweak has allowed me to minimize and restore to my hearts content. One POSSIBLE side effect (because I don’t know the structure of the malformed linked list), is that duplicate program caching may occur, but it should never get out of hand because further down the same function there is a safeguard to prevent boundless caching.
Once I’ve finished with my project I promise I’ll learn to patch!
AAaaargh!
Nevermind. My program was apparently working fine, but when drawing certain largish images the thing slows to a crawl. My ‘workaround’ as it turned out was being indirectly called by GLES2_RenderCopy zillions of times and for whatever reason couldn’t gracefully handle large images. My guess is that the code I changed made the cache hit rate 0 and so new shaders were being made every draw. I’ll get around to fixing the linked list at some point…
eclectocrat wrote:
Wow, debugging other peoples code is so much easier than debugging mine. I guess we are most blind to the mistakes we make (duh!).
Anyways, I found the missing UIScreenMode instance. In the UIKit_AddDisplay function in SDL_uikitvideo.m, you create desktop_mode and current_mode SDL_DisplayMode instances without assigning them driver data. Later on UIKit_SetDisplayMode expects them to have valid driver data. I just changed
Code:
UIKit_AddDisplay(UIScreen *uiscreen, int w, int h)to
Code:
UIKit_AddDisplay(UIScreen *uiscreen, UIScreenMode *uimode, int w, int h)and plopped a retained UIScreenMode in the driver data slot. Now my SDL app can minimize and maximize to hearts content with no crashes! YAY![/code]
eclectocrat, I’m having this same problem and I’m not very comfortable working wit Objective-C code yet. Could you please elaborate on the solution? If you’ve posted a bug entry in bugzilla with a patch, linking to that should be enough.
For what I understand, if you post the code for the UIKit_AddDisplay() and UIKit_VideoInit() functions (the one calling UIKit_AddDisplay) would be enough and I could post the patch for you.
I’ve been able to sidestep the issue by commenting out lines 232 & 233 in SDL_uikitvideo.m and thus disabling multiple display support.
Obviously it’s not a fix.