SDL_SolidIcosahedron() and other platonics

SDL Development
1

Hi,

I digged through old sources today and put some stuff together:

http://www.gltron.org/stuff/SDL_platonics.tar.gz

It’s public domain and it contains

extern void SDL_WireTetrahedron();
extern void SDL_SolidTetrahedron();
extern void SDL_WireOctahedron();
extern void SDL_SolidOctahedron();
extern void SDL_WireIcosahedron();
extern void SDL_SolidIcosahedron();
extern void SDL_SolidDodecahedron();
extern void SDL_WireDodecahedron();
extern void SDL_WireCube( GLdouble dSize );
extern void SDL_SolidCube( GLdouble dSize );
extern void SDL_WireSphere( GLdouble dRadius, GLint slices, GLint stacks );
extern void SDL_SolidSphere( GLdouble dRadius, GLint slices, GLint stacks );

Yes, I know, the teapot is missing. Also missing are Cone and Torus.

  • Andreas–
    Check out my 3D lightcycle game: http://www.gltron.org
    More than 100’000 Downloads of the last version (0.59)
2

Hi,

I digged through old sources today and put some stuff together:

http://www.gltron.org/stuff/SDL_platonics.tar.gz

It’s public domain and it contains

[…]

Please use a different prefix so it doesn’t conflict with core library
names in the future.

Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

3

Yes, I know, the teapot is missing. Also missing are Cone and Torus.

how dare you, the teapot is the foremost of the platonics! :slight_smile:

4

Not exactly the responses I hoped for:

Please use a different prefix so it doesn’t conflict with core library
names in the future.

What about: ‘Hey, these functions already have the right prefix.
I’ll just add these two files to the SDL CVS.’

how dare you, the teapot is the foremost of the platonics! :slight_smile:

I’ll just post the (copyrighted, but it’s a fairly moderate license) source
here. Removing the bottom from the teapot is left as an exercise to the
reader:

/*

  • Original teapot code copyright follows:
    */

/*

  • © Copyright 1993, Silicon Graphics, Inc.*
  • ALL RIGHTS RESERVED
  • Permission to use, copy, modify, and distribute this software
  • for any purpose and without fee is hereby granted, provided
  • that the above copyright notice appear in all copies and that
  • both the copyright notice and this permission notice appear in
  • supporting documentation, and that the name of Silicon
  • Graphics, Inc. not be used in advertising or publicity
  • pertaining to distribution of the software without specific,
  • written prior permission.
  • THE MATERIAL EMBODIED ON THIS SOFTWARE IS PROVIDED TO YOU
  • “AS-IS” AND WITHOUT WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR
  • OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF
  • MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO
  • EVENT SHALL SILICON GRAPHICS, INC. BE LIABLE TO YOU OR ANYONE
  • ELSE FOR ANY DIRECT, SPECIAL, INCIDENTAL, INDIRECT OR
  • CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY DAMAGES WHATSOEVER,
  • INCLUDING WITHOUT LIMITATION, LOSS OF PROFIT, LOSS OF USE,
  • SAVINGS OR REVENUE, OR THE CLAIMS OF THIRD PARTIES, WHETHER OR
  • NOT SILICON GRAPHICS, INC. HAS BEEN ADVISED OF THE POSSIBILITY
  • OF SUCH LOSS, HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
  • ARISING OUT OF OR IN CONNECTION WITH THE POSSESSION, USE OR
  • PERFORMANCE OF THIS SOFTWARE.
  • US Government Users Restricted Rights
  • Use, duplication, or disclosure by the Government is subject to
  • restrictions set forth in FAR 52.227.19©(2) or subparagraph
  • ©(1)(ii) of the Rights in Technical Data and Computer
  • Software clause at DFARS 252.227-7013 and/or in similar or
  • successor clauses in the FAR or the DOD or NASA FAR
  • Supplement. Unpublished-- rights reserved under the copyright
  • laws of the United States. Contractor/manufacturer is Silicon
  • Graphics, Inc., 2011 N. Shoreline Blvd., Mountain View, CA
  • 94039-7311.
  • OpenGL™ is a trademark of Silicon Graphics, Inc.
    */

/*

  • Rim, body, lid, and bottom data must be reflected in x and y;
  • handle and spout data across the y axis only.
    /
    static int patchdata[][16] =
    {
    { 102, 103, 104, 105, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 }, /     rim /
    { 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27 }, /     body /
    { 24, 25, 26, 27, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40 },
    { 96, 96, 96, 96, 97, 98, 99, 100, 101, 101, 101, 101, 0, 1, 2, 3 }, /     lid /
    { 0, 1, 2, 3, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117 },
    { 118, 118, 118, 118, 124, 122, 119, 121, 123, 126, 125, 120, 40, 39, 38, 37 }, /     bottom /
    { 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56 }, /     handle /
    { 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 28, 65, 66, 67 },
    { 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83 }, /     spout */
    { 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95 }
    };

static float cpdata[][3] =
{
{0.2, 0, 2.7}, {0.2, -0.112, 2.7}, {0.112, -0.2, 2.7}, {0,
-0.2, 2.7}, {1.3375, 0, 2.53125}, {1.3375, -0.749, 2.53125},
{0.749, -1.3375, 2.53125}, {0, -1.3375, 2.53125}, {1.4375,
0, 2.53125}, {1.4375, -0.805, 2.53125}, {0.805, -1.4375,
2.53125}, {0, -1.4375, 2.53125}, {1.5, 0, 2.4}, {1.5, -0.84,
2.4}, {0.84, -1.5, 2.4}, {0, -1.5, 2.4}, {1.75, 0, 1.875},
{1.75, -0.98, 1.875}, {0.98, -1.75, 1.875}, {0, -1.75,
1.875}, {2, 0, 1.35}, {2, -1.12, 1.35}, {1.12, -2, 1.35},
{0, -2, 1.35}, {2, 0, 0.9}, {2, -1.12, 0.9}, {1.12, -2,
0.9}, {0, -2, 0.9}, {-2, 0, 0.9}, {2, 0, 0.45}, {2, -1.12,
0.45}, {1.12, -2, 0.45}, {0, -2, 0.45}, {1.5, 0, 0.225},
{1.5, -0.84, 0.225}, {0.84, -1.5, 0.225}, {0, -1.5, 0.225},
{1.5, 0, 0.15}, {1.5, -0.84, 0.15}, {0.84, -1.5, 0.15}, {0,
-1.5, 0.15}, {-1.6, 0, 2.025}, {-1.6, -0.3, 2.025}, {-1.5,
-0.3, 2.25}, {-1.5, 0, 2.25}, {-2.3, 0, 2.025}, {-2.3, -0.3,
2.025}, {-2.5, -0.3, 2.25}, {-2.5, 0, 2.25}, {-2.7, 0,
2.025}, {-2.7, -0.3, 2.025}, {-3, -0.3, 2.25}, {-3, 0,
2.25}, {-2.7, 0, 1.8}, {-2.7, -0.3, 1.8}, {-3, -0.3, 1.8},
{-3, 0, 1.8}, {-2.7, 0, 1.575}, {-2.7, -0.3, 1.575}, {-3,
-0.3, 1.35}, {-3, 0, 1.35}, {-2.5, 0, 1.125}, {-2.5, -0.3,
1.125}, {-2.65, -0.3, 0.9375}, {-2.65, 0, 0.9375}, {-2,
-0.3, 0.9}, {-1.9, -0.3, 0.6}, {-1.9, 0, 0.6}, {1.7, 0,
1.425}, {1.7, -0.66, 1.425}, {1.7, -0.66, 0.6}, {1.7, 0,
0.6}, {2.6, 0, 1.425}, {2.6, -0.66, 1.425}, {3.1, -0.66,
0.825}, {3.1, 0, 0.825}, {2.3, 0, 2.1}, {2.3, -0.25, 2.1},
{2.4, -0.25, 2.025}, {2.4, 0, 2.025}, {2.7, 0, 2.4}, {2.7,
-0.25, 2.4}, {3.3, -0.25, 2.4}, {3.3, 0, 2.4}, {2.8, 0,
2.475}, {2.8, -0.25, 2.475}, {3.525, -0.25, 2.49375},
{3.525, 0, 2.49375}, {2.9, 0, 2.475}, {2.9, -0.15, 2.475},
{3.45, -0.15, 2.5125}, {3.45, 0, 2.5125}, {2.8, 0, 2.4},
{2.8, -0.15, 2.4}, {3.2, -0.15, 2.4}, {3.2, 0, 2.4}, {0, 0,
3.15}, {0.8, 0, 3.15}, {0.8, -0.45, 3.15}, {0.45, -0.8,
3.15}, {0, -0.8, 3.15}, {0, 0, 2.85}, {1.4, 0, 2.4}, {1.4,
-0.784, 2.4}, {0.784, -1.4, 2.4}, {0, -1.4, 2.4}, {0.4, 0,
2.55}, {0.4, -0.224, 2.55}, {0.224, -0.4, 2.55}, {0, -0.4,
2.55}, {1.3, 0, 2.55}, {1.3, -0.728, 2.55}, {0.728, -1.3,
2.55}, {0, -1.3, 2.55}, {1.3, 0, 2.4}, {1.3, -0.728, 2.4},
{0.728, -1.3, 2.4}, {0, -1.3, 2.4}, {0, 0, 0}, {1.425,
-0.798, 0}, {1.5, 0, 0.075}, {1.425, 0, 0}, {0.798, -1.425,
0}, {0, -1.5, 0.075}, {0, -1.425, 0}, {1.5, -0.84, 0.075},
{0.84, -1.5, 0.075}
};

static float tex[2][2][2] =
{
{ {0, 0}, {1, 0} },
{ {0, 1}, {1, 1} }
};

static void teapot( GLint grid, GLdouble scale, GLenum type )
{
float p[4][4][3], q[4][4][3], r[4][4][3], s[4][4][3];
long i, j, k, l;

glPushAttrib( GL_ENABLE_BIT | GL_EVAL_BIT );
glEnable( GL_AUTO_NORMAL );
glEnable( GL_NORMALIZE );
glEnable( GL_MAP2_VERTEX_3 );
glEnable( GL_MAP2_TEXTURE_COORD_2 );

glPushMatrix();
glRotatef(270.0, 1.0, 0.0, 0.0);
glScalef(0.5 * scale, 0.5 * scale, 0.5 * scale);
glTranslatef(0.0, 0.0, -1.5);

for (i = 0; i < 10; i++) {
  for (j = 0; j < 4; j++) {
    for (k = 0; k < 4; k++) {
      for (l = 0; l < 3; l++) {
        p[j][k][l] = cpdata[patchdata[i][j * 4 + k]][l];
        q[j][k][l] = cpdata[patchdata[i][j * 4 + (3 - k)]][l];
        if (l == 1)
          q[j][k][l] *= -1.0;
        if (i < 6) {
          r[j][k][l] =
            cpdata[patchdata[i][j * 4 + (3 - k)]][l];
          if (l == 0)
            r[j][k][l] *= -1.0;
          s[j][k][l] = cpdata[patchdata[i][j * 4 + k]][l];
          if (l == 0)
            s[j][k][l] *= -1.0;
          if (l == 1)
            s[j][k][l] *= -1.0;
        }
      }
    }
  }

  glMap2f(GL_MAP2_TEXTURE_COORD_2, 0, 1, 2, 2, 0, 1, 4, 2,
    &tex[0][0][0]);
  glMap2f(GL_MAP2_VERTEX_3, 0, 1, 3, 4, 0, 1, 12, 4,
    &p[0][0][0]);
  glMapGrid2f(grid, 0.0, 1.0, grid, 0.0, 1.0);
  glEvalMesh2(type, 0, grid, 0, grid);
  glMap2f(GL_MAP2_VERTEX_3, 0, 1, 3, 4, 0, 1, 12, 4,
    &q[0][0][0]);
  glEvalMesh2(type, 0, grid, 0, grid);
  if (i < 6) {
    glMap2f(GL_MAP2_VERTEX_3, 0, 1, 3, 4, 0, 1, 12, 4,
      &r[0][0][0]);
    glEvalMesh2(type, 0, grid, 0, grid);
    glMap2f(GL_MAP2_VERTEX_3, 0, 1, 3, 4, 0, 1, 12, 4,
      &s[0][0][0]);
    glEvalMesh2(type, 0, grid, 0, grid);
  }
}

glPopMatrix();
glPopAttrib();

}

/*

  • Renders a beautiful wired teapot…
    /
    void glutWireTeapot( GLdouble size )
    {
    /
    • We will use the general teapot rendering code
      */
      teapot( 10, size, GL_LINE );
      }

/*

  • Renders a beautiful filled teapot…
    /
    void glutSolidTeapot( GLdouble size )
    {
    /
    • We will use the general teapot rendering code
      */
      teapot( 7, size, GL_FILL );
      }

/*** END OF FILE ***/

  • Andreas
5

Not exactly the responses I hoped for:

Please use a different prefix so it doesn’t conflict with core library
names in the future.

What about: ‘Hey, these functions already have the right prefix.
I’ll just add these two files to the SDL CVS.’

Heheh. Nothing new is going into SDL before the experimental 1.3 branch
is started. At that point we can toss in the kitchen sink and see what
happens.

I still think that these should be in a separate library anyway though. :slight_smile:

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

6

Heheh. Nothing new is going into SDL before the experimental 1.3 branch
is started. At that point we can toss in the kitchen sink and see what
happens.
Will I have to document the dishes?

I still think that these should be in a separate library anyway though. :slight_smile:
Deffo. Andreas, It’ll give you the chance to change your nick,
is much better than <sdl-1.2-cvs-platonics-patch.diff>.
:)On Mon, Mar 19, 2001 at 09:37:46AM -0800, Sam Lantinga wrote:

–
Martin

Bother! said Pooh joining AOLers. 1"M NOW TYP1NG KEWL STUFF//!!!

7

No, formal documenation won’t happen until the new API stabilizes,
which won’t be for at least six months.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software> On Mon, Mar 19, 2001 at 09:37:46AM -0800, Sam Lantinga wrote:

Heheh. Nothing new is going into SDL before the experimental 1.3 branch
is started. At that point we can toss in the kitchen sink and see what
happens.
Will I have to document the dishes?

8

Bother! said Pooh joining AOLers. 1"M NOW TYP1NG KEWL STUFF//!!!

This tagline must have been written by someone with a keyboard layout
other than a US one where the ‘!’ is a shifted ‘/’ whereas it’s ‘?’ on a
US keyboard.

My current problem with SDL is that I need to translate keystrokes from
the base enumeration and the modifier key states (esp. shift) into
keyboard characters which vary depending on keyboard layout.

I’m hoping that there’s an easy way to get the character that someone
intended when they pressed Shift-something and I just overlooked it in the
docs.

Otherwise I’ll have to write my own code to do this (I already have it,
technically but it’s hardcoded for a US layout), possibly borrowing
Linux’s key map definitions.

Has anyone done something similar already, perhaps?

Greg V. (hmaon)

    "It's today!" said Piglet.
"My favorite day," said Pooh.
9

My current problem with SDL is that I need to translate keystrokes from
the base enumeration and the modifier key states (esp. shift) into
keyboard characters which vary depending on keyboard layout.

I’m hoping that there’s an easy way to get the character that someone
intended when they pressed Shift-something and I just overlooked it in the
docs.

Have you looked at the unicode value in the keysym structure?
You need to call SDL_EnableUNICODE(1) before this is meaningful, but it
should be exactly what you want.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

10

“Greg Velichansky” wrote

I’m hoping that there’s an easy way to get the character that someone
intended when they pressed Shift-something and I just overlooked it in the
docs.

you are in luck greg. in SDL you can enable 'unicode translations’
which will fill in a correctly mapped unicode character for all
SDL_KEYDOWN events.

http://www.libsdl.org/docs/sdlenableunicode.html

11

I’m hoping that there’s an easy way to get the character that someone
intended when they pressed Shift-something and I just overlooked it in the
docs.

Have you looked at the unicode value in the keysym structure?
You need to call SDL_EnableUNICODE(1) before this is meaningful, but it
should be exactly what you want.

Aha, I knew there must have been something! Thanks, I’ll try it. :slight_smile:

BTW, there is a windows build of a preliminary merging of Iso-Pernangband
with the SDL Angband display module.

Get it here:
http://212.187.33.55/~simutrans/iso_angband/download.html

Sorry, it will only work properly with a US keyboard. :wink:

gregOn Mon, 19 Mar 2001, Sam Lantinga wrote:

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

12

And SDL/docs/html/guideinputkeyboard.html or
http://sdldoc.csn.ul.ie/guideinputkeyboard.html in the latest docs.On Mon, Mar 19, 2001 at 02:10:31PM -0800, Pete Shinners wrote:

“Greg Velichansky” wrote

I’m hoping that there’s an easy way to get the character that someone
intended when they pressed Shift-something and I just overlooked it in the
docs.

you are in luck greg. in SDL you can enable 'unicode translations’
which will fill in a correctly mapped unicode character for all
SDL_KEYDOWN events.

http://www.libsdl.org/docs/sdlenableunicode.html

–
Martin

Bother! said Pooh, when he mixed up the Ben-Gay and the K-Y Jelly.

13

Sam Lantinga schrieb am 19 Mar 2001:> > On Mon, Mar 19, 2001 at 09:37:46AM -0800, Sam Lantinga wrote:

Heheh. Nothing new is going into SDL before the experimental 1.3 branch
is started. At that point we can toss in the kitchen sink and see what
happens.
Will I have to document the dishes?

No, formal documenation won’t happen until the new API stabilizes,
which won’t be for at least six months.

I seriously hope that we’ll backport the important new stuff to 1.2
from time to time then. Otherwise it will go the way of 1.0, quickly
being obsolete and ignored by developers (who want/need the features in
1.3).

  • Andreas
    –
    Check out my 3D lightcycle game: http://www.gltron.org
    More than 100’000 Downloads of the last version (0.59)
14

I seriously hope that we’ll backport the important new stuff to 1.2
from time to time then. Otherwise it will go the way of 1.0, quickly
being obsolete and ignored by developers (who want/need the features in
1.3).

that’s probably a good idea, but some new things may be hard to
backport if they depend on a new design. On the other hand 1.2 should
be considerably more useful than 1.0 was and will be useful for quite
some time

15

I seriously hope that we’ll backport the important new stuff to 1.2
from time to time then. Otherwise it will go the way of 1.0, quickly
being obsolete and ignored by developers (who want/need the features in
1.3).

that’s probably a good idea, but some new things may be hard to
backport if they depend on a new design. On the other hand 1.2 should
be considerably more useful than 1.0 was and will be useful for quite
some time

Also, the timeframe for a usable 1.3 release is on the order of 3-6 months
at the earliest. I want to take the time to learn from what we’ve done
over the past four years and design it right. It will be a precursor to
SDL 2.0

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

16

Sam Lantinga writes:

I seriously hope that we’ll backport the important new stuff to 1.2
from time to time then. Otherwise it will go the way of 1.0, quickly
being obsolete and ignored by developers (who want/need the features in
1.3).

that’s probably a good idea, but some new things may be hard to
backport if they depend on a new design. On the other hand 1.2 should
be considerably more useful than 1.0 was and will be useful for quite
some time

Also, the timeframe for a usable 1.3 release is on the order of 3-6 months
at the earliest. I want to take the time to learn from what we’ve done
over the past four years and design it right. It will be a precursor to
SDL 2.0

Is there any plans for native C++ support in the future of SDL, as
opposed to depending on 3rd party wrapper libs? I haven’t followed the
discussions here for quite some time (5000 unread :-), so excuse me if
this has already been discussed.

Is there a roadmap for the future development of SDL somewhere?–
[ Below is a random fortune, which is unrelated to the above message. ]
Doing gets it done.

17

Is there any plans for native C++ support in the future of SDL, as
opposed to depending on 3rd party wrapper libs?

No, I plan to keep the API C-only, as it eases multi-language bindings.
Also, people have very different styles of C++, and what’s useful for
one person or project may be completely useless for another.

Is there a roadmap for the future development of SDL somewhere?

Hmm, only in the TODO file, my head, and the mailing list archives.
More will be coming this summer.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

18

Sam Lantinga writes:

Is there any plans for native C++ support in the future of SDL, as
opposed to depending on 3rd party wrapper libs?

No, I plan to keep the API C-only, as it eases multi-language bindings.
Also, people have very different styles of C++, and what’s useful for
one person or project may be completely useless for another.

Well, I certainly never suggested dropping the C API. I think it would
be nice with an offical SDL++ however. I.e when you build and install
SDL, you get a library (perhaps named SDL++) that features all the SDL
calls of the current version using a C++ interface.

Is there a roadmap for the future development of SDL somewhere?

Hmm, only in the TODO file, my head, and the mailing list archives.
More will be coming this summer.

Ok!–
[ Below is a random fortune, which is unrelated to the above message. ]
Your code should be more efficient!