SDL 1.3 and video overlays

Hello, All!

I think we must return video overlays support back to SDL 1.3, because they
could significally improve conversion quality, filtering, speed of YUV->RGB
conversion and scaling. Right now YUV->RGB conversion could be supported
only as texture blitting, but most drivers has software fallbacks only for
this conversion. Also I think we need to add not YUV overlays only, but RGB
overlays too. RGB overlays are good for emulators, when you need to emulate
screen like 256x192 and then stretch it to any size.

Maybe new overlay support code must be without software fallbacks, only
hardware implementation, if current video driver supports overlays. Overlay
formats and restrictions must be obtained through the SDL API, and
application will decide which YUV or RGB overlay type it will use.

Any opinions on this ? (Is this a good task for Google Summer of Code ?)

With best regards, Mike Gorchak. E-mail: @Mike_Gorchak

Hi everybody!!!
I have one doubt about little endian and big endian issue.
I want to develop one game for windows, linux and MacOS, can I use the int,
bool, char and String literals normally? Or I have to create new classes
that simulate this literals?
Thanks for all,
FRAN

__________ Informacion de ESET NOD32 Antivirus, version de la base de firmas
de virus 3983 (20090402) __________

ESET NOD32 Antivirus ha comprobado este mensaje.

Hi everybody!!!
I have one doubt about little endian and big endian issue.
I want to develop one game for windows, linux and MacOS, can I use
the int,
bool, char and String literals normally? Or I have to create new
classes
that simulate this literals?
Thanks for all,
FRAN

Depends what you are doing. For all normal operations, you should not
see a difference.

When you are manipulation/accessing the raw data behind, e.g.:

Uint32 color = SDL_MapColor(//);
uchar *px = surface->pixels;

memcpy(px, (uchar*)&color, surface->format->BytesPerPixel);

That won’t work.

Also fwrite/fread will not work directly. Best is to code some small
wrappers around those.Am 07.04.2009 um 15:28 schrieb Francisco Bodego Franco:

Actually big endian and little endian is not an OS feature, but a processor
architeture one (I’m not completely sure about this, somebody know any OS
that control the endianess?). That means you don’t need to be aware of
endianess, but you must be aware of data sizes (OSes can have control about
this, it might change from one to the next).

Like Albert said, if you are doing normal operations on the variables you’re
using (like a = b, a and b being int), you should’nt have problems, but if
you are working on the raw data, never assume the size of anything you
have’nt made yourself.

Making wrappers around those types you have’nt made usually is a good idea,
or using some sizeof operator…

2009/4/7 Albert Zeyer <albert.zeyer at rwth-aachen.de>>

Am 07.04.2009 um 15:28 schrieb Francisco Bodego Franco:

Hi everybody!!!

I have one doubt about little endian and big endian issue.
I want to develop one game for windows, linux and MacOS, can I use the
int,
bool, char and String literals normally? Or I have to create new classes
that simulate this literals?
Thanks for all,
FRAN

Depends what you are doing. For all normal operations, you should not see a
difference.

When you are manipulation/accessing the raw data behind, e.g.:

Uint32 color = SDL_MapColor(//);
uchar *px = surface->pixels;

memcpy(px, (uchar*)&color, surface->format->BytesPerPixel);

That won’t work.

Also fwrite/fread will not work directly. Best is to code some small
wrappers around those.


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

Endian issues really only come into play when sharing data between
such systems, such as files or through a network. In such cases, one
of the endian formats is chosen arbitrarily (for example, big endian
is typically used over a network) and the application must be written
to perform the endian conversions. In C (and probably available from
other languages) there are routines such as htonl and ntohl (“host to
network long” and “network to host long” respectively) that make it
easier to do this.

Another important note is that type sizes can vary between different
machines. So you should also decide how many bits are used to
represent data in a file format or in a network protocol.On Tue, Apr 7, 2009 at 2:28 PM, Francisco Bodego Franco wrote:

Hi everybody!!!
I have one doubt about little endian and big endian issue.
I want to develop one game for windows, linux and MacOS, can I use the int,
bool, char and String literals normally? Or I have to create new classes
that simulate this literals?
Thanks for all,
FRAN


Actually big endian and little endian is not an OS feature, but a
processor architeture one (I’m not completely sure about this,
somebody know any OS that control the endianess?).

Yes, it’s a processor thing. And there’s really no good reason
for the OS to try to control it manually, unless you’re emulating.
a different CPU. (Which isn’t an OS function anyway.) It’s a
whole lot easier to work with your CPU than to try to fight it.>From: Leonardo Guilherme <leonardo.guilherme at gmail.com>

Subject: Re: [SDL] little endian and big endian

Can you give one example of wrapper around types or use a sizeof operator?

I don’t understand very well. my program will access external data like
images, audio and xml files.De: sdl-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] En
nombre de Leonardo Guilherme
Enviado el: martes, 07 de abril de 2009 15:45
Para: A list for developers using the SDL library. (includes SDL-announce)
Asunto: Re: [SDL] little endian and big endian

Actually big endian and little endian is not an OS feature, but a processor
architeture one (I’m not completely sure about this, somebody know any OS
that control the endianess?). That means you don’t need to be aware of
endianess, but you must be aware of data sizes (OSes can have control about
this, it might change from one to the next).

Like Albert said, if you are doing normal operations on the variables you’re
using (like a = b, a and b being int), you should’nt have problems, but if
you are working on the raw data, never assume the size of anything you
have’nt made yourself.

Making wrappers around those types you have’nt made usually is a good idea,
or using some sizeof operator…

2009/4/7 Albert Zeyer <albert.zeyer at rwth-aachen.de>

Am 07.04.2009 um 15:28 schrieb Francisco Bodego Franco:

Hi everybody!!!
I have one doubt about little endian and big endian issue.
I want to develop one game for windows, linux and MacOS, can I use the int,
bool, char and String literals normally? Or I have to create new classes
that simulate this literals?
Thanks for all,
FRAN

Depends what you are doing. For all normal operations, you should not see a
difference.

When you are manipulation/accessing the raw data behind, e.g.:

Uint32 color = SDL_MapColor(//);
uchar *px = surface->pixels;

memcpy(px, (uchar*)&color, surface->format->BytesPerPixel);

That won’t work.

Also fwrite/fread will not work directly. Best is to code some small
wrappers around those.


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

Francisco Bodego Franco wrote:

Can you give one example of wrapper around types or use a sizeof operator?

I thought most of what people needed for 32-bit data models is
already in SDL_endian.h, dunno about SDL 1.3 though.

Also note the different 64-bit data models that we have nowadays,
important if your 32-bit code is to be 64-bit clean. Linux and
*nix use LP64 while Win64 uses LLP64. (See
64-bit computing - Wikipedia)> De: sdl-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org]

*En nombre de *Leonardo Guilherme
Enviado el: martes, 07 de abril de 2009 15:45
Para: A list for developers using the SDL library. (includes SDL-announce)
Asunto: Re: [SDL] little endian and big endian

Actually big endian and little endian is not an OS feature, but a
processor architeture one (I’m not completely sure about this, somebody
know any OS that control the endianess?). That means you don’t need to
be aware of endianess, but you must be aware of data sizes (OSes can
have control about this, it might change from one to the next).
[snip snip snip]


Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

You don’t have to care about loading of images, audio and XML files if
that is not part of your code (i.e. you use IMG_Load from SDL or other
external functions).

For example, we have some own map format for our game which is saved
in a binary format. Also, we have network multiplayer support in our
game and we are using some binary protocol. In such cases, you have to
care about it.

See here for some examples:

OpenLieroX download | SourceForge.net 07.04.2009 um 15:58 schrieb Francisco Bodego Franco:

Can you give one example of wrapper around types or use a sizeof
operator?

I don?t understand very well? my program will access external data
like images, audio and xml files.

De: sdl-bounces at lists.libsdl.org [mailto:sdl-
bounces at lists.libsdl.org] En nombre de Leonardo Guilherme
Enviado el: martes, 07 de abril de 2009 15:45
Para: A list for developers using the SDL library. (includes SDL-
announce)
Asunto: Re: [SDL] little endian and big endian

Actually big endian and little endian is not an OS feature, but a
processor architeture one (I’m not completely sure about this,
somebody know any OS that control the endianess?). That means you
don’t need to be aware of endianess, but you must be aware of data
sizes (OSes can have control about this, it might change from one to
the next).

Like Albert said, if you are doing normal operations on the
variables you’re using (like a = b, a and b being int), you
should’nt have problems, but if you are working on the raw data,
never assume the size of anything you have’nt made yourself.

Making wrappers around those types you have’nt made usually is a
good idea, or using some sizeof operator…

2009/4/7 Albert Zeyer <@Albert_Zeyer>

Am 07.04.2009 um 15:28 schrieb Francisco Bodego Franco:

Hi everybody!!!
I have one doubt about little endian and big endian issue.
I want to develop one game for windows, linux and MacOS, can I use
the int,
bool, char and String literals normally? Or I have to create new
classes
that simulate this literals?
Thanks for all,
FRAN

Depends what you are doing. For all normal operations, you should
not see a difference.

When you are manipulation/accessing the raw data behind, e.g.:

Uint32 color = SDL_MapColor(//);
uchar *px = surface->pixels;

memcpy(px, (uchar*)&color, surface->format->BytesPerPixel);

That won’t work.

Also fwrite/fread will not work directly. Best is to code some small
wrappers around those.


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

__________ Informaci?n de ESET NOD32 Antivirus, versi?n de la base
de firmas de virus 3983 (20090402) __________

ESET NOD32 Antivirus ha comprobado este mensaje.

http://www.eset.com


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

I have one doubt about little endian and big endian issue.
I want to develop one game for windows, linux and MacOS, can I use the int,
bool, char and String literals normally? Or I have to create new classes
that simulate this literals?

You mainly have to be careful while doing I/O or manipulating integers
in strange ways (for example, trying to access the two bytes in an
integer separately, you might find they are inverted). If you’re just
doing things normally, as others pointed out, you’ll be fine.

One thing that I got caught by is that you don’t always think of all
the I/O. While reading/writing files and network communications are
obvious, I once found out the hard way that the sound card on a
Powerbook actually takes little endian samples, even though the
PowerPC CPU in that laptop is big endian!

For reading and writing to files, you can borrow the trick often used
by network communication, which is to standardize on one endianness,
and have some functions used while doing the I/O (checking “at the
borders” of your program, so to speak), using the hton/ntoh family of
macros, for example (“hton” means “host to network”, meaning that it
converts from whatever your host system uses to the “network byte
order”, so if you get a 32 bit integer from the network, you don’t
need to think much about it, just run it through ntohl, and you’ll now
have whatever you need for your system).

Strings don’t tend to be a problem, since (most commonly) they are
just a sequence of discrete single-byte data, so there’s no byte
ordering issue. If you use UTF-16 for your string encoding, that might
not be the case, tough.

The hton/ntoh macros are an example of the “wrappers” mentioned by others.

The mention of sizeof is related to the fact that on some platforms,
an “int” might not be the same size as on another (“long” is a common
offender, where it can be 32 or 64 bits long, depending on the
platform). Again, for I/O, in those cases, you’d want to use something
like the fixed-size integer types from stdint.h, so that when you use
an int32_t, you know that it’ll be exactly 4 bytes long, no matter
what platform you’re on, for example.

That said, if you use libraries for doing your I/O, like SDL_image to
load images, say, the library should handle those byte ordering
details for you, most of the time. I experienced the problem on my
Powerbook mainly because I was coding my own sound mixer, which had to
manipulate each samples, but if you use a library like SDL_mixer, it
will deal with it for you. The main problems remaining are usually
file formats (but if you use XML, it’s all strings, and your XML
library should work around any problem for you) and network
communication (just use the hton/ntoh functions all the time).

I did see some people using C++ who created special types for “network
integers”, and had overloaded a number of operators so that they would
automatically convert (using hton/ntoh), but I think that’s probably
more trouble than it’s worth, the code that interacts over the network
is usually grouped together, making it easy to deal with “by hand”.On Tue, Apr 7, 2009 at 9:28 AM, Francisco Bodego Franco wrote:

So, the problem with endians will only appear if I use fread or fwrite
functions to create a new file, for example?-----Mensaje original-----
De: sdl-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] En
nombre de Albert Zeyer
Enviado el: martes, 07 de abril de 2009 16:14
Para: A list for developers using the SDL library. (includes SDL-announce)
Asunto: Re: [SDL] little endian and big endian

You don’t have to care about loading of images, audio and XML files if
that is not part of your code (i.e. you use IMG_Load from SDL or other
external functions).

For example, we have some own map format for our game which is saved
in a binary format. Also, we have network multiplayer support in our
game and we are using some binary protocol. In such cases, you have to
care about it.

See here for some examples:

?view=markup

am.cpp?view=markup

Am 07.04.2009 um 15:58 schrieb Francisco Bodego Franco:

Can you give one example of wrapper around types or use a sizeof
operator?

I don?t understand very well
my program will access external data
like images, audio and xml files.

De: sdl-bounces at lists.libsdl.org [mailto:sdl-
bounces at lists.libsdl.org] En nombre de Leonardo Guilherme
Enviado el: martes, 07 de abril de 2009 15:45
Para: A list for developers using the SDL library. (includes SDL-
announce)
Asunto: Re: [SDL] little endian and big endian

Actually big endian and little endian is not an OS feature, but a
processor architeture one (I’m not completely sure about this,
somebody know any OS that control the endianess?). That means you
don’t need to be aware of endianess, but you must be aware of data
sizes (OSes can have control about this, it might change from one to
the next).

Like Albert said, if you are doing normal operations on the
variables you’re using (like a = b, a and b being int), you
should’nt have problems, but if you are working on the raw data,
never assume the size of anything you have’nt made yourself.

Making wrappers around those types you have’nt made usually is a
good idea, or using some sizeof operator…

2009/4/7 Albert Zeyer <albert.zeyer at rwth-aachen.de>

Am 07.04.2009 um 15:28 schrieb Francisco Bodego Franco:

Hi everybody!!!
I have one doubt about little endian and big endian issue.
I want to develop one game for windows, linux and MacOS, can I use
the int,
bool, char and String literals normally? Or I have to create new
classes
that simulate this literals?
Thanks for all,
FRAN

Depends what you are doing. For all normal operations, you should
not see a difference.

When you are manipulation/accessing the raw data behind, e.g.:

Uint32 color = SDL_MapColor(//);
uchar *px = surface->pixels;

memcpy(px, (uchar*)&color, surface->format->BytesPerPixel);

That won’t work.

Also fwrite/fread will not work directly. Best is to code some small
wrappers around those.


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

__________ Informaci?n de ESET NOD32 Antivirus, versi?n de la base
de firmas de virus 3983 (20090402) __________

ESET NOD32 Antivirus ha comprobado este mensaje.

http://www.eset.com


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

__________ Informaci?n de ESET NOD32 Antivirus, versi?n de la base de firmas
de virus 3983 (20090402) __________

ESET NOD32 Antivirus ha comprobado este mensaje.

http://www.eset.com

__________ Informaci?n de ESET NOD32 Antivirus, versi?n de la base de firmas
de virus 3983 (20090402) __________

ESET NOD32 Antivirus ha comprobado este mensaje.

http://www.eset.com

A general thumb: Whereever you access a pointer to some integer type,
you have to care about it.

Btw., there are also emulators for PowerPC or SPARC (common big endian
CPUs), e.g. QEMU. There are even ready-to-use images to download with
Linux for PowerPC or SPARC for QEMU. These emulators are slow of
course but they could be usefull though to just try it out.

If you see weird colors or have other problems with your application
in the emulator, you have made a mistake.Am 07.04.2009 um 16:24 schrieb Francisco Bodego Franco:

So, the problem with endians will only appear if I use fread or fwrite
functions to create a new file, for example?

-----Mensaje original-----
De: sdl-bounces at lists.libsdl.org [mailto:sdl-
bounces at lists.libsdl.org] En
nombre de Albert Zeyer
Enviado el: martes, 07 de abril de 2009 16:14
Para: A list for developers using the SDL library. (includes SDL-
announce)
Asunto: Re: [SDL] little endian and big endian

You don’t have to care about loading of images, audio and XML files if
that is not part of your code (i.e. you use IMG_Load from SDL or other
external functions).

For example, we have some own map format for our game which is saved
in a binary format. Also, we have network multiplayer support in our
game and we are using some binary protocol. In such cases, you have to
care about it.

See here for some examples:
OpenLieroX download | SourceForge.net
?view=markup
OpenLieroX download | SourceForge.net
am.cpp?view=markup

Am 07.04.2009 um 15:58 schrieb Francisco Bodego Franco:

Can you give one example of wrapper around types or use a sizeof
operator?

I don?t understand very well? my program will access external data
like images, audio and xml files.

De: sdl-bounces at lists.libsdl.org [mailto:sdl-
bounces at lists.libsdl.org] En nombre de Leonardo Guilherme
Enviado el: martes, 07 de abril de 2009 15:45
Para: A list for developers using the SDL library. (includes SDL-
announce)
Asunto: Re: [SDL] little endian and big endian

Actually big endian and little endian is not an OS feature, but a
processor architeture one (I’m not completely sure about this,
somebody know any OS that control the endianess?). That means you
don’t need to be aware of endianess, but you must be aware of data
sizes (OSes can have control about this, it might change from one to
the next).

Like Albert said, if you are doing normal operations on the
variables you’re using (like a = b, a and b being int), you
should’nt have problems, but if you are working on the raw data,
never assume the size of anything you have’nt made yourself.

Making wrappers around those types you have’nt made usually is a
good idea, or using some sizeof operator…

2009/4/7 Albert Zeyer <@Albert_Zeyer>

Am 07.04.2009 um 15:28 schrieb Francisco Bodego Franco:

Hi everybody!!!
I have one doubt about little endian and big endian issue.
I want to develop one game for windows, linux and MacOS, can I use
the int,
bool, char and String literals normally? Or I have to create new
classes
that simulate this literals?
Thanks for all,
FRAN

Depends what you are doing. For all normal operations, you should
not see a difference.

When you are manipulation/accessing the raw data behind, e.g.:

Uint32 color = SDL_MapColor(//);
uchar *px = surface->pixels;

memcpy(px, (uchar*)&color, surface->format->BytesPerPixel);

That won’t work.

Also fwrite/fread will not work directly. Best is to code some small
wrappers around those.


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

__________ Informaci?n de ESET NOD32 Antivirus, versi?n de la base
de firmas de virus 3983 (20090402) __________

ESET NOD32 Antivirus ha comprobado este mensaje.

http://www.eset.com


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

__________ Informaci?n de ESET NOD32 Antivirus, versi?n de la base
de firmas
de virus 3983 (20090402) __________

ESET NOD32 Antivirus ha comprobado este mensaje.

http://www.eset.com

__________ Informaci?n de ESET NOD32 Antivirus, versi?n de la base
de firmas
de virus 3983 (20090402) __________

ESET NOD32 Antivirus ha comprobado este mensaje.

http://www.eset.com


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

So, the problem with endians will only appear if I use fread or fwrite
functions to create a new file, for example?

Well, not only, but fread/fwrite of binary data will have problems.
For example:

long foo = 42;
fwrite(&foo, sizeof(foo), 1, myfile);

This has (at least) two problems. First, even though we use sizeof,
the return value of “sizeof(foo)” will vary from platform to platform.
You’d want to use an int32_t or an int64_t instead of long to fix that
problem. The other problem is that if you write this file on a big
endian machine and read it on a little endian machine, it will be
incorrect.

What you want is something like this:

int32_t foo = 42;
int32_t network_foo = htonl(foo); // doesn’t have to be in a separate
line, but imagine foo comes from a parameter…
fwrite(&network_foo, sizeof(foo), 1, myfile);

Here, sizeof(foo) will always be 4, and we can read this like this:

int32_t network_foo;
fread(&network_foo, sizeof(network_foo), 1, myfile);
int32_t foo = ntohl(network_foo);

Albert’s rule of thumb is pretty good, actually.On Tue, Apr 7, 2009 at 10:24 AM, Francisco Bodego Franco wrote:

What you want is something like this:

int32_t foo = 42;
int32_t network_foo = htonl(foo); // doesn’t have to be in a separate
line, but imagine foo comes from a parameter…
fwrite(&network_foo, sizeof(foo), 1, myfile);

Or, since we’re on the SDL list:

SDL_WriteBE32(myfile_rwops, 42);

GregoryOn Tue, 7 Apr 2009, Pierre Phaneuf wrote:

Or, since we’re on the SDL list:

SDL_WriteBE32(myfile_rwops, 42);

Ah, yes, I figured after hitting send maybe I should have pointed to
the SDL equivalents of hton/ntoh, and I didn’t know about the rwops
ones (don’t use rwops), thanks!On Tue, Apr 7, 2009 at 11:37 AM, Gregory Smith wrote: