headers
keithhards | 1 Feb 2007 08:45
Favicon

UNSUBSCRIBE FROM MAILING LIST


HELLO,

PLEASE UBNSUBSCRIBE ME FROM THE MAILING LIST.

Regards,

Keith Hards,

TEL: (01843) 600092
MOB:  07921 678252

http://www.pennyfalls.com

Signup to supanet at https://signup.supanet.com/cgi-bin/signup?_origin=sigwebmail
Permalink | Reply | 2 comments |
headers
realstudent | 1 Feb 2007 12:57
Picon
Favicon

SDL 1.3 test working on dual monitors but need help

Hello! Sorry for bad english. My post "Control nultiple window om different 
display" stay withou answers, but i solve problems. Now I have example 
(corrected testsprite2.c) - his draw in different windows (each on the own 
display). But i have massive memory leaks (approbed in valgrind)! Please view 
my example and help if error in the source. Leaks appears in GL_LockTexture 
(SDL_renderer_gl.c:666) - i found what a function GL_UnlockTexture - 
unimplemented (have a void body), i kill allocated textures 
SDL_DestroyTexture() - but this not solve problem! Please help.

/* Simple program:  Move N sprites around on the screen as fast as possible */

#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <string.h>

#include "common.h"

#define NUM_SPRITES	100
static SDL_TextureBlendMode blendMode = SDL_TEXTUREBLENDMODE_MASK;
static SDL_TextureScaleMode scaleMode = SDL_TEXTURESCALEMODE_NONE;
static int num_sprites;

static CommonState *state;
static SDL_TextureID sprites_displ0[260];
static SDL_TextureID sprites_field[1];
static SDL_bool cycle_color;
static SDL_bool cycle_alpha;
static int cycle_direction = 1;
static int current_alpha = 0;
(Continue reading)

Permalink | Reply | 0 comments |
headers
realstudent | 1 Feb 2007 13:40
Picon
Favicon

SDL 1.3 draw in windows on diff display, but need help

Hello! Sorry for bad english. My post "Control nultiple window om different 
display" stay withou answers, but i solve problems. Now I have example 
(corrected testsprite2.c) - his draw in different windows (each on the own 
display). But i have massive memory leaks (approbed in valgrind)! Please view 
my example and help if error in the source. Leaks appears in GL_LockTexture 
(SDL_renderer_gl.c:666) - i found what a function GL_UnlockTexture - 
unimplemented (have a void body), i kill allocated textures 
SDL_DestroyTexture() - but this not solve problem! Please help.

/* Simple program:  Move N sprites around on the screen as fast as possible */

#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <string.h>

#include "common.h"

#define NUM_SPRITES	100
static SDL_TextureBlendMode blendMode = SDL_TEXTUREBLENDMODE_MASK;
static SDL_TextureScaleMode scaleMode = SDL_TEXTURESCALEMODE_NONE;
static int num_sprites;

static CommonState *state;
static SDL_TextureID sprites_displ0[260];
static SDL_TextureID sprites_field[1];
static SDL_bool cycle_color;
static SDL_bool cycle_alpha;
static int cycle_direction = 1;
static int current_alpha = 0;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andre Krause | 1 Feb 2007 20:25

SDL_VideoModeOK and SDL_SetVideoMode not consistently handling bits_per_pixel argument !

if i pass to SetVideoMode bpp=0, everything is fine and a surface is
created. ( "If bpp is 0, it is treated as the current display bits per
pixel.")

now im trying to resize the window and want to check if that window size
is ok, with SDL_VideoModeOK.

but if i pass bpp=0 to VideoModeOK, it returns 0 instead of the closest
supported bitdepth as stated in the docs:

"SDL_VideoModeOK returns 0 if the requested mode is not supported under
any bit depth, or returns the bits-per-pixel of the closest available
mode with the given width".

if i just ignore VideoModeOK and do the resize everything works fine.
but i think VideoModeOK  should return something nonzero if i actually
can create the new window size and surface.

videoflas i pass: videoFlags  = SDL_OPENGL | SDL_RESIZABLE;

code i use:

videoFlags=0;
bits_per_pixel=0; // use desktop default bitdepth
videoFlags  = SDL_OPENGL | SDL_RESIZABLE;
SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER, 1 );
surface = SDL_SetVideoMode( _w, _h, bits_per_pixel, videoFlags );

and in my handle events function:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jake Goerzen | 1 Feb 2007 21:28

dummy joystick driver

When I compile version version 1.2.9 on Solaris the dummy joystick 
driver is compiled in.  However, when I compile version 1.2.11 programs 
that link against SDL tell me that "SDL not built with joystick 
support".  Can someone help me understand why the newer version does not 
compile in the dummy driver?

Thanks, Jake
Permalink | Reply | 1 comment |
headers
Bill Kendrick | 1 Feb 2007 21:32
Favicon

Re: UNSUBSCRIBE FROM MAILING LIST

On Thu, Feb 01, 2007 at 07:45:02AM +0000, keithhards <at> supanet.com wrote:
> PLEASE UBNSUBSCRIBE ME FROM THE MAILING LIST.

*sigh*

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

You're welcome ;)

-bill!
Permalink | Reply | 1 comment |
headers
Christer Sandberg | 1 Feb 2007 22:05
Picon
Picon
Favicon

Re: The keyboard in SDL

On Wednesday 31 January 2007 21:52, Christian Walther wrote:
>Christer Sandberg wrote:
>> E.g. when pressing the key with the Swedish letter 'ö' (the key with
>> a ';' on a US keyboard mapping) the content of both sym and unicode
>> is 246 (which is a correct representation of 'ö' in ISO-8859
>> encoding). The actual unicode value of 'ö' is however a two byte
>> number (in UTF-8).
>
>The unicode field contains the Unicode code point of the generated
>character (which is a number), not its UTF-8 encoded form (which is a
>sequence of bytes). The code point of 'ö' is indeed 246. In fact code
>points 0 to 255 of Unicode coincide with ISO-Latin-1, so to test whether
>SDL really produces Unicode and not Latin-1 values, you need to use
>characters that are not in Latin-1.
Thanks for your answer. I wasn't aware there existed a "code point" 
representaition (however, the SDL docs does not mention the "code point"). 
I have have spent some time trying to understand what relation there are 
between a unicode encoding like UTF-8 and "code point", but I have had little 
or no success. So I'm asking for someone to make a miracle.
From Wikipedia:
"In text processing, Unicode takes the role of providing a unique code point — 
a number, not a glyph — for each character. In other words, Unicode 
represents a character in an abstract way and leaves the visual rendering 
(size, shape, font or style) to other software, such as a web browser or word 
processor."
But as far as I know this description matches also UTF-8, or? And on 
www.unicode.org there essentially the same text:
"Characters are represented by code points that reside only in a memory 
representation, as strings in memory, or on disk. The Unicode Standard deals 
only with character codes. Glyphs represent the shapes that characters can
(Continue reading)

Permalink | Reply | 6 comments |
headers
Torsten Giebl | 2 Feb 2007 02:18

Re: UNSUBSCRIBE FROM MAILING LIST

Hello !

>> PLEASE UBNSUBSCRIBE ME FROM THE MAILING LIST.
>>
>
> *sigh*
>
>
>> SDL mailing list
>> SDL <at> lists.libsdl.org
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I think Mailman makes it as easy as
possible to subscribe / unsubscribe
to a Mailinglist. Majordomo is a lot harder
to use.

CU
Permalink | Reply | 0 comments |
headers
Ryan C. Gordon | 2 Feb 2007 02:25
Favicon
Gravatar

Re: dummy joystick driver


> When I compile version version 1.2.9 on Solaris the dummy joystick 
> driver is compiled in.  However, when I compile version 1.2.11 programs 
> that link against SDL tell me that "SDL not built with joystick 
> support".  Can someone help me understand why the newer version does not 
> compile in the dummy driver?

We fixed this in Subversion, but it's not in an official release yet:

http://www.libsdl.org/cgi/viewvc.cgi/branches/SDL-1.2/configure.in?r1=2788&r2=2898

--ryan.
Permalink | Reply | 0 comments |
headers
=?UTF-8?Q? Kuon_-_Nicolas_Goy_-_=E6=99=82=E6=9C=9F=E7=B2=BE?= =?UTF-8?Q?=E9=9C=8A_=28Goyman.com_SA=29 ?= | 2 Feb 2007 10:10
Favicon

Re: The keyboard in SDL


On Feb 1, 2007, at 10:05 PM, Christer Sandberg wrote:

>

You should not confuse Unicode and UTF-8.

Unicode is NOT an encoding, it's a standard CHARACTER SET.

The encoding are, UTF-8, UTF-16 (little and big endian) and UTF-32  
(same thing as 16 for endian).

In SDL, the unicode value is UCS4. (I think so, not 100% sure about  
sdl, it's quite strange because UCS4 is 32 bit, and sdl return a  
16bit value, but I think it's UCS4 but they just drop the value if  
it's bigger than 65535. Sam, Ryan?)

Let me explain a bit:

UTF-32 is the UCS4 value encoded on 32 bit, simply a number, stored  
in little or big endian.

For example (I took a rare kanji because it has a huge value:) )

0x2F9F4 is the UCS4 value, and can be encoding as is on 32 bit.

Now, how can I encode this on 16 or 8 bit? It's impossible!
The answer is, surrogates. This barbaric words means a "prefix" to be  
used to inform the parser that our char is encoded on two unit. (a  
unit is 16 or 8 bit depending of the encoding, can be up to 4 units
(Continue reading)

Permalink | Reply | 5 comments |

Gmane