I don’t know very much about SDL’s backend, or about the conventional iOS and ObjC environment, so I’m open to any comments. From my experience, when the iOS status bar is shown, the pixels under the translucent status bar are unavailable to the SDL renderer. I’ve only found one way to change the pixels. They become the color that the SDL renderer is cleared with.
I’ve noticed other apps, that probably don’t use SDL, can have images under the status bar. Can this be done with SDL? Can I move the SDL renderer to underneath the status bar?
Are you using SDL_RenderSetLogicalSize? If so, it letterboxes the usable area of the screen to the aspect ratio of the dimensions you set, which means if your given aspect ratio is wider than the screen?s native ratio then there will be areas at the top and bottom of the screen where you can?t draw.> On Feb 17, 2015, at 10:20 PM, ace491 wrote:
I don’t know very much about SDL’s backend, or about the conventional iOS and ObjC environment, so I’m open to any comments. From my experience, when the iOS status bar is shown, the pixels under the translucent status bar are unavailable to the SDL renderer. I’ve only found one way to change the pixels. They become the color that the SDL renderer is cleared with.
I’ve noticed other apps, that probably don’t use SDL, can have images under the status bar. Can this be done with SDL? Can I move the SDL renderer to underneath the status bar?
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
No I’m not. Here’s a simple loop that draws a red rectangle. Even though the rectangle is at a position of 0, it is drawn just under the status bar. Essentially the status bar pushes the renderer down. ALTHOUGH, after testing this code, the renderer is not pushed down until after the second SDL_RenderPresent. The rectangle is under the status bar after the first SDL_RenderPresent, but not the second.
Code:
int main(int argc, char* args[])
{
SDL_Init(SDL_INIT_VIDEO);
SDL_Window* window = SDL_CreateWindow("", 100,100,500,500, 0);
SDL_Renderer* renderer = SDL_CreateRenderer(window, -1, 0);
bool running = true;
while (running)
{
SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
SDL_RenderClear(renderer);
SDL_SetRenderDrawColor(renderer, 255, 0, 0, 255);
SDL_Rect rect = {0,0,100,100};
SDL_RenderFillRect(renderer, &rect);
SDL_RenderPresent(renderer);
SDL_Event event;
while (SDL_PollEvent(&event))
{
if (event.type == SDL_QUIT)
running = false;
}
SDL_Delay(1000);
}
return 0;
}
SDL?s current iOS code has a lot of bugs and issues when run on modern iOS versions. I have a fork[1] (or a patch[2], if you prefer) which fixes many of the issues. Maybe you?ve encountered a bug that?s been fixed by my updates?
[1]: https://bitbucket.org/slime73/sdl-experiments/branch/iOS-improvements https://bitbucket.org/slime73/sdl-experiments/branch/iOS-improvements / https://bitbucket.org/slime73/sdl-experiments/get/iOS-improvements.zip https://bitbucket.org/slime73/sdl-experiments/get/iOS-improvements.zip
[2]: https://bugzilla.libsdl.org/show_bug.cgi?id=2798 https://bugzilla.libsdl.org/show_bug.cgi?id=2798> On Feb 17, 2015, at 11:45 PM, ace491 wrote:
No I’m not. Here’s a simple loop that draws a red rectangle. Even though the rectangle is at a position of 0, it is drawn just under the status bar. Essentially the status bar pushes the renderer down. ALTHOUGH, after testing this code, the renderer is not pushed down until after the second SDL_RenderPresent. The rectangle is under the status bar after the first SDL_RenderPresent, but not the second.
Code:
int main(int argc, char* args[])
{
SDL_Init(SDL_INIT_VIDEO);
SDL_Window* window = SDL_CreateWindow("", 100,100,500,500, 0);
SDL_Renderer* renderer = SDL_CreateRenderer(window, -1, 0);bool running = true; while (running) { SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255); SDL_RenderClear(renderer); SDL_SetRenderDrawColor(renderer, 255, 0, 0, 255); SDL_Rect rect = {0,0,100,100}; SDL_RenderFillRect(renderer, &rect); SDL_RenderPresent(renderer); SDL_Event event; while (SDL_PollEvent(&event)) { if (event.type == SDL_QUIT) running = false; } SDL_Delay(1000); } return 0;}
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
Thanks! I’ll test your fork out tomorrow. Browsing through your commits, it looks like you’ve made a lot of important improvements. Why are they not added/merged to the main SDL branch?
I think doing that is the plan, but the diff is pretty huge as far as patches go and Ryan and Sam don?t have a lot of free time to spend on SDL these days, so it might take a while for it to be properly looked over and such. :)> On Feb 18, 2015, at 12:14 AM, ace491 wrote:
Thanks! I’ll test your fork out tomorrow. Browsing through your commits, it looks like you’ve made a lot of important improvements. Why are they not added/merged to the main SDL branch?
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
This is great to have a patch of improvements for IOS.
If the patch is huge, maybe it is worth splitting it in smaller
independant patches.
It will be easier to commit, and also for other people to review it.
Some patch may be applied, and some not.
Moreover, if someone find an issue with IOS, it will also be easier to
debug if we have several distinct commits.On Wed, Feb 18, 2015 at 5:22 AM, Alex Szpakowski wrote:
I think doing that is the plan, but the diff is pretty huge as far as
patches go and Ryan and Sam don?t have a lot of free time to spend on SDL
these days, so it might take a while for it to be properly looked over and
such.On Feb 18, 2015, at 12:14 AM, ace491 wrote:
Thanks! I’ll test your fork out tomorrow. Browsing through your commits, it
looks like you’ve made a lot of important improvements. Why are they not
added/merged to the main SDL branch?
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
–
Sylvain Becker
I?ve thought about doing that, but most of it can?t really be split up like that without a lot of trouble. For example I could split the memory leak fixes (adding autorelease pool blocks to a lot of functions) out to its own patch, but some of the functions covered by that only exist in my forked code, and some of the functions in the main SDL repository that would need those autorelease pools don?t exist in my fork.
Most of the other changes are much more interlinked than that. The retina-resolution changes affect rotation and OpenGL ES context and display-mode and window code. Which also describes what many of the other changes affect, including the move to ARC (since I changed the iOS SDL_DisplayModeData, SDL_WindowData, etc. structs to Objective-C classes for ARC to work nicer, but the retina-resolution changes also touched those classes.) Most of the individual changes would need at least some parts rewritten without ARC.
I could keep giving examples like that? :)> On Feb 18, 2015, at 3:24 AM, Sylvain Becker <sylvain.becker at gmail.com> wrote:
This is great to have a patch of improvements for IOS.
If the patch is huge, maybe it is worth splitting it in smaller
independant patches.
It will be easier to commit, and also for other people to review it.
Some patch may be applied, and some not.Moreover, if someone find an issue with IOS, it will also be easier to
debug if we have several distinct commits.Sylvain Becker
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Yes, of course. need to split what can be actually split.
Though, a patch with “memory leak fixes” should be considered as
critical and applied with higher priority !On Wed, Feb 18, 2015 at 8:38 AM, Alex Szpakowski wrote:
I?ve thought about doing that, but most of it can?t really be split up like that without a lot of trouble. For example I could split the memory leak fixes (adding autorelease pool blocks to a lot of functions) out to its own patch, but some of the functions covered by that only exist in my forked code, and some of the functions in the main SDL repository that would need those autorelease pools don?t exist in my fork.
Most of the other changes are much more interlinked than that. The retina-resolution changes affect rotation and OpenGL ES context and display-mode and window code. Which also describes what many of the other changes affect, including the move to ARC (since I changed the iOS SDL_DisplayModeData, SDL_WindowData, etc. structs to Objective-C classes for ARC to work nicer, but the retina-resolution changes also touched those classes.) Most of the individual changes would need at least some parts rewritten without ARC.
I could keep giving examples like that?
On Feb 18, 2015, at 3:24 AM, Sylvain Becker <@Sylvain_Becker> wrote:
This is great to have a patch of improvements for IOS.
If the patch is huge, maybe it is worth splitting it in smaller
independant patches.
It will be easier to commit, and also for other people to review it.
Some patch may be applied, and some not.Moreover, if someone find an issue with IOS, it will also be easier to
debug if we have several distinct commits.Sylvain Becker
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
–
Sylvain Becker
I can confirm your fork fixed the status bar problem. I can now draw under the status bar. Thanks!
I would really love for this stuff to get into the main branch. I depend a lot on SDL on iOS.