I have a couple of issues blitting to a window surface.
SDL is giving an error if the target rectangle does not
intersect with the surface. This is not documented in the source,
on the contrary, the header says rectangle validation and clipping is done.
In that context it is not an error to blit off the surface, an empty set is
a perfectly valid set. Its not clear what other error could exist
except perhaps a NULL pointer, but the comment is imprecise.
When I resize the window, I have to redraw. It isn’t clear
what to do with the old window surface. Should be documented.
The header file actually says the surface is freed when the window
is destroyed, but it neglects to say what happens if the window is
resized and the old surface is no longer applicable.
On OSX 10.6 I get two events: window resized and size_changed.
I do not get an exposed event. When should I redraw?
There is a problem here: when I grab the corner of the window
and resize there’s no event until I release the mouse button.
So when making it bigger the new parts of the window are full of
mouse droppings (specifically the corner tab which isn’t actually
visible until I try to resize, probably because I overwrote it).
This doesn’t happen on a real OSX application, eg MacVim.
It redraws during the resize and the window is always clean.
I think the desired events would be:
begin_resize // when i start resizing
new_size // regularly when the mouse is moved holding corner
end_resize // when i release the mouse and final size set
If using SDL_Blit do I have to lock or unlock?
I assume no (since I’m not playing with the pixels directly.
Now some curiosity: SDL seems to contain a mix of archaic and
more modern API calls. For example SDL_FillRect wants a weird
pixel format, and I have to calculate that with SDL_MapRGB(A),
which accepts separate parameters, but not an SDL_Color.
[One reason C++ is better: you could easily add an overload]
Pixel based technology (raster displays) are quite distinct
from vector (scalable line drawing) display, which is actually a special
case of modern GPU based operations (where you
just give the GPU a model and it does all the work).
So apart from “compatibility” is there a reason to keep
the pixel technology? [Just looking for some conceptual
insight]
At present I’m using SDL_ttf which uses surfaces and Blits,
but this seems to exclude using an OpenGL context on the
same window (the docs actually say 3D … is that the same thing?)
I can understand that but if so how does one get text into
an OpenGL based window?
BTW: My first application will be an SDL based text editor
using the classic video technology I actually invented a long
time ago. With SDL I can finally get hold of the actual keys
on a keyboard. Just magic to have something finally work.
SDL_Blit still exists? o_O (wiki says SDL_BlitSurface instead)
The window needing to be redrawn on resize is a pretty well known
situation, this happens with pretty much any API that deals with the
GPU. Heck, any API, period - the operating system expects the program
to repaint the entire thing if the window gets resized.
If I recall correctly, surfaces are still there in case somebody wants
to deal with bitmaps for whatever reason (e.g. SDL_Image does this to
put the images it loads somewhere). Also the idea behind being able to
deal with pixel units is in case the program wants to do something at
a pixel perfect level (though now you can scale the proportion if your
program doesn’t want to do that - and even then for 2D using -1 to 1
coordinates is a chore, be it bitmap or vector).
2013/6/16, john skaller :> I have a couple of issues blitting to a window surface.
SDL is giving an error if the target rectangle does not
intersect with the surface. This is not documented in the source,
on the contrary, the header says rectangle validation and clipping is done.
In that context it is not an error to blit off the surface, an empty set is
a perfectly valid set. Its not clear what other error could exist
except perhaps a NULL pointer, but the comment is imprecise.
When I resize the window, I have to redraw. It isn’t clear
what to do with the old window surface. Should be documented.
The header file actually says the surface is freed when the window
is destroyed, but it neglects to say what happens if the window is
resized and the old surface is no longer applicable.
On OSX 10.6 I get two events: window resized and size_changed.
I do not get an exposed event. When should I redraw?
There is a problem here: when I grab the corner of the window
and resize there’s no event until I release the mouse button.
So when making it bigger the new parts of the window are full of
mouse droppings (specifically the corner tab which isn’t actually
visible until I try to resize, probably because I overwrote it).
This doesn’t happen on a real OSX application, eg MacVim.
It redraws during the resize and the window is always clean.
I think the desired events would be:
begin_resize // when i start resizing
new_size // regularly when the mouse is moved holding corner
end_resize // when i release the mouse and final size set
If using SDL_Blit do I have to lock or unlock?
I assume no (since I’m not playing with the pixels directly.
Now some curiosity: SDL seems to contain a mix of archaic and
more modern API calls. For example SDL_FillRect wants a weird
pixel format, and I have to calculate that with SDL_MapRGB(A),
which accepts separate parameters, but not an SDL_Color.
[One reason C++ is better: you could easily add an overload]
Pixel based technology (raster displays) are quite distinct
from vector (scalable line drawing) display, which is actually a special
case of modern GPU based operations (where you
just give the GPU a model and it does all the work).
So apart from “compatibility” is there a reason to keep
the pixel technology? [Just looking for some conceptual
insight]
At present I’m using SDL_ttf which uses surfaces and Blits,
but this seems to exclude using an OpenGL context on the
same window (the docs actually say 3D … is that the same thing?)
I can understand that but if so how does one get text into
an OpenGL based window?
BTW: My first application will be an SDL based text editor
using the classic video technology I actually invented a long
time ago. With SDL I can finally get hold of the actual keys
on a keyboard. Just magic to have something finally work.
SDL_Blit still exists? o_O (wiki says SDL_BlitSurface instead)
Sorry, I was abbreviating
SDL_BlitSurface it is.
The window needing to be redrawn on resize is a pretty well known
situation, this happens with pretty much any API that deals with the
GPU. Heck, any API, period - the operating system expects the program
to repaint the entire thing if the window gets resized.
I know. The problem, as outlined, is that it isn’t clear how
this impacts the pointer to the SDL_surface obtained by
SDL_GetWindowSurface.
I assume it is invalidated, a new surface must be obtained,
and the old one is taken care of by the system. Is that correct?
If I recall correctly, surfaces are still there in case somebody wants
to deal with bitmaps for whatever reason (e.g. SDL_Image does this to
put the images it loads somewhere). Also the idea behind being able to
deal with pixel units is in case the program wants to do something at
a pixel perfect level
Yeah, ok, that’s reasonable. But how do I put text on an OpenGL
based window? Seems GL stuff an raster stuff don’t mix.On 16/06/2013, at 9:23 PM, Sik the hedgehog wrote:
Um, there isn’t any function to update a texture with the data from a
surface, only to create one (updating would be useful e.g. for HUD
text using SDL_ttf or for textures that are animated), so that one
case needs to be done by copying pixels by hand. Maybe a function
should be added to cover that case too?
Yeah, SDL_BlitSurface is fine without locking. Locking is for e.g. when
SDL has to convert the pixels (due to RLE) or make sure they aren’t being
used (hardware surface) before you touch them.
Are you using OpenGL or are you using the SDL renderer API (you are using
SDL 2.0, right?)? I have some OpenGL/GLES code that works reasonably well
for creating textures from SDL_Surfaces, updating textures, and copying
textures back into SDL_Surfaces as part of my SDL_gpu project: https://code.google.com/p/sdl-gpu/
Jonny DOn Sun, Jun 16, 2013 at 8:32 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:
2013/6/16, john skaller :
Yeah, ok, that’s reasonable. But how do I put text on an OpenGL
based window? Seems GL stuff an raster stuff don’t mix.
Um, there isn’t any function to update a texture with the data from a
surface, only to create one (updating would be useful e.g. for HUD
text using SDL_ttf or for textures that are animated), so that one
case needs to be done by copying pixels by hand. Maybe a function
should be added to cover that case too?
Yeah, SDL_BlitSurface is fine without locking. Locking is for e.g. when SDL has to convert the pixels (due to RLE) or make sure they aren’t being used (hardware surface) before you touch them.
Ok, thanks for info!
Are you using OpenGL or are you using the SDL renderer API (you are using SDL 2.0, right?)?
i am using bleeding edge SDL2 from mercurial repo
I’m not using either OpenGL or the render API at this point,
I’m writing a binding and a test application to check the binding.
The test app is currently using an SDL_Surface obtained by
SDL_CreateWindow and SDL_GetWindowSurface.
I guess these are legacy routines, because it seems hard to do
basic things like draw lines, draw a caret, etc. And, these routines
are in my old SDL 1.x binding.
I have some OpenGL/GLES code that works reasonably well for creating textures from SDL_Surfaces, updating textures, and copying textures back into SDL_Surfaces as part of my SDL_gpu project: https://code.google.com/p/sdl-gpu/
I’m running OSX. I’ve built and installed your package no problem.
Only got a *.a file though, no shared lib (.dylib on OSX).
The demos run but the images are all scrambled.On 17/06/2013, at 12:06 AM, Jonathan Dearborn wrote:
I guess these are legacy routines, because it seems hard to do
basic things like draw lines, draw a caret, etc. And, these routines
are in my old SDL 1.x binding.
Sorta, I believe. Not like SDL 1.x provided any of those functions (it
didn’t even provide a put pixel function!).
I think another of the reasons why surfaces are still there is non-RGB
formats. Remember surfaces can be YUV and stuff like that, and
handling things this way means the conversion from those formats to
RGB is left to SDL.
