# Aros/Developer/SDL

* Navbar for the Aros wikibook
* Aros User
* Aros User Docs
* Aros User FAQs
* Aros User Applications
* Aros User DOS Shell
* Aros/User/AmigaLegacy
* Aros Dev Docs
* Aros Developer Docs
* Porting Software from AmigaOS/SDL
* For Zune Beginners
* Zune .MUI Classes
* For SDL Beginners
* Aros Developer BuildSystem
* Specific platforms
* Aros x86 Complete System HCL
* Aros x86 Audio/Video Support
* Aros x86 Network Support
* Aros Intel AMD x86 Installing
* Aros Storage Support IDE SATA etc
* Aros Poseidon USB Support
* x86-64 Support
* Motorola 68k Amiga Support
* Linux and FreeBSD Support
* Windows Mingw and MacOSX Support
* Android Support
* Arm Raspberry Pi Support
* PPC Power Architecture
* misc
* Aros Public License

## Introduction

Many SDL games work by polling (ie reading all the time) the event queue.
https://wiki.libsdl.org/SDL_PollEvent
The example code shows the ugly. while(1) { SDL_PollEvent(...); }
It kills any CPU class.
Better main loop would be with SDL_WaitEvent/SDL_WaitEventTimeout
https://wiki.libsdl.org/SDL_WaitEvent https://wiki.libsdl.org/SDL_WaitEventTimeout
At least, those calls shouldn't eat all the CPU.

### Game Routines

If SDL failed

### References

Comprehensive Tutorials
SDL OpenGL and LUA
Tutorials
C++ Tutorial
Alpha Blending
Tutorials
2D Engine
SDL audio input examples
Programming Forum
Stepped Tutorials Tetris,
SDL uses event-based input. All SDL apps are handling events by themselves. Therefore, every SDL app starts a busy loop on AROS, using as much of CPU time as possible. It seems also that the SDL software is badly written and most of the code uses event pooling (instead of waiting for events) and small delays, like here. It also seems, many programmers do not care at all if a SDL game consumes 100% of cpu time even in idle state.
Colors in SDL are usually stored in Uint32 variables. This type (and others) is defined by SDL so that you can be sure that you get exactly 32 bits on every different platform/OS, rather than the ambiguous 'unsigned int'. On a 32-bit surface, each color component gets 8 bits. If I write a hexidecimal constant like so: 0x50a600ff, and the pixel format is ARGB, then my components would be alpha = 0x50 (80), red = 0xa6 (166), green = 0x00 (0), and blue = 0xff (255). There you can see that color components range from 0 to 255 (256 values). These components can each be stored in Uint8 variables.
SDL uses the standard coordinate axes for computer graphics. The point (0, 0) is in the upper left-hand corner of the screen. The x coordinate increases to the right, and the y coordinate increases downward. This does have a small side-effect that the coordinate system is left-handed (angles are measured clockwise).
It pays to wrap certain things in your own functions. For example, you can write a function that draws an image to the screen, taking just the surface pointer and coordinates. Found it very easy to wrap both keyboard and joystick handling into one function, so my game accepts either input method for a particular player and the code to use it is nice and clean.

## openGL

OLD STYLE OpenGL 1.1 - Immediate mode: glBegin, glEnd, glVertex etc
NEW STYLE OpenGL2 3 4 - Vertex Arrays

### OpenGL 2, 3 and 4 - Shaders and co

glColor - Even if often used with immediate mode, this is ok for setting a constant color for further vertices to draw.
glNormal, glTexCoord - As with glColor, although it's quite rare to set these to a constant value.
glTranslate, glLoadMatrix, glMultMatrix etc. - These are the way to do transformations.
glMatrixMode - Used to change which matrix to apply changes to. Don't do glFrustum, glOrtho, gluPerspective or similar each frame (unless its arguments change). In most cases,this belongs to your reshape function.
glEnableClientState, glVertexPointer (and equivalent for normals, texcoords, color), glDrawArrays, glDrawElements - While deprecated, the "idea" is generally the same (but used functions different) with modern OpenGL. Give OpenGL a pointer to elements, which it will draw. Of course you want to use VBO (upload the data to graphics ram) when possible. You can do this with few #ifdef's if you want to compile your code also for platforms that already support it.
GL_POINTS, GL_LINES, GL_LINE_STRIP, GL_TRIANGLES, GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN - These are still around in every OpenGL (or OpenGL ES) implementation. Use freely.
NOTE: all previous functionality (except immediate mode) works with OpenGL ES1. OpenGL ES2 uses shaders extensively, and it's not possible to write code that works both on TinyGL or OpenGL1 and OpenGL ES2 without using lots of #ifdefs or similar, assuming you do something more complex than clear the screen with the specified color.
GL_QUADS, GL_QUAD_STRIP, GL_POLYGON - AVOID. Deprecated, and missing from both OpenGL ES1 and ES2. Use indexed GL_TRIANGLES or GL_TRIANGLE_STRIP instead.
http://www.amigacoding.de/index.php?topic=456.0
http://www.amigacoding.de/index.php?topic=494.0
VBOs (Vertx Buffer Objects) with texture atlases (create one big texture with all your textures in it uing Texture Arrays) - use multiple VBOs, one for each texture atlas -
shaders
use the OpenGL state machine more optimally. Switching between shaders and textures are often more expensive than actual draw calls, so one has to design the code in such a way that this switching is minimised, e.g. perform all the draw calls that need a specific shader and texture before switching to another shader and/or texture.
http://forum.unity3d.com/threads/63149-After-playing-minecraft...
lighting
shadows
reflections
bump/parallax mapping

### OpenGL 1 - old

AVIOD below