Hey, I’m working on SDL 1.3 during my vacation this week, and I wanted to
get some feedback on what needs to be done before the first release.
Please reply to this e-mail with your thoughts, and please make sure any
bugs or patches get added to bugzilla, marked with SDL version 1.3.0.
http://bugzilla.libsdl.org/
Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
Hey, I’m working on SDL 1.3 during my vacation this week, and I wanted to
get some feedback on what needs to be done before the first release.
FYI, you can checkout the current PRERELEASE source snapshot here:
http://www.libsdl.org/tmp/SDL-1.3.zip
or
http://www.libsdl.org/tmp/SDL-1.3.tar.gz
See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
Le 25 nov. 08 ? 08:41, Sam Lantinga a ?crit :
Please reply to this e-mail with your thoughts, and please make sure
any
bugs or patches get added to bugzilla, marked with SDL version 1.3.0.
Maybe more documentation would be nice. I tried to doxygen the headers
but the result is a little bit dry.
Best,
Daniel
Hello !
Hey, I’m working on SDL 1.3 during my vacation this week, and I wanted to
get some feedback on what needs to be done before the first release.Please reply to this e-mail with your thoughts, and please make sure any
bugs or patches get added to bugzilla, marked with SDL version 1.3.0.
http://bugzilla.libsdl.org/
A test that should be added to configure :
Is libunicows available or not.
The standard MinGW distribution does not have it onboard, i think,
the same goes for CYGWIN. There should be a ZIP online, so
that people can install it easily, the same way like the directx,
opengl and nasm files.
CU
Hello !
Compilation of testmmousetablet.c fails,
because the main function has not the
standard format.---------------------------------------
— testmmousetablet.c (revision 4136)
+++ testmmousetablet.c (working copy)
@@ -5,7 +5,7 @@
int quit = 0;
int
-main()
+main(int argc, char *argv [])
{
SDL_Event event;
int mice;
wizard at wizardspc ~/code/SDL/SDL2/test
$
CU
Hello !
testsprite2 works correctly, testsprite called with
-bpp 8 fails
-bpp 16 produces wrong background colors
-bpp 24 works correctly
-bpp 32 produces wrong background colors
Called with -bpp 32 gives this output :
http://www.syntheticsw.com/~wizard/tmp/SDL2_testsprite.png
CU
Hello !
I am so used to that the testsprite example produces
a black background, so i first thought, testsprite2
does not work correct, as it has a grey background.
My wish would be to change the background color
to black :----------------------
— testsprite2.c (revision 4136)
+++ testsprite2.c (working copy)
@@ -119,7 +119,7 @@
/* Move the sprite, bounce at the wall, and draw */
n = 0;
SDL_RenderFill(0xA0, 0xA0, 0xA0, 0xFF, NULL);
SDL_RenderFill(0xFF, 0xFF, 0xFF, 0xFF, NULL);
SDL_RenderFill(0xA0, 0xA0, 0xA0, 0xFF, NULL);
SDL_RenderFill(0xFF, 0xFF, 0xFF, 0xFF, NULL);
break;
}
break;
CU
Hey, I’m working on SDL 1.3 during my vacation this week, and I
wanted to get some feedback on what needs to be done before the first
release.Please reply to this e-mail with your thoughts, and please make sure
any bugs or patches get added to bugzilla, marked with SDL version
1.3.0. http://bugzilla.libsdl.org/Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I’ve not had time to look at the code but did the atomic integer code
make it in? I don’t recall getting any feedback on it.
-antonioOn Mon, 24 Nov 2008 23:41:56 -0800 Sam Lantinga wrote:
Hello !
I am so used to that the testsprite example produces
a black background, so i first thought, testsprite2
does not work correct, as it has a grey background.
My wish would be to change the background color
to black :
It’s grey so that the other blend modes show up better for testing.
I can change the older testsprite to grey, if you want. 
See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
Hello !
It’s grey so that the other blend modes show up better for testing.
I can change the older testsprite to grey, if you want.
If there is a reason for grey it is okay
CU
Hello, Sam!
SL> Hey, I’m working on SDL 1.3 during my vacation this week, and I wanted
SL> to get some feedback on what needs to be done before the first release.
SL> Please reply to this e-mail with your thoughts, and please make sure
SL> any bugs or patches get added to bugzilla, marked with SDL version
SL> 1.3.0. http://bugzilla.libsdl.org/
It would be nice to have a function which could flush all asynchronous 2D
blitting (and not only blitting) operations, like glFlush() does for OpenGL.
In my QNX port of SDL 1.2.x branch (Photon GDI) I’ve added blit flushing
after each blit operation and this causes a great perfomance loss. Otherwise
some tests were failed (like testalpha). Because it uses blitting operation
to main visible surface and back blitting from visible surface to sprite
surface with software surface access by CPU, in case of using asynchronous
blit operations it causes reading from surface by CPU before 2D accellerator
has finished blitting operation.
And now I can see, that SDL_ASYNCBLIT is deprecated in the SDL_compat.h and
has bogus value shared with other deprecated constants. Maybe it would be
better to remove SDL_ASYNCBLIT occurences in the all source code tree and
documentation OR add real asynchronous blitting support with appropriate
SDL_xxxxxxx function call (including SDL video driver call entry) which
could flush all delayed blit operations. I would vote for the second
solution.
SDL has SDL_UpdateRects() function but it is usable for software surface
access only, not for the hardware blitting, bacause it is not possible to
trace all drawed primitives to check which is must be updated by coordinates
intersection with updating region and drawed primitive or blit operation.
Asynchronous blits could really speed-up rendering using 2D accelleration
(without OpenGL), for example in the SCADA systems which output a lot small
sprites producing a large picture ( just for the example (I’m not an owner
of these images): http://www.atasel.com.tr/images/im_efes_scada.jpg ,
http://www.arecont.com/scada.gif ,
http://www.plcdirect.eu/upload/ADC/Software/p2_t_scada.jpg).
With best regards, Mike Gorchak. E-mail: @Mike_Gorchak
I’ve not had time to look at the code but did the atomic integer code
make it in? I don’t recall getting any feedback on it.
Not yet, did you put it in bugzilla so it doesn’t get lost?
See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
I’ve not had time to look at the code but did the atomic integer
code make it in? I don’t recall getting any feedback on it.Not yet, did you put it in bugzilla so it doesn’t get lost?
See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
No I hadn’t. I just created it.
http://bugzilla.libsdl.org/show_bug.cgi?id=646On Wed, 26 Nov 2008 07:52:19 -0800 Sam Lantinga wrote:
I believe I have seen separate libraries that provide this capability.
Perhaps 1.3 is the right time to add such support to SDL, but in the
meantime if you want that functionality, it’s not terribly difficult
to implement yourself with varying degrees of sophistication.On Wed, Nov 26, 2008 at 7:47 AM, Mike Gorchak wrote:
It would be nice to have a function which could flush all asynchronous 2D
blitting (and not only blitting) operations, like glFlush() does for OpenGL.
