Proposition for SDL_math

SDL Development
1

Hello,

I was starting to make ‘yet another math library’ when
I thought that was a good idea to have something like SDL_math.
Let me explain. We already have SDL_net, SDL_audio, SDL_image,
and so on, why would we need an SDL_math ?
I think that is a good idea to have a math library as part of
SDL, because most of graphics programming means math. So the
library would have support for matrix, vector, points operations
in homogeneous and non-homogeneous coordinates. The ability to pass
points and matrices to the OpenGL system. And most important optimizations
at the processor level.
The library could use MMX, SIMD, or whatever to speed up operations.
Since all the other SDL_* packages are done in C, that should be
the language for building SDL_math.
If you like the idea, I will try to create an inicial proposition and
post it, as soon as possible.–
Paulo Pinto, uRD Software Engineer
Altitude Software (formerly Easyphone)

paulo.pinto at altitudesoftware.com
www.altitudesoftware.com

The opinions expressed by myself are personal and not of my employer.
Programming languages teach you not to want what they cannot provide.

2

I think this would be a great idea, especially if through the library you had
access to a number of different algorythms for the same features (i.e, you had
two matrix multiplication algorythms, one for speed, one for accuracy, etc).

Also, I think it should be a general graphical math lib… and not focus
entirely upon OpenGL & 3D graphics (I realize you weren’t necessarily proposing
it be only 3D math functions, I was just stating a preference ;-)On Wed, 28 Mar 2001, you wrote:

Hello,

I was starting to make ‘yet another math library’ when
I thought that was a good idea to have something like SDL_math.
Let me explain. We already have SDL_net, SDL_audio, SDL_image,
and so on, why would we need an SDL_math ?
I think that is a good idea to have a math library as part of
SDL, because most of graphics programming means math. So the
library would have support for matrix, vector, points operations
in homogeneous and non-homogeneous coordinates. The ability to pass
points and matrices to the OpenGL system. And most important optimizations
at the processor level.
The library could use MMX, SIMD, or whatever to speed up operations.
Since all the other SDL_* packages are done in C, that should be
the language for building SDL_math.
If you like the idea, I will try to create an inicial proposition and
post it, as soon as possible.

–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

3

Paulo Pinto wrote:
I think that is a good idea to have a math library as part of

SDL, because most of graphics programming means math. So the
library would have support for matrix, vector, points operations
in homogeneous and non-homogeneous coordinates.

Don’t forget fixed-point math !! :slight_smile:

-- David Snopek

/-- libksd –
| The C++ Cross-Platform Game Framework
| Only want to write it once??
| http://libksd.sourceforge.net
------------

4

Good idea, but I don’t see why a maths library should be dependent on
SDL.On Wed, Mar 28, 2001 at 02:44:35PM +0100, Paulo Pinto wrote:

I was starting to make ‘yet another math library’ when
I thought that was a good idea to have something like SDL_math.
Let me explain. We already have SDL_net, SDL_audio, SDL_image,
and so on, why would we need an SDL_math ?

–
Martin

Bother! said Pooh, as he found that he had gonorrhea.

5

I dont think SDL_math is a good idea from a personal standpoint. Most math
encapsulation is done for use of algorithms. Algorithms that must be
optimized, and encapsulating it defeats the purpose of using a particular
structure or class in the first place.

You have to tie in the data structure quite closely to the algorithm in some
cases. I dont know if this is true in modern game design, but some function
overhead or class overhead could have more impact then the actual operation
itself. Granted the code can be inlined and you can return references and
operator overloading and everything else, but still. The more generic it is,
the least useful it is. A programmer should write his own math routines to
tailor his graphics engine, not the other way around.

IMHO, sometimes too much encapsulation is a bad thing. A simple API lets the
programmer do the programming, and less time reading docs… I mean, even if
it takes the guy twice as long to do it himself then to figure out the docs,
its worth it in my opinion. I am sick and tired of reading docs… Thats why
people who programmed DOS were so pissed off at Win32 API that had a
function for everything… its a lot more enjoyable just trying to program
instead of spending 90% of your time referencing docs or working around
bugs…I swear if I have to work around one more MFC bug at work Im going to
choke gates

Matt> Hello,

I was starting to make ‘yet another math library’ when
I thought that was a good idea to have something like SDL_math.
Let me explain. We already have SDL_net, SDL_audio, SDL_image,
and so on, why would we need an SDL_math ?
I think that is a good idea to have a math library as part of
SDL, because most of graphics programming means math. So the
library would have support for matrix, vector, points operations
in homogeneous and non-homogeneous coordinates. The ability to pass
points and matrices to the OpenGL system. And most important optimizations
at the processor level.
The library could use MMX, SIMD, or whatever to speed up operations.
Since all the other SDL_* packages are done in C, that should be
the language for building SDL_math.
If you like the idea, I will try to create an inicial proposition and
post it, as soon as possible.

–
Paulo Pinto, uRD Software Engineer
Altitude Software (formerly Easyphone)

paulo.pinto at altitudesoftware.com
www.altitudesoftware.com

The opinions expressed by myself are personal and not of my employer.
Programming languages teach you not to want what they cannot provide.

6

I dont think SDL_math is a good idea from a personal standpoint. Most math
encapsulation is done for use of algorithms. Algorithms that must be
optimized, and encapsulating it defeats the purpose of using a particular
structure or class in the first place.

You have to tie in the data structure quite closely to the algorithm in
some cases. I dont know if this is true in modern game design, but some
function overhead or class overhead could have more impact then the actual
operation itself.

The trick is to design around array operations.

Granted the code can be inlined and you can return
references and operator overloading and everything else, but still. The
more generic it is, the least useful it is. A programmer should write his
own math routines to tailor his graphics engine, not the other way around.

Not quite. These days, there are various SIMD extensions both in the CPUs and
on the video cards, and these happen to fit very nicely behind the APIs of
traditional array based math libraries.

Obviously, you have to design your algorithms around array operations to make
use of this, just as you have to design a 3D game around a 3D API to make use
of hardware 3D acceleration.

IMHO, sometimes too much encapsulation is a bad thing. A simple API lets
the programmer do the programming, and less time reading docs…

Right, but I don’t see how this applies to a high speed math library… I
mean, it has to be array based for performance and SIMD acceleration support,
and the API has to be rather simple to minimize overhead.

Any API that takes too much time to learn in relation to the benefits is very
likely poorly designed, or just the wrong tool for your project.

I mean,
even if it takes the guy twice as long to do it himself then to figure out
the docs, its worth it in my opinion.

That won’t work if you have to code for a living. The priority is getting the
product out in time - all other things are secondary, and can be sacrificed
to meet the deadline, even if that means that lots of code will have to be
thrown away and rewritten for the next release…

I am sick and tired of reading docs…
Thats why people who programmed DOS were so pissed off at Win32 API that
had a function for everything… its a lot more enjoyable just trying to
program instead of spending 90% of your time referencing docs or working
around bugs…I swear if I have to work around one more MFC bug at work Im
going to choke gates

Why are you assuming that “API” is synonymous to various crap from MS? There
is a big difference between "must get all of this in before the deadline"
style APIs and properly designed stuff. It doesn’t have to be nasty just
because it’s called “API”! :wink:

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 28 March 2001 20:10, Matt Johnson wrote:

7

Perhaps so… but an SDL friendly graphical math library would sure be nice
;-)On Wed, 28 Mar 2001, you wrote:

Good idea, but I don’t see why a maths library should be dependent on
SDL.

–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

8

Also, I think it should be a general graphical math lib… and not focus
entirely upon OpenGL & 3D graphics (I realize you weren’t necessarily
proposing
it be only 3D math functions, I was just stating a preference :wink:

Agree on everything, except this. I think it should be focused on OpenGL,
that’s the “official” SDL 3D API…–
Marco Iannaccone
@Marco_Iannaccone
ICQ UIN: 18748121 MetalCoder

"What is real? How do you define real? If you’re talking about your senses,
what you feel, taste,
smell, or see, then all you’re talking about are electrical signals
interpreted by your brain."
Morpheus - The Matrix

9

In my personal point of view, it would be nice.

The only big doubt is whether a C++ implementation will be developed. I know
that all SDL is C and not C++, but I think that there only a few guys left
out there that still use C math libraries. C++ is just more powerful for
this kind of things, the code is way more readable.
Of course, I would not like to start a big flame about old school boys that
believe that C++ is too slow for overhead against new guys that know well
that C++ can be driven to be even faster than C. This is not the point. The
point is that most people nowadays use C++ at least for math libraries, and
we should not ignore this.

Personally, I’m not going to use any math library that comes in C-only
fashion, and I know the same would apply to a lot of developers.—
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

  • Black holes are generated when God divides by zero -

-----Messaggio originale-----
Da: owner-sdl at lokigames.com [mailto:owner-sdl at lokigames.com]Per conto di
Paulo Pinto
Inviato: mercoled? 28 marzo 2001 15.45
A: sdl at lokigames.com
Oggetto: [SDL] Proposition for SDL_math

Hello,

I was starting to make ‘yet another math library’ when
I thought that was a good idea to have something like SDL_math.
Let me explain. We already have SDL_net, SDL_audio, SDL_image,
and so on, why would we need an SDL_math ?
I think that is a good idea to have a math library as part of
SDL, because most of graphics programming means math. So the
library would have support for matrix, vector, points operations
in homogeneous and non-homogeneous coordinates. The ability to pass
points and matrices to the OpenGL system. And most important optimizations
at the processor level.
The library could use MMX, SIMD, or whatever to speed up operations.
Since all the other SDL_* packages are done in C, that should be
the language for building SDL_math.
If you like the idea, I will try to create an inicial proposition and
post it, as soon as possible.

–
Paulo Pinto, uRD Software Engineer
Altitude Software (formerly Easyphone)

paulo.pinto at altitudesoftware.com
www.altitudesoftware.com

The opinions expressed by myself are personal and not of my employer.
Programming languages teach you not to want what they cannot provide.

10

Hello,

I was starting to make ‘yet another math library’ when
I thought that was a good idea to have something like SDL_math.
Let me explain. We already have SDL_net, SDL_audio, SDL_image,
and so on, why would we need an SDL_math ?
I think that is a good idea to have a math library as part of
SDL, because most of graphics programming means math.

Not necessarily. For 3D graphics programming, yes, but not 2D. There’s only
been one 2D program I’ve written that needed any complex math for the
graphics stuff. This complex math stuff wasn’t explicitly for the graphics
most of the time, though. So for 2D, this math library would probably be
unnecessary.

So the
library would have support for matrix, vector, points operations
in homogeneous and non-homogeneous coordinates. The ability to pass
points and matrices to the OpenGL system. And most important optimizations
at the processor level.

Sounds like a general purpose 3D math library. I’d be highly surprised if
something like this doesn’t already exist out there somewhere. Seems more
logical to try and find it rather than reinvent the wheel.

The library could use MMX, SIMD, or whatever to speed up operations.
Since all the other SDL_* packages are done in C, that should be
the language for building SDL_math.

I’m generally one for prefering C APIs to C++ APIs, however in the case of a
math library, I think C++ works much better. This is really the only
exception I’ve run across to date. That’s my opinion anyway.

If you like the idea, I will try to create an inicial proposition and
post it, as soon as possible.

Unless there aren’t any out there already, or they all suck for whatever
reasons, then I don’t really think it’s that good of an idea. Unless you are
just looking for something to do, or want to learn from the experience or
whatever.

These are all just my opinions, so don’t take them as flames or anything.On Wednesday 28 March 2001 05:44, you wrote:

11

The trick is to design around array operations.

Ok. I have no idea what you are talking about, though. :slight_smile:

IMHO, sometimes too much encapsulation is a bad thing. A simple API lets
the programmer do the programming, and less time reading docs…

Right, but I don’t see how this applies to a high speed math library… I
mean, it has to be array based for performance and SIMD acceleration
support, and the API has to be rather simple to minimize overhead.

Any API that takes too much time to learn in relation to the benefits is
very likely poorly designed, or just the wrong tool for your project.

Or the people designing it just got carried away, which tends to be one of
the biggest problems with C++ fanatics. I know where he’s coming from on
this. Simplicity would definately be the better choice for this library (or
any library really).

I mean,
even if it takes the guy twice as long to do it himself then to figure
out the docs, its worth it in my opinion.

That won’t work if you have to code for a living. The priority is getting
the product out in time - all other things are secondary, and can be
sacrificed to meet the deadline, even if that means that lots of code will
have to be thrown away and rewritten for the next release…

That depends on where you work. A lot of places use this philosophy, which
unfortunately is very detrimental in the long term. A much better model is
that making sure the product works at all should be the 1st priority, and
getting it out on time secondary, with everyone else below that. Don’t
believe that’s a good model? Just look at how everyone hates all the
bugginess of microsoft products. It’s causing a lot of people to switch to
Linux as a result. Anyway, this is getting offtopic.

Why are you assuming that “API” is synonymous to various crap from MS?
There is a big difference between “must get all of this in before the
deadline” style APIs and properly designed stuff. It doesn’t have to be
nasty just because it’s called “API”! :wink:

That’s not really the issue I don’t think. It’s the people driving the API.
Some of the worst APIs are designed by people who take all the time they need
to to “design it right”, and end up throwing everything but the kitchen sink
into it. They want to make it very robust and flexible, but the problem is
they make it too complicated as well. The 2 reasons I like SDL is because it
allows me to do the things I want to do, and because it is easy to use. I
think API design is an art form really, and while anyone can do it, few can
really master it.On Wednesday 28 March 2001 11:06, you wrote:

12

Right on! If it implemented handy matrix operations (rref, rank, det,
eigenstuff, etc), for fairly large matrices, in either int, float or
double, that would be great. Integration w/ SDL_video (for applying
transforms to regions of screens and such) would be nice. And maybe
functions for generating gradient-fields, etc., too.

Essentially, a fast library that implemented all the functions of your
spiffy HP or TI calculator, really.

The C/C++ argument is silly, do the core math routines in C, with c++
wrapper classes and everyone’s happy. And the 2d/3d argument is somewhat
silly, too – 2d math is 3d math with z=0.

-Jared
@Jared_MaguireOn Wed, Mar 28, 2001 at 02:44:35PM +0100, Paulo Pinto wrote:

I think that is a good idea to have a math library as part of
SDL, because most of graphics programming means math. So the
library would have support for matrix, vector, points operations
in homogeneous and non-homogeneous coordinates. The ability to pass
points and matrices to the OpenGL system. And most important optimizations
at the processor level.
The library could use MMX, SIMD, or whatever to speed up operations.

13

Giovanni Bajo wrote:

In my personal point of view, it would be nice.

The only big doubt is whether a C++ implementation will be developed. I know
that all SDL is C and not C++, but I think that there only a few guys left
out there that still use C math libraries. C++ is just more powerful for
this kind of things, the code is way more readable.
Of course, I would not like to start a big flame about old school boys that
believe that C++ is too slow for overhead against new guys that know well
that C++ can be driven to be even faster than C. This is not the point. The
point is that most people nowadays use C++ at least for math libraries, and
we should not ignore this.

Personally, I’m not going to use any math library that comes in C-only
fashion, and I know the same would apply to a lot of developers.

code is code is code is code

-- David Snopek

/-- libksd –
| The C++ Cross-Platform Game Framework
| Only want to write it once??
| http://libksd.sourceforge.net
------------

14

But there are a lot of non-3D graphic algorythms I’d like to see in this. There
are some very neat 2D effects that would be of great use (even in 3D areas).

I was just stating I’d prefer it focus on more general graphical algorythms
than just 3D ones.On Wed, 28 Mar 2001, you wrote:

Also, I think it should be a general graphical math lib… and not focus
entirely upon OpenGL & 3D graphics (I realize you weren’t necessarily
proposing
it be only 3D math functions, I was just stating a preference :wink:

Agree on everything, except this. I think it should be focused on OpenGL,
that’s the “official” SDL 3D API…

–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

15

In my personal point of view, it would be nice.

The only big doubt is whether a C++ implementation will be developed. I know
that all SDL is C and not C++, but I think that there only a few guys left
out there that still use C math libraries. C++ is just more powerful for
this kind of things, the code is way more readable.

Actually, my only push for C++ in this respect would be for the operator
overloading… as for a /math/ graphic lib this would be extremely handy.

All of the other C/C++ arguments really don’t hold as much weight in this
instance as the operator overloading one does…

The
point is that most people nowadays use C++ at least for math libraries, and
we should not ignore this.

Speaking as someone trained in Physics and Mathematics (computers just so
happen to be the hobby that pays my bills :wink: … I really don’t see much
validity in this statement… sorry ;-)On Wed, 28 Mar 2001, you wrote:

–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

16

Martin Donlon wrote:

Paulo Pinto wrote:

I was starting to make ‘yet another math library’ when
I thought that was a good idea to have something like
SDL_math.

Good idea, but I don’t see why a maths library should be
dependent on SDL.

That’s what I don’t get. Doesn’t an SDL library kind of imply a dependency
on SDL? I have yet to take a close look at SDL_net but I have a feeling that
it falls under this category as well. At least SDL_net has some
cross-platform issues that it is trying to address.

Like Martin says, good idea, but why the SDL dependency?

  • Randi

Regimental Command
Generic Armored Combat System
http://regcom.sourceforge.net

17

Maybe it doesn’t have to have an SDL dependency, maybe it’s intended to be
useful mostly to users of SDL?–

Olivier A. Dagenais - Software Architect and Developer

I was starting to make ‘yet another math library’ when
I thought that was a good idea to have something like
SDL_math.
Good idea, but I don’t see why a maths library should be
dependent on SDL.
That’s what I don’t get. Doesn’t an SDL library kind of imply a dependency
on SDL? I have yet to take a close look at SDL_net but I have a feeling
that
it falls under this category as well. At least SDL_net has some
cross-platform issues that it is trying to address.
Like Martin says, good idea, but why the SDL dependency?

18

The C/C++ argument is silly, do the core math routines in C, with c++
wrapper classes and everyone’s happy. And the 2d/3d argument is somewhat
silly, too – 2d math is 3d math with z=0.

Surely? Were we can find C math lib as efficient as C++?
If we will have C++ wrapper of C math lib, how fast it will be?
I think it will be the worst of two worlds.

Best wishes,
AlexeiFrom: jared@choronzon.net (Jared Maguire)

19

To be honest it wouldn’t have any SDL dependecy, so maybe I should
choose another name.> ----- Original Message -----

From: olivier.dagenais@canada.com (Olivier Dagenais)
To:
Sent: Thursday, March 29, 2001 6:44 AM
Subject: [SDL] Re: Proposition for SDL_math

Maybe it doesn’t have to have an SDL dependency, maybe it’s intended to be
useful mostly to users of SDL?

–

Olivier A. Dagenais - Software Architect and Developer

I was starting to make ‘yet another math library’ when
I thought that was a good idea to have something like
SDL_math.
Good idea, but I don’t see why a maths library should be
dependent on SDL.
That’s what I don’t get. Doesn’t an SDL library kind of imply a
dependency

on SDL? I have yet to take a close look at SDL_net but I have a feeling
that
it falls under this category as well. At least SDL_net has some
cross-platform issues that it is trying to address.
Like Martin says, good idea, but why the SDL dependency?

20

Sam,

The
point is that most people nowadays use C++ at least for math
libraries, and
we should not ignore this.

Speaking as someone trained in Physics and Mathematics (computers just so
happen to be the hobby that pays my bills :wink: … I really don’t see much
validity in this statement… sorry :wink:

You are completely right, the sentence itself was misleading.
Let me rephrase it:

The point is that most people that do graphic programming (thus they are the
main users of SDL) use C++ for their math libraries, mainly thank to
operator overloading.—
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

  • Black holes are generated when God divides by zero -