Nabble - SDL

Re: SFML - What SDL 1.3 hopefully will be...

2009-12-21T10:08:28Z

SDL 1.3 should already have OpenGL and (on Windows only, ofc) Direct3D hardware accelerated renderers. It also has scaling functions, but not rotation ones.

There were libraries for SDL 1.2 that were easy enough to use that provided OpenGL acceleration, too.

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

My simple computer shutting program in C language...

2009-12-21T05:49:03Z

Hi guys!, here is my new simple program... I hope it will be helpful for you... Honestly, it helps me so much:)
but there are some bugs in my program, i cant solve them... for example: how can i disable arrow keys like letters???
because if you use an arrow key, it disables the whole warnings and warnings are very important...
here is the link, check it if you want:

http://www.MegaShare.com/1694062

have good day:)

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

Re: SDL 1.3 docs?

2009-12-20T20:18:49Z

The source would be great, if possible. Go ahead and send me private
e-mail, if you want.

On Sun, Dec 20, 2009 at 10:32 AM, Ken Rogoway <Ken@...> wrote:

> It's large due to the assets, so I will send you access to my FTP. Do you
> just want the Bin, or do you need the source too?
>
> -----Original Message-----
> From: sdl-bounces@... [mailto:sdl-bounces@...] On
> Behalf Of Sam Lantinga
> Sent: Sunday, December 20, 2009 11:13 AM
> To: SDL Development List
> Subject: Re: [SDL] SDL 1.3 docs?
>
> Can you send me a link to your program so I can try it out here?
>
> On Sun, Dec 20, 2009 at 9:11 AM, Ken Rogoway <Ken@...>
> wrote:
>> After I sent the post I saw the sample apps. Better than nothing, but
> still
>> not ideal for a migration since you can never tell in a sample what is
>> particular to that program, and what is required for a minimum
>> implementation. I will keep notes of the migration from 1.2 to 1.3 and
> get
>> in touch with Lauren.
>>
>> As for the slow down:
>>
>> I am running on Windows XP.
>>
>> The program is running in a 800x600x24 software window. My physical
> screen
>> is 1920x1200x32.
>>
>> I convert all images at load time to match the display format. I use
>> SDL_Flip() to update the screen, which according to the docs is the
>> equivalent of calling SDL_UpdateRect().
>>
>> I am not using dirty rects for this game since I need to redraw
> everything.
>>
>> The concern is that just by rebuilding with SDL 1.3 (no code changes) the
>> framerate drops 50%. Let me know if there is anything you want me to
>> try/test to see if I can get the performance up.
>>
>> Ken
>>
>> -----Original Message-----
>> From: sdl-bounces@... [mailto:sdl-bounces@...]
> On
>> Behalf Of Sam Lantinga
>> Sent: Sunday, December 20, 2009 10:30 AM
>> To: SDL Development List
>> Subject: Re: [SDL] SDL 1.3 docs?
>>
>> There isn't an official 1.3 migration guide, although it's high on the
>> priority list. We're going to put a list of new functions and a
>> migration guide on the wiki here:
>> http://wiki.libsdl.org/moin.cgi/NewInSDL1.3
>>
>> In the meantime, the best way to get comfortable with the new API
>> functions is to take a look at the testsprite2 and testdraw2 test
>> programs.
>>
>> If you'd like to put together some initial notes for people migrating
>> to SDL 1.3, feel free to start a page on the wiki, coordinating it
>> with Lauren <laleh_aziz@...>
>>
>> As for the slowdown, I've tried to keep the SDL 1.3 implementation as
>> close to the 1.2 code path as possible. Judging by the 50% slowdown,
>> it sounds like there's an extra buffer copy going on there. What
>> platform are you running?
>>
>> See ya!
>>
>>
>> _______________________________________________
>> SDL mailing list
>> SDL@...
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
>
>
>
> --
> -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
> _______________________________________________
> SDL mailing list
> SDL@...
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
> _______________________________________________
> SDL mailing list
> SDL@...
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>

--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: disable ugly windows shortkeys

2009-12-20T17:32:11Z

mandarx wrote:

Can SDL disable ugly windows shortkeys and filters?

I can't give you an authoritative answer, but I'm pretty sure the answer is 'no'. Also, I think the general consensus is that OS-specific shortcuts (such as alt-tab in Windows and cmd-tab in OS X) shouldn't be disabled under normal circumstances. (There's certainly some disagreement about this though.)

Quote:

are GNU+Linux and MacOsX affected by the same problem??

I wouldn't go so far as to call it a 'problem' per se, but yeah, in OS X the OS keyboard shortcuts are still operational (in windowed mode at least) when an SDL-based app has focus. Not sure about Linux.

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

SDL 1.3 Mac fullscreen

2009-12-20T14:21:28Z

Hi,

I've written a very simple test program with a ball bouncing.

I used the same technic as in the 'testspriteminial' test.
(No VideoInit() call, no Renderer created).

Although 'testspriteminimal' works fine in fullscreen mode, mine

produces strange tearing, and more the video seems almost corrupted

whereas it is perfectly OK in window mode. I tried creating a renderer

and many different options without success (ex: SDL_RENDERER_SINGLEBUFFER).

Another note, 'testsprite2' produces the same corrupted video in fullscreen mode.

By the way, I don't see a significant speed up comparing with the SDL 1.2 test sprite.

I checked the name of the default renderer and it is "opengl".

Thanks,

Julien

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

Re: SDL 1.3 docs?

2009-12-20T10:32:25Z

It's large due to the assets, so I will send you access to my FTP. Do you
just want the Bin, or do you need the source too?

-----Original Message-----
From: sdl-bounces@... [mailto:sdl-bounces@...] On
Behalf Of Sam Lantinga
Sent: Sunday, December 20, 2009 11:13 AM
To: SDL Development List
Subject: Re: [SDL] SDL 1.3 docs?

Can you send me a link to your program so I can try it out here?

On Sun, Dec 20, 2009 at 9:11 AM, Ken Rogoway <Ken@...>
wrote:
> After I sent the post I saw the sample apps. Better than nothing, but
still
> not ideal for a migration since you can never tell in a sample what is
> particular to that program, and what is required for a minimum
> implementation. I will keep notes of the migration from 1.2 to 1.3 and
get
> in touch with Lauren.
>
> As for the slow down:
>
> I am running on Windows XP.
>
> The program is running in a 800x600x24 software window. My physical
screen
> is 1920x1200x32.
>
> I convert all images at load time to match the display format. I use
> SDL_Flip() to update the screen, which according to the docs is the
> equivalent of calling SDL_UpdateRect().
>
> I am not using dirty rects for this game since I need to redraw
everything.
>
> The concern is that just by rebuilding with SDL 1.3 (no code changes) the
> framerate drops 50%. Let me know if there is anything you want me to
> try/test to see if I can get the performance up.
>
> Ken
>
> -----Original Message-----
> From: sdl-bounces@... [mailto:sdl-bounces@...]
On

> Behalf Of Sam Lantinga
> Sent: Sunday, December 20, 2009 10:30 AM
> To: SDL Development List
> Subject: Re: [SDL] SDL 1.3 docs?
>
> There isn't an official 1.3 migration guide, although it's high on the
> priority list. We're going to put a list of new functions and a
> migration guide on the wiki here:
> http://wiki.libsdl.org/moin.cgi/NewInSDL1.3
>
> In the meantime, the best way to get comfortable with the new API
> functions is to take a look at the testsprite2 and testdraw2 test
> programs.
>
> If you'd like to put together some initial notes for people migrating
> to SDL 1.3, feel free to start a page on the wiki, coordinating it
> with Lauren <laleh_aziz@...>
>
> As for the slowdown, I've tried to keep the SDL 1.3 implementation as
> close to the 1.2 code path as possible. Judging by the 50% slowdown,
> it sounds like there's an extra buffer copy going on there. What
> platform are you running?
>
> See ya!
>
>
> _______________________________________________
> SDL mailing list
> SDL@...
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>

--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

Re: SDL 1.3 docs?

2009-12-20T09:15:06Z

Oh, there's a great test to show the minimum you need to get up and
running! Try out testspriteminimal in the test directory. As you can
see it's super easy. :)

On Sun, Dec 20, 2009 at 9:11 AM, Ken Rogoway <Ken@...> wrote:

> After I sent the post I saw the sample apps. Better than nothing, but still
> not ideal for a migration since you can never tell in a sample what is
> particular to that program, and what is required for a minimum
> implementation. I will keep notes of the migration from 1.2 to 1.3 and get
> in touch with Lauren.
>
> As for the slow down:
>
> I am running on Windows XP.
>
> The program is running in a 800x600x24 software window. My physical screen
> is 1920x1200x32.
>
> I convert all images at load time to match the display format. I use
> SDL_Flip() to update the screen, which according to the docs is the
> equivalent of calling SDL_UpdateRect().
>
> I am not using dirty rects for this game since I need to redraw everything.
>
> The concern is that just by rebuilding with SDL 1.3 (no code changes) the
> framerate drops 50%. Let me know if there is anything you want me to
> try/test to see if I can get the performance up.
>
> Ken
>
> -----Original Message-----
> From: sdl-bounces@... [mailto:sdl-bounces@...] On
> Behalf Of Sam Lantinga
> Sent: Sunday, December 20, 2009 10:30 AM
> To: SDL Development List
> Subject: Re: [SDL] SDL 1.3 docs?
>
> There isn't an official 1.3 migration guide, although it's high on the
> priority list. We're going to put a list of new functions and a
> migration guide on the wiki here:
> http://wiki.libsdl.org/moin.cgi/NewInSDL1.3
>
> In the meantime, the best way to get comfortable with the new API
> functions is to take a look at the testsprite2 and testdraw2 test
> programs.
>
> If you'd like to put together some initial notes for people migrating
> to SDL 1.3, feel free to start a page on the wiki, coordinating it
> with Lauren <laleh_aziz@...>
>
> As for the slowdown, I've tried to keep the SDL 1.3 implementation as
> close to the 1.2 code path as possible. Judging by the 50% slowdown,
> it sounds like there's an extra buffer copy going on there. What
> platform are you running?
>
> See ya!
>
>
> _______________________________________________
> SDL mailing list
> SDL@...
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>

--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: SDL 1.3 docs?

2009-12-20T09:13:02Z

Can you send me a link to your program so I can try it out here?

On Sun, Dec 20, 2009 at 9:11 AM, Ken Rogoway <Ken@...> wrote:

--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: SDL 1.3 docs?

2009-12-20T09:11:04Z

After I sent the post I saw the sample apps. Better than nothing, but still
not ideal for a migration since you can never tell in a sample what is
particular to that program, and what is required for a minimum
implementation. I will keep notes of the migration from 1.2 to 1.3 and get
in touch with Lauren.

As for the slow down:

I am running on Windows XP.

The program is running in a 800x600x24 software window. My physical screen
is 1920x1200x32.

I convert all images at load time to match the display format. I use
SDL_Flip() to update the screen, which according to the docs is the
equivalent of calling SDL_UpdateRect().

I am not using dirty rects for this game since I need to redraw everything.

The concern is that just by rebuilding with SDL 1.3 (no code changes) the
framerate drops 50%. Let me know if there is anything you want me to
try/test to see if I can get the performance up.

Ken

-----Original Message-----
From: sdl-bounces@... [mailto:sdl-bounces@...] On
Behalf Of Sam Lantinga
Sent: Sunday, December 20, 2009 10:30 AM
To: SDL Development List
Subject: Re: [SDL] SDL 1.3 docs?

There isn't an official 1.3 migration guide, although it's high on the
priority list. We're going to put a list of new functions and a
migration guide on the wiki here:
http://wiki.libsdl.org/moin.cgi/NewInSDL1.3

In the meantime, the best way to get comfortable with the new API
functions is to take a look at the testsprite2 and testdraw2 test
programs.

If you'd like to put together some initial notes for people migrating
to SDL 1.3, feel free to start a page on the wiki, coordinating it
with Lauren <laleh_aziz@...>

As for the slowdown, I've tried to keep the SDL 1.3 implementation as
close to the 1.2 code path as possible. Judging by the 50% slowdown,
it sounds like there's an extra buffer copy going on there. What
platform are you running?

See ya!

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

Re: rival library?

2009-12-20T08:56:33Z

Sorry about that. Stopping right now.

On Sun, Dec 20, 2009 at 5:21 PM, Sam Lantinga <slouken@...> wrote:

Hey guys, this is a great discussion, but it's gotten big and off
topic. Please take it off list.

Thanks!

On Sun, Dec 20, 2009 at 8:17 AM, Johannes Kroll <j-kroll@...> wrote:
> On Sun, 20 Dec 2009 07:48:36 -0800
> Jeff Post <j_post@...> wrote:
>
>> On Sunday 20 December 2009 03:40, Johannes Kroll wrote:
>> >
>> > Unlike heap allocation, using data on the stack is automatically
>> > cache-friendly. It's perfectly possible to allocate data from the heap
>> > though. It's done all the time. I'm not familiar with QT, so I can't
>> > comment on whether using stack-allocated objects in QT causes security
>> > problems (how?).
>>
>> Stack (or buffer) overrun. The following copied from
>> http://weblogs.asp.net/gad/archive/2004/03/23/94996.aspx
>>
>> [...]
>
> Apparently Mason Wheeler was not talking about buffer overflows. He was
> talking about returning addresses of stack-allocated data (in QT).
> Besides, 1) if I understand him correctly, he would still allocate
> "value types" on the stack, making stack overflows still possible, 2)
> Buffer overflows on the heap can be just as dangerous, 3) ... like you
> said, learn to use the screwdriver, or don't use it ;)
> _______________________________________________
> SDL mailing list
> SDL@...
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>

--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

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

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

Re: rival library?

2009-12-20T08:43:49Z

>----- Original Message ----

>From: Sam Lantinga <slouken@...>
>Subject: Re: [SDL] rival library?
>
>Hey guys, this is a great discussion, but it's gotten big and off
>topic. Please take it off list.
>
>Thanks!

Ack! Sorry, I sent my last reply before I saw this request.

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

Re: rival library?

2009-12-20T08:40:43Z

>----- Original Message ----

>From: Johannes Kroll <j-kroll@...>
>Subject: Re: [SDL] rival library?
>> More safety problems than security problems, though there are points
>> where the two overlap. By passing (copies of) stack-allocated objects
>> outside the library to user code, which the user code was then able to
>> obtain references to. Hilarity ensues once the stack gets cleaned up
>> and objects that the object contains a reference to are deallocated
>> out from under the user.
>
>Errr... That's a typical newbie error, right? Compilers issue warnings
>for these types of errors.

Only when the compiler knows what's going on. See above, re:
passing them outside of the library.

>> No, of course not. See above, "stack allocation is wonderful for
>> value types." I'm suggesting that C++ should dump stack allocation
>> *for objects* altogether.
>
>So where exactly do you draw the line between "objects" and "value
>types"? Is a class containing only a few ints and no
>pointers/references to anything an object, or a "value type"?

That sounds like a value type to me, and a good candidate for putting
into a struct, though it depends on how many ints constitute "a few".
Anything significantly larger than sizeof(pointer) probably should be a
reference type anyway, for performance reasons.

>Still, I don't think the dumbness of a few programmers should dumb down
>the whole language. :-)

Neither do I, but you have to draw the line somewhere. I prefer to err on
the side of caution. These aren't issues for "a few dumb programmers".
They're very common C++ gotchas that everyone ends up getting tripped
up by, and has to learn and commit to memory, and even then can end up
forgetting, causing embarrassing and occasionally dangerous problems.
When it's that easy to get it wrong, that's a strong indication that the
underlying system is badly-designed. The correct solution isn't "bend
every single user's thought patterns away from what's intuitive into what
fits the system," it's "fix the system to make it more intuitive!"

>Let's not discuss performance issues of C-style vs Pascal-style
>strings :-) I don't think it makes a huge difference one way or the
>other.

Please don't take this the wrong way, but if you truly think that
having to run a linear scan to find the length of a string in O(n) time
instead of having it immediately available in O(1) time, and needing
to perform all string operations one byte at a time, with a conditional
test between each byte, instead of in the largest chunks the CPU can
use to transfer data, with the conditional test against a length value
that's known from the start and can be kept in a register that doesn't
have to have values loaded into it over and over, doesn't make a
significant difference, (especially on low-end CPUs like you're
talking about!) then yes, I probably shouldn't be discussing
performance issues with you.

>But the memory usage might. Making the length prefix
>variable-sized isn't really feasible since then you would have to
>compile all the code an app uses (including libraries) with the same
>prefix-size options. So you end up using 4-byte prefixes. So each
>string uses 3 bytes more memory than a C string would. This doesn't
>normally matter on desktops of course, but on microcontrollers and the
>like, it does matter.

What sort of microcontrollers are you referring to? These days, even
tiny embedded systems like cellphones have access to hundreds of
megabytes of RAM. An extra 3 bytes per string might have been
significant 10 years ago, but today?

>> But due to pointer aliasing, changing a string with multiple
>> references to it would cause trouble. So how do you fix that?
>
>If you change a string, it is changed, no matter how many references to
>it exist. This is just plain obvious. Everything else would be
>counter-intuitive, and wrong. Nothing to fix here.

Not necessarily. Yes, you need to copy a string when you make
changes to it, to avoid stomping aliased references, but how do you
know when is the right time to copy? If you pass a C string into a
function, you don't know if it's got one reference to it or a hundred,
so you end up needing to make a (possibly unnecessary) copy
if you're going to change it. This can be very expensive if it's a
large string, especially since C has to copy the string one byte at a
time with a conditional test between each byte.

By building reference counting into the language's string type,
you ensure that copying always takes place when it needs to, and
never when it doesn't. No chance of user error there. I'd have to
check to make sure, but I don't think the Delphi standard library
even *has* a strcopy() function, because it doesn't need one.

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

Re: SDL 1.3 docs?

2009-12-20T08:29:43Z

There isn't an official 1.3 migration guide, although it's high on the
priority list. We're going to put a list of new functions and a
migration guide on the wiki here:
http://wiki.libsdl.org/moin.cgi/NewInSDL1.3

In the meantime, the best way to get comfortable with the new API
functions is to take a look at the testsprite2 and testdraw2 test
programs.

If you'd like to put together some initial notes for people migrating
to SDL 1.3, feel free to start a page on the wiki, coordinating it
with Lauren <laleh_aziz@...>

As for the slowdown, I've tried to keep the SDL 1.3 implementation as
close to the 1.2 code path as possible. Judging by the 50% slowdown,
it sounds like there's an extra buffer copy going on there. What
platform are you running?

See ya!

On Sat, Dec 19, 2009 at 7:04 PM, Ken Rogoway <Ken@...> wrote:

> Has anyone built docs for SDL 1.3? In particular documentation regarding
> the use of textures instead of surfaces (the old API vs. the new API)?
>
> I built and ran my game using SDL 1.2.14 and got 29 FPS.
> I then build and ran it using SDL 1.3.0 using the Compatibility mode (old
> API) and got 15 FPS.
>
> It looks like it is time to switch over to the new Texture based API so I
> can get decent performance, but it looks like there isn't any documentation
> other than the headers. I thought I saw a post a while back that talked
> about the changes necessary to migrate 1.2.x to 1.3.x, but cannot find it in
> emails.
>
> I have built the docs using doxygen, and although all of the new functions
> are in the generated html, there really isn't a good example of migrating
> from 1.2.x to 1.3.x
>
> Can someone point me to a old post or doc somewhere that details this?
>
> Thanks,
>
> Ken Rogoway
>
> _______________________________________________
> SDL mailing list
> SDL@...
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>

--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: rival library?

2009-12-20T08:23:34Z

On Sun, 20 Dec 2009 08:21:34 -0800
Sam Lantinga <slouken@...> wrote:

> Hey guys, this is a great discussion, but it's gotten big and off
> topic. Please take it off list.
>
> Thanks!

You're right, sorry.
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: rival library?

2009-12-20T08:21:34Z

Hey guys, this is a great discussion, but it's gotten big and off
topic. Please take it off list.

Thanks!

On Sun, Dec 20, 2009 at 8:17 AM, Johannes Kroll <j-kroll@...> wrote:

> On Sun, 20 Dec 2009 07:48:36 -0800
> Jeff Post <j_post@...> wrote:
>
>> On Sunday 20 December 2009 03:40, Johannes Kroll wrote:
>> >
>> > Unlike heap allocation, using data on the stack is automatically
>> > cache-friendly. It's perfectly possible to allocate data from the heap
>> > though. It's done all the time. I'm not familiar with QT, so I can't
>> > comment on whether using stack-allocated objects in QT causes security
>> > problems (how?).
>>
>> Stack (or buffer) overrun. The following copied from
>> http://weblogs.asp.net/gad/archive/2004/03/23/94996.aspx
>>
>> [...]
>
> Apparently Mason Wheeler was not talking about buffer overflows. He was
> talking about returning addresses of stack-allocated data (in QT).
> Besides, 1) if I understand him correctly, he would still allocate
> "value types" on the stack, making stack overflows still possible, 2)
> Buffer overflows on the heap can be just as dangerous, 3) ... like you
> said, learn to use the screwdriver, or don't use it ;)
> _______________________________________________
> SDL mailing list
> SDL@...
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>

--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: rival library?

2009-12-20T08:17:35Z

On Sun, 20 Dec 2009 07:48:36 -0800
Jeff Post <j_post@...> wrote:

> On Sunday 20 December 2009 03:40, Johannes Kroll wrote:
> >
> > Unlike heap allocation, using data on the stack is automatically
> > cache-friendly. It's perfectly possible to allocate data from the heap
> > though. It's done all the time. I'm not familiar with QT, so I can't
> > comment on whether using stack-allocated objects in QT causes security
> > problems (how?).
>
> Stack (or buffer) overrun. The following copied from
> http://weblogs.asp.net/gad/archive/2004/03/23/94996.aspx
>
> [...]

Apparently Mason Wheeler was not talking about buffer overflows. He was
talking about returning addresses of stack-allocated data (in QT).
Besides, 1) if I understand him correctly, he would still allocate
"value types" on the stack, making stack overflows still possible, 2)
Buffer overflows on the heap can be just as dangerous, 3) ... like you
said, learn to use the screwdriver, or don't use it ;)
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: rival library?

2009-12-20T08:06:51Z

Unfortunely there are lots of average programmers out there.

On Sun, Dec 20, 2009 at 4:48 PM, Jeff Post <j_post@...> wrote:

On Sunday 20 December 2009 03:40, Johannes Kroll wrote:
>

---------
(Note: The above would *not* necessarily "bleed into" method foo. Depends on
the compiler. No C or C++ compiler I know of would allocate pBuff anywhere
but on the stack. But the end result is the same, the hacker can cause
execution of arbitrary code.)

> If it is true, it boils down to bad programming skills
> or bad documentation, not bad language.
>

Yep :-)

Jeff

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

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

Re: rival library?

2009-12-20T07:53:15Z

On Sunday 20 December 2009 06:22, Mason Wheeler wrote:
>
> And yes, that's partially a bad programming skills issue, and I've
> heard that a lot of these bugs have been fixed lately, but it's also
> partially the fault of bad language design for making it possible in
> the first place.
>
Any tool that is powerful is also dangerous. Think what you can do with a
common screwdriver. That doesn't make it bad design. It does make it
incumbent on the programmer to learn to use the power wisely.

Jeff
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: rival library?

2009-12-20T07:47:54Z

On Sunday 20 December 2009 03:40, Johannes Kroll wrote:
>
> Unlike heap allocation, using data on the stack is automatically
> cache-friendly. It's perfectly possible to allocate data from the heap
> though. It's done all the time. I'm not familiar with QT, so I can't
> comment on whether using stack-allocated objects in QT causes security
> problems (how?).

Stack (or buffer) overrun. The following copied from
http://weblogs.asp.net/gad/archive/2004/03/23/94996.aspx

Buffer overrun attack is a very common attack utilized by hackers. This type
of attack is not new. This attack utilizes poor coding practices in C and
C++ code, with the handling of string functions. The following code is an
example of a buffer overrun.

void myMethod(char * pStr) {
char pBuff[10];
int nCount = 0;

strcpy(pBuff, pStr);
}

void foo()
{
}

Cause:

The input pStr is of an unknown size. The string copy is unsafe. If the
string (pStr) is greater then 10 characters, then the buffer (pBuff) starts
to bleed into nCount and the method foo. The buffer overrun property
exploited would allow for the execution of foo by manipulation of the
application input.

---------
(Note: The above would *not* necessarily "bleed into" method foo. Depends on
the compiler. No C or C++ compiler I know of would allocate pBuff anywhere
but on the stack. But the end result is the same, the hacker can cause
execution of arbitrary code.)

> If it is true, it boils down to bad programming skills
> or bad documentation, not bad language.
>

Yep :-)

Jeff
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

testgl compilation failed OSX

2009-12-20T07:47:39Z

* Here is the error:

make testgl

gcc -o testgl testgl.c -g -O2 -I/Volumes/Antares_APPS/build//include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE -I/usr/X11/include -DHAVE_OPENGL -L/Volumes/Antares_APPS/build//lib -lSDL -L/usr/X11/lib -Wl,-framework,OpenGL

ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib

collect2: ld returned 1 exit status

make: *** [testgl] Error 1

* Here is the context:

I use Mac OS 10.5.8 on a PowerPC G4 machine.

I checked out and compiled the trunk. I installed it in a non-standard subdirectory

so that it doesnt' mess with existing SDL 1.2 (which resides under /sw through fink).

In order to compile the tests, I had to manually alter the DYLD_LIBRARY_PATH environment variable so that it knows where to find the newly installed SDL 1.3.

Then I get the error above when attempting to compile the OpenGL tests. Same error for testopengl2 and testopengles.

Thanks,

Julien CLEMENT

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

Re: rival library?

2009-12-20T07:44:49Z

On Sun, 20 Dec 2009 06:22:52 -0800 (PST)
Mason Wheeler <masonwheeler@...> wrote:

> >----- Original Message ----
>
> >From: Johannes Kroll <j-kroll@...>
> >Subject: Re: [SDL] rival library?
> >
> >Unlike heap allocation, using data on the stack is automatically
> >cache-friendly. It's perfectly possible to allocate data from the heap
> >though. It's done all the time. I'm not familiar with QT, so I can't
> >comment on whether using stack-allocated objects in QT causes security
> >problems (how?). If it is true, it boils down to bad programming skills
> >or bad documentation, not bad language.
>
> More safety problems than security problems, though there are points
> where the two overlap. By passing (copies of) stack-allocated objects
> outside the library to user code, which the user code was then able to
> obtain references to. Hilarity ensues once the stack gets cleaned up
> and objects that the object contains a reference to are deallocated
> out from under the user.

Errr... That's a typical newbie error, right? Compilers issue warnings
for these types of errors.

> And yes, that's partially a bad programming skills issue, and I've
> heard that a lot of these bugs have been fixed lately, but it's also
> partially the fault of bad language design for making it possible in
> the first place.

If someone returns an address of something that was allocated on the
stack, it's the programmer's fault, not a fault of the language.

> >> Stack allocation is wonderful for value types. But once you get
> >> something that owns references to other variables, it's more trouble
> >> than it's worth. Then you're better off using another x86 feature:
> >> the built-in instructions for dereferencing pointers.
> >
> >Then use data from the heap where necessary. You're not really
> >suggesting C++ should dump stack allocation altogether?
>
> No, of course not. See above, "stack allocation is wonderful for
> value types." I'm suggesting that C++ should dump stack allocation
> *for objects* altogether.

So where exactly do you draw the line between "objects" and "value
types"? Is a class containing only a few ints and no
pointers/references to anything an object, or a "value type"?

Still, I don't think the dumbness of a few programmers should dumb down
the whole language. :-)

> >C++ is not a VHLL. C++ covers a different area of use than you seem to
> >want. You can perfectly use C++ for programming a 16MHz ATMega micro
> >with 16 Kilobytes RAM. Partly because C++ uses, by default, a string
> >representation that hardware can process efficiently: just a
> >zero-terminated list of bytes.
>
> That's probably the worst example you could have given. See
> http://www.joelonsoftware.com/articles/fog0000000319.html in which
> Joel Spolsky, who knows a lot more about C++ than I ever will,
> explains why C strings are pretty much the *worst possible way* to
> handle strings, from the perspective of the CPU. He specifically holds
> up the Pascal string model as an improvement. It has one drawback,
> that strings are very limited in size. This can be fixed, though, by
> using two bytes, or four, instead of one for the length data.

Let's not discuss performance issues of C-style vs Pascal-style
strings :-) I don't think it makes a huge difference one way or the
other. But the memory usage might. Making the length prefix
variable-sized isn't really feasible since then you would have to
compile all the code an app uses (including libraries) with the same
prefix-size options. So you end up using 4-byte prefixes. So each
string uses 3 bytes more memory than a C string would. This doesn't
normally matter on desktops of course, but on microcontrollers and the
like, it does matter.

> Of course, since strings tend to be big, you probably don't want to
> be passing them around by value (copying all howevermany bytes
> to the stack every time you make a function call) anyway, so it's a
> good idea to make them reference types. IIRC, C strings are
> always reference types anyway, so that's not much of a
> problem... yet.
>
> But due to pointer aliasing, changing a string with multiple
> references to it would cause trouble. So how do you fix that?

If you change a string, it is changed, no matter how many references to
it exist. This is just plain obvious. Everything else would be
counter-intuitive, and wrong. Nothing to fix here.

> By putting a reference count on your string, (which takes care
> of memory and cleanup issues as long as you don't do anything
> stupid like casting it to a pointer), and implementing copy-on-write
> semantics for strings with multiple references.

Actually, no. You wouldn't want features like automatic reference
counting and copy-on-write for strings on systems with limited
resources. These systems probably don't count for you - but like I
said, use a different language then.

> Of course, all of this has to be baked into the compiler to really
> work well. But once you get it working, you have something far
> more efficient for real-world use cases than C strings. No linear
> scan required for obtaining the length or concatenation.
> (Imagine trying to take the length of a C string representing the
> text of an entire novel!) And with the length known up front, your
> CPU can read from it one native word size at a time, (or more, if
> you've got SIMD instructions and large registers available, for
> example,) instead of having to go one byte at a time and then
> test each individual byte to see if it's 0, which results in huge speed
> gains on modern hardware.
>
> The additional cost for all these real-world optimizations is a few
> extra bytes per string. 4-8, depending on how large you make your
> size marker and your reference count, as opposed to 1 byte of
> overhead for C strings. This is the Delphi string model. It's the
> sort of thing that happens when language designers actually think
> about how certain language features get used in real-world use
> cases, instead of applying premature optimizations. (And, of
> course, if those extra bookkeeping bytes are just too much for your
> scenario, the option to fall back to old-school Pascal strings is still
> available.)

If you know that your program will never use strings longer than 256
bytes, yes. ;-)

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

Re: rival library?

2009-12-20T07:34:28Z

Yeah, but C is nothing more than a high level assembler. That's why.

On Sun, Dec 20, 2009 at 4:19 PM, Andre de Leiradella <aleirade@...> wrote:

See
http://www.joelonsoftware.com/articles/fog0000000319.html in which
Joel Spolsky, who knows a lot more about C++ than I ever will,
explains why C strings are pretty much the *worst possible way* to
handle strings, from the perspective of the CPU.

But C doesn't have strings! Strings don't fit in CPU registers :)

Seriously, strings come with their own set of problems that must be solved. For example, when you concatenate two strings, where the result should be written to? Heap is not the right answer because C runs in systems where a heap is not available. The functions in <string.h> help you by *pretending* that character arrays are strings and leave that responsibility to the caller, which is the most sensible thing to do in such systems.

C doesn't force you into a high-level data type that can be implemented in one million different ways because there isn't a correct one for all programmers.

Cheers,

Andre

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

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

Re: rival library?

2009-12-20T07:31:54Z

There are quite a few languages in the Pascal family that successfully have shown that you can
have type safety and systems programming hand in hand.

Oberon, Modula-2, Modula-3, Ada, Eiffel

But they all suffer from a big disadvantage, they belong to the Pascal family of languages and
most programmers tend to lean to the C family of languages.

Maybe D could replace C++, but I doubt it. I don't see many people picking it up, and looking at
the Digital Mars site, it looks like a dead language kind of.

If Microsoft would be a more faire player, C# could take that role, specially looking at their Singularity
project. Then again, this might never happen.

That is why I said that I currently don't see any replacement for C++ happening any time soon.

--
Paulo

On Sun, Dec 20, 2009 at 3:22 PM, Mason Wheeler <masonwheeler@...> wrote:

>----- Original Message ----

>From: Johannes Kroll <j-kroll@...>
>Subject: Re: [SDL] rival library?
>

>Unlike heap allocation, using data on the stack is automatically
>cache-friendly. It's perfectly possible to allocate data from the heap
>though. It's done all the time. I'm not familiar with QT, so I can't
>comment on whether using stack-allocated objects in QT causes security
>problems (how?). If it is true, it boils down to bad programming skills
>or bad documentation, not bad language.

More safety problems than security problems, though there are points
where the two overlap. By passing (copies of) stack-allocated objects
outside the library to user code, which the user code was then able to
obtain references to. Hilarity ensues once the stack gets cleaned up
and objects that the object contains a reference to are deallocated
out from under the user.

And yes, that's partially a bad programming skills issue, and I've
heard that a lot of these bugs have been fixed lately, but it's also
partially the fault of bad language design for making it possible in
the first place.

>> Stack allocation is wonderful for value types. But once you get
>> something that owns references to other variables, it's more trouble
>> than it's worth. Then you're better off using another x86 feature:
>> the built-in instructions for dereferencing pointers.
>
>Then use data from the heap where necessary. You're not really
>suggesting C++ should dump stack allocation altogether?

No, of course not. See above, "stack allocation is wonderful for
value types." I'm suggesting that C++ should dump stack allocation
*for objects* altogether.

Wait, no. That would break backwards compatibility with too much
existing code. What I'm really suggesting is that programmers
should dump C++ altogether. :P

>C++ is not a VHLL. C++ covers a different area of use than you seem to
>want. You can perfectly use C++ for programming a 16MHz ATMega micro
>with 16 Kilobytes RAM. Partly because C++ uses, by default, a string
>representation that hardware can process efficiently: just a
>zero-terminated list of bytes.

That's probably the worst example you could have given. See
http://www.joelonsoftware.com/articles/fog0000000319.html in which
Joel Spolsky, who knows a lot more about C++ than I ever will,
explains why C strings are pretty much the *worst possible way* to
handle strings, from the perspective of the CPU. He specifically holds
up the Pascal string model as an improvement. It has one drawback,
that strings are very limited in size. This can be fixed, though, by
using two bytes, or four, instead of one for the length data.

Of course, since strings tend to be big, you probably don't want to
be passing them around by value (copying all howevermany bytes
to the stack every time you make a function call) anyway, so it's a
good idea to make them reference types. IIRC, C strings are
always reference types anyway, so that's not much of a
problem... yet.

But due to pointer aliasing, changing a string with multiple
references to it would cause trouble. So how do you fix that?
By putting a reference count on your string, (which takes care
of memory and cleanup issues as long as you don't do anything
stupid like casting it to a pointer), and implementing copy-on-write
semantics for strings with multiple references.

Of course, all of this has to be baked into the compiler to really
work well. But once you get it working, you have something far
more efficient for real-world use cases than C strings. No linear
scan required for obtaining the length or concatenation.
(Imagine trying to take the length of a C string representing the
text of an entire novel!) And with the length known up front, your
CPU can read from it one native word size at a time, (or more, if
you've got SIMD instructions and large registers available, for
example,) instead of having to go one byte at a time and then
test each individual byte to see if it's 0, which results in huge speed
gains on modern hardware.

The additional cost for all these real-world optimizations is a few
extra bytes per string. 4-8, depending on how large you make your
size marker and your reference count, as opposed to 1 byte of
overhead for C strings. This is the Delphi string model. It's the
sort of thing that happens when language designers actually think
about how certain language features get used in real-world use
cases, instead of applying premature optimizations. (And, of
course, if those extra bookkeeping bytes are just too much for your
scenario, the option to fall back to old-school Pascal strings is still
available.)

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

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

Re: rival library?

2009-12-20T07:19:19Z

> See
> http://www.joelonsoftware.com/articles/fog0000000319.html in which
> Joel Spolsky, who knows a lot more about C++ than I ever will,
> explains why C strings are pretty much the *worst possible way* to
> handle strings, from the perspective of the CPU.
>
But C doesn't have strings! Strings don't fit in CPU registers :)

Seriously, strings come with their own set of problems that must be
solved. For example, when you concatenate two strings, where the result
should be written to? Heap is not the right answer because C runs in
systems where a heap is not available. The functions in <string.h> help
you by *pretending* that character arrays are strings and leave that
responsibility to the caller, which is the most sensible thing to do in
such systems.

C doesn't force you into a high-level data type that can be implemented
in one million different ways because there isn't a correct one for all
programmers.

Cheers,

Andre

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

Re: rival library?

2009-12-20T06:25:41Z

>----- Original Message ----

>From: Jonathan Dearborn <grimfang4@...>
>Subject: Re: [SDL] rival library?
>
>This is what I was waiting for, Tres.
>
>try
>{
> //stuff
> throw 42;
>}
>catch(int finally)
>{
> //Hooray a finally block :V
>}
>
>I don't have any experience with try..finally. Mason, will this do it?
>
>Jonny D

Close. It would have to be a catch(...) block, in order to also catch
any exceptions that would be thrown from within the code. But it
still doesn't satisfy the requirement that the finally-block code
always execute, even in the case of a return() statement. I don't
think that's possible without compiler support.

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

Re: rival library?

2009-12-20T06:22:52Z

>----- Original Message ----

>From: Johannes Kroll <j-kroll@...>
>Subject: Re: [SDL] rival library?
>
>Unlike heap allocation, using data on the stack is automatically
>cache-friendly. It's perfectly possible to allocate data from the heap
>though. It's done all the time. I'm not familiar with QT, so I can't
>comment on whether using stack-allocated objects in QT causes security
>problems (how?). If it is true, it boils down to bad programming skills
>or bad documentation, not bad language.

More safety problems than security problems, though there are points
where the two overlap. By passing (copies of) stack-allocated objects
outside the library to user code, which the user code was then able to
obtain references to. Hilarity ensues once the stack gets cleaned up
and objects that the object contains a reference to are deallocated
out from under the user.

And yes, that's partially a bad programming skills issue, and I've
heard that a lot of these bugs have been fixed lately, but it's also
partially the fault of bad language design for making it possible in
the first place.

>> Stack allocation is wonderful for value types. But once you get
>> something that owns references to other variables, it's more trouble
>> than it's worth. Then you're better off using another x86 feature:
>> the built-in instructions for dereferencing pointers.
>
>Then use data from the heap where necessary. You're not really
>suggesting C++ should dump stack allocation altogether?

No, of course not. See above, "stack allocation is wonderful for
value types." I'm suggesting that C++ should dump stack allocation
*for objects* altogether.

Wait, no. That would break backwards compatibility with too much
existing code. What I'm really suggesting is that programmers
should dump C++ altogether. :P

>C++ is not a VHLL. C++ covers a different area of use than you seem to
>want. You can perfectly use C++ for programming a 16MHz ATMega micro
>with 16 Kilobytes RAM. Partly because C++ uses, by default, a string
>representation that hardware can process efficiently: just a
>zero-terminated list of bytes.

That's probably the worst example you could have given. See
http://www.joelonsoftware.com/articles/fog0000000319.html in which
Joel Spolsky, who knows a lot more about C++ than I ever will,
explains why C strings are pretty much the *worst possible way* to
handle strings, from the perspective of the CPU. He specifically holds
up the Pascal string model as an improvement. It has one drawback,
that strings are very limited in size. This can be fixed, though, by
using two bytes, or four, instead of one for the length data.

Of course, since strings tend to be big, you probably don't want to
be passing them around by value (copying all howevermany bytes
to the stack every time you make a function call) anyway, so it's a
good idea to make them reference types. IIRC, C strings are
always reference types anyway, so that's not much of a
problem... yet.

But due to pointer aliasing, changing a string with multiple
references to it would cause trouble. So how do you fix that?
By putting a reference count on your string, (which takes care
of memory and cleanup issues as long as you don't do anything
stupid like casting it to a pointer), and implementing copy-on-write
semantics for strings with multiple references.

Of course, all of this has to be baked into the compiler to really
work well. But once you get it working, you have something far
more efficient for real-world use cases than C strings. No linear
scan required for obtaining the length or concatenation.
(Imagine trying to take the length of a C string representing the
text of an entire novel!) And with the length known up front, your
CPU can read from it one native word size at a time, (or more, if
you've got SIMD instructions and large registers available, for
example,) instead of having to go one byte at a time and then
test each individual byte to see if it's 0, which results in huge speed
gains on modern hardware.

The additional cost for all these real-world optimizations is a few
extra bytes per string. 4-8, depending on how large you make your
size marker and your reference count, as opposed to 1 byte of
overhead for C strings. This is the Delphi string model. It's the
sort of thing that happens when language designers actually think
about how certain language features get used in real-world use
cases, instead of applying premature optimizations. (And, of
course, if those extra bookkeeping bytes are just too much for your
scenario, the option to fall back to old-school Pascal strings is still
available.)

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

Re: rival library?

2009-12-20T06:06:44Z

This is what I was waiting for, Tres.

try
{
//stuff
throw 42;
}
catch(int finally)
{
//Hooray a finally block :V
}

I don't have any experience with try..finally. Mason, will this do it?

Jonny D

On Sat, Dec 19, 2009 at 2:56 PM, Tres Walsh <tres.walsh@...> wrote:

> try
> {
> //stuff
> goto finally;
> }
> catch(...)
> {
> finally:
> //More Stuff
> }
>
> Alternatively
>
> try
> {
> //stuff
> throw 42;
> }
> catch(int finally)
> {
> //Hooray a finally block :V
> }
>
> (I'm just having fun being a butthead :P )
>
>> -----Original Message-----
>> From: sdl-bounces@... [mailto:sdl-
>> bounces@...] On Behalf Of Mason Wheeler
>> Sent: Saturday, December 19, 2009 5:07 AM
>> To: SDL Development List
>> Subject: Re: [SDL] rival library?
>>
>> >----- Original Message ----
>>
>> >From: Tres Walsh <tres.walsh@...>
>> >Subject: Re: [SDL] rival library?
>> >
>> >> Is there any way to do this
>> >> in
>> >> C++ without creating a new class and instantiating an object of it,
>> >> which
>> >> is a gross hack?
>> >
>> >/* Terrible Idea! */
>> >try { // stuff }
>> >catch(...) { // more stuff }
>> >
>> >Hope that answers your question! :V
>>
>> No, unfortunately. Unless I'm badly mistaken, the catch(...) code
>> will *only* execute if an exception is thrown. The point of a finally
>> block is that the code will execute no matter what when the flow
>> of control passes out of the block, whether by an exception,
>> a return(), or normal program flow.
>>
>> _______________________________________________
>> SDL mailing list
>> SDL@...
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
> _______________________________________________
> SDL mailing list
> SDL@...
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>

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

Re: rival library?

2009-12-20T05:44:34Z

Well actually there are quite a few higher level languages that run on such small environments.

http://en.wikipedia.org/wiki/Sun_SPOT (Java subset)
http://www.parallax.com/propeller/ (Spin)
http://www.parallax.com/tabid/295/Default.aspx (Basic)

But this does not break the concept that we need system programing languages that are free
from vendor lock-in, standard, portable as much as possible between several target sytems,
high level enough to be productive but also allow to work low level when needed.

So far no language was able to dispel C and C++ from their places exactly because they are
not able to offer better alternatives. And when they do, the effort of switching the complete IT is
not worth it.

Assembler is still needed nowadays, even if it is only in some niche cases. The same will hold
true for C/C++.

Even if an OS is 98% coded in a higher level language, maybe those 2% will be something like C
or C++.

Because the tools are good enough at their job.

--
Paulo

On Sun, Dec 20, 2009 at 12:40 PM, Johannes Kroll <j-kroll@...> wrote:

On Sat, 19 Dec 2009 07:55:23 -0800 (PST)
Mason Wheeler <masonwheeler@...> wrote:

> >----- Original Message ----
>
> >From: Johannes Kroll <j-kroll@...>
> >Subject: Re: [SDL] rival library?
> >
> >Allocating stuff on the stack is an efficient, cache-friendly,
> >hardware-supported way of using local variables. As long as computing
> >power is finite, efficiency will be an issue. Which makes the
> >discussion about stack allocation a little redundant.
>
> You're trading a very minor (dare I say "premature"?) optimization
> for all sorts of safety problems. Just look at all the troubles caused
> by QT using stack-allocated objects without doing a good job of
> documenting what was a value type and what was a reference type.

Unlike heap allocation, using data on the stack is automatically
cache-friendly. It's perfectly possible to allocate data from the heap
though. It's done all the time. I'm not familiar with QT, so I can't
comment on whether using stack-allocated objects in QT causes security
problems (how?). If it is true, it boils down to bad programming skills
or bad documentation, not bad language.

> >It's just the way today's computers do things. That's what registers
> >like ESP and EBP on x86 are for.
>
> Stack allocation is wonderful for value types. But once you get
> something that owns references to other variables, it's more trouble
> than it's worth. Then you're better off using another x86 feature:
> the built-in instructions for dereferencing pointers.

Then use data from the heap where necessary. You're not really
suggesting C++ should dump stack allocation altogether? Or are you
suggesting the language should let the programmer decide whether to
allocate from stack or from heap? That's exactly what C++ is doing.

> >C++ is just not high-level enough to ignore the machines it's
> >running on.
>
> Never said it should be. The problem is that C++ ignores the
> problem domain. That's not a matter of high-level or low-level,
> it's a matter of bad language design.
>
> >Maybe you want another language.
>
> No "maybe" about it!

C++ is not a VHLL. C++ covers a different area of use than you seem to
want. You can perfectly use C++ for programming a 16MHz ATMega micro
with 16 Kilobytes RAM. Partly because C++ uses, by default, a string
representation that hardware can process efficiently: just a
zero-terminated list of bytes. If std::string were built into the
language, it would waste precious extra RAM. Because it's part of the
STL, you *can* use it, but you don't have to, if every byte counts.
That makes C++ flexible. If everything that people would like to have
(like garbage collection...) was built into the language, using it to
program microcontrollers, for example, would not be possible. Likewise,
you can't afford to allocate *everything* from the heap on those
systems because of allocation overhead (processing time, wasted space).

C++ is just not the language you want.
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

Re: lib compilation

2009-12-20T04:40:28Z

Doesn't work for me. :/
Can you upload the vc++08 converted project files?

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

Re: rival library?

2009-12-20T03:40:27Z

On Sat, 19 Dec 2009 07:55:23 -0800 (PST)
Mason Wheeler <masonwheeler@...> wrote:

> >----- Original Message ----
>
> >From: Johannes Kroll <j-kroll@...>
> >Subject: Re: [SDL] rival library?
> >
> >Allocating stuff on the stack is an efficient, cache-friendly,
> >hardware-supported way of using local variables. As long as computing
> >power is finite, efficiency will be an issue. Which makes the
> >discussion about stack allocation a little redundant.
>
> You're trading a very minor (dare I say "premature"?) optimization
> for all sorts of safety problems. Just look at all the troubles caused
> by QT using stack-allocated objects without doing a good job of
> documenting what was a value type and what was a reference type.

Unlike heap allocation, using data on the stack is automatically
cache-friendly. It's perfectly possible to allocate data from the heap
though. It's done all the time. I'm not familiar with QT, so I can't
comment on whether using stack-allocated objects in QT causes security
problems (how?). If it is true, it boils down to bad programming skills
or bad documentation, not bad language.

> >It's just the way today's computers do things. That's what registers
> >like ESP and EBP on x86 are for.
>
> Stack allocation is wonderful for value types. But once you get
> something that owns references to other variables, it's more trouble
> than it's worth. Then you're better off using another x86 feature:
> the built-in instructions for dereferencing pointers.

Then use data from the heap where necessary. You're not really
suggesting C++ should dump stack allocation altogether? Or are you
suggesting the language should let the programmer decide whether to
allocate from stack or from heap? That's exactly what C++ is doing.

> >C++ is just not high-level enough to ignore the machines it's
> >running on.
>
> Never said it should be. The problem is that C++ ignores the
> problem domain. That's not a matter of high-level or low-level,
> it's a matter of bad language design.
>
> >Maybe you want another language.
>
> No "maybe" about it!

C++ is not a VHLL. C++ covers a different area of use than you seem to
want. You can perfectly use C++ for programming a 16MHz ATMega micro
with 16 Kilobytes RAM. Partly because C++ uses, by default, a string
representation that hardware can process efficiently: just a
zero-terminated list of bytes. If std::string were built into the
language, it would waste precious extra RAM. Because it's part of the
STL, you *can* use it, but you don't have to, if every byte counts.
That makes C++ flexible. If everything that people would like to have
(like garbage collection...) was built into the language, using it to
program microcontrollers, for example, would not be possible. Likewise,
you can't afford to allocate *everything* from the heap on those
systems because of allocation overhead (processing time, wasted space).

C++ is just not the language you want.
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: SDL 1.3 docs?

2009-12-20T02:24:41Z

I guess that the best solution for the time being is to look at the provided sample code.

On Sun, Dec 20, 2009 at 4:04 AM, Ken Rogoway <Ken@...> wrote:

Has anyone built docs for SDL 1.3? In particular documentation regarding
the use of textures instead of surfaces (the old API vs. the new API)?

I built and ran my game using SDL 1.2.14 and got 29 FPS.
I then build and ran it using SDL 1.3.0 using the Compatibility mode (old
API) and got 15 FPS.

It looks like it is time to switch over to the new Texture based API so I
can get decent performance, but it looks like there isn't any documentation
other than the headers. I thought I saw a post a while back that talked
about the changes necessary to migrate 1.2.x to 1.3.x, but cannot find it in
emails.

I have built the docs using doxygen, and although all of the new functions
are in the generated html, there really isn't a good example of migrating
from 1.2.x to 1.3.x

Can someone point me to a old post or doc somewhere that details this?

Thanks,

Ken Rogoway

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

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

Re: rival library?

2009-12-20T01:04:26Z

Gregory Smith writes:

> To paraphrase The Simpsons, can't this list go one week without a C++
> flamewar?

Hey guys! Look what I found in the mailing list server!

# ls /etc/cron.weekly/
c++flamewar

#

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

SDL 1.3 docs?

2009-12-19T19:04:07Z

Has anyone built docs for SDL 1.3? In particular documentation regarding
the use of textures instead of surfaces (the old API vs. the new API)?

I built and ran my game using SDL 1.2.14 and got 29 FPS.
I then build and ran it using SDL 1.3.0 using the Compatibility mode (old
API) and got 15 FPS.

It looks like it is time to switch over to the new Texture based API so I
can get decent performance, but it looks like there isn't any documentation
other than the headers. I thought I saw a post a while back that talked
about the changes necessary to migrate 1.2.x to 1.3.x, but cannot find it in
emails.

I have built the docs using doxygen, and although all of the new functions
are in the generated html, there really isn't a good example of migrating
from 1.2.x to 1.3.x

Can someone point me to a old post or doc somewhere that details this?

Thanks,

Ken Rogoway

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

Re: lib compilation

2009-12-19T15:30:57Z

Sorry small typo, I meant 2008 not 2009.

On Sun, Dec 20, 2009 at 12:30 AM, Paulo Pinto <pjmlp@...> wrote:

Not sure what your issue might be.

I just tried to open the Visual Studio 2007 solution that is delivered together with the
SDL 1.2 source code, by using the Visual Studio C++ 2008 Express.

Visual Studio asked me if I wanted to converted the project, I said yes and got a
Visual Studio 2009 compliant project.

--
Paulo

On Sat, Dec 19, 2009 at 3:44 PM, clv <commelevent@...> wrote:

Hi
I need help figuring out how exactly to compile the source to get sdl.lib, sdlmain.lib and the sdl.dll. Since the vc++ projects won't convert with my vc++08, i have no idea which files to compile to get the individual sdl files. I would usually use the downloadable libs, but i need 64 bit versions.

I searched both google and this forum but didn't find the info. Anybody know how to convert those project files, or which files to include in a project to compile the three files?

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

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

Re: lib compilation

2009-12-19T15:30:09Z

Not sure what your issue might be.

I just tried to open the Visual Studio 2007 solution that is delivered together with the
SDL 1.2 source code, by using the Visual Studio C++ 2008 Express.

Visual Studio asked me if I wanted to converted the project, I said yes and got a
Visual Studio 2009 compliant project.

--
Paulo

On Sat, Dec 19, 2009 at 3:44 PM, clv <commelevent@...> wrote:

Hi
I need help figuring out how exactly to compile the source to get sdl.lib, sdlmain.lib and the sdl.dll. Since the vc++ projects won't convert with my vc++08, i have no idea which files to compile to get the individual sdl files. I would usually use the downloadable libs, but i need 64 bit versions.

I searched both google and this forum but didn't find the info. Anybody know how to convert those project files, or which files to include in a project to compile the three files?

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

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