# Aros/Developer/OpenGL

* 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

The Amiga's first introduction to hardware enhanced 3D was Warp3D in the 1990s. This was followed by an open source(software based) equivalent called Wazp3D A Wazp3D adaptation to AROS from Matthias Rustler appeared on December 2007.
During 2009 Krzysztof "Deadwood" Smiechowicz ported version 7.5 of MESA 3D to AROS. MESA 3D provides a generic OpenGL implementation. Then he added hardware 3D acceleration capabilities to AROS with his port of Gallium3D for MESA 3D. Then on September 2011 Wazp3D was linked to Mesa 3D for hardware enhanced 3D.
in -> vertex -> fragment -> out
* Framebuffer – alpha, stencil, depth
* Vertex – transform and lighting
* Fragment – texturing, fog,
* Geometry – primitives (dots, lines, polygons triangle/quad), clipping
* Compute -
* Tessellation -
Far better using SDL's 1.2.x GL additions for up to and including OpenGL 2 or consider SDL 1.3 / 2.x for OpenGL 3 and above
* Web GL 1.0 – OpenGL ES 2.0 – OpenGL 2 but complete support in OpenGL 4.1
* Web GL 2.0 – Open GL ES 3.0 – OpenGL 4.3
There is no backwards compatibility from OpenGL 2 to OpenGL 1 as well as OpenGL ES 2 to OpenGL ES 1. But all later OpenGL and ES versions are retrospectively support.
Considered deprecated (ie not advised using or missing/removed)
GL1.1 – OpenGL ES 1 with Fixed Functions – glNormalPointer, glColorPointer and glVertexPointer were introduced. Nearly all of the old ID software are OpenGL 1.1 + extensions
GL1.3 -
GL1.4 – fragment support added
GL1.5 – VBOs added – OpenGL ES 1.1 – added features such as mandatory support for multitexture, better multitexture support (including combiners and dot product texture operations), automatic mipmap generation, vertex buffer objects, state queries, user clip planes, and greater control over point rendering
GL2.0 – OpenGL es 2 – Vertex / Fragment shaders introduced – WebGL minimum – GLSL shading language -
deprecated = glMatrixMode glMult/LoadMatrix glRotate/Translate/Scale glPush/PopMatrix glBegin/End glVertex glTexCoords glLight glMaterial glPush/PopAttrib
GL2.1 – 2006 – last appearance of some matrix functions/stacks – PBOs Pixel buffer objects -
If you want to be able to run on hardware incapable of OpenGL 3.0, then suggest that you not write applications for OpenGL 3.0. Many of the features of 3.0 that can be used on older hardware are backported via extensions. So instead of writing a 3.x application, you could be writing a 2.1 application that is able to use certain extensions. So just code to the GL 2.1 spec instead. You can always research the calls and features that have been since deprecated and just avoid using them in a pure 2.1 program
general method is to have different rendering paths for different features. You detect the version number. If it's one thing, you use one rendering path. If it's lower, you use another. Etc. You can do fine-grained checking by checking for the presence of certain extensions.
Minimum advised starting point for new apps which arrived with Mesa 12 ported to AROS which opened access to the following (hardware support permitting)
Gl3.0 – 2008 – Geometry shaders – Vertex Array Objects (VAOs) ie GL_ARB_vertex_array_object. Older versions need to do more vertex setup work when drawing an object, rather than setting them up once and just binding the VAO. Modern OpenGL enforces you to write your own matrices and pass those manually into shader programs. use programmable function pipelines
GL3.1 – eliminates most of the fixed-function rendering pipeline in favor of a programmable one
GL3.3
GL4.0 – 2010 – Tesselation shaders – Image load/store and atomic counters are probably the biggest ones (this includes shader storage buffers too), though simultaneously the least advertised. Shaders get to write/read from images and buffers directly, though there are a lot of caveats and synchronization issues to understand about doing this. introduces an additional pair of shader stages: one that decides how much to tessellate a primitive, and the other to decide how to generate the new values from the tessellated primitive.
GL4.1 – 2010 – incompatibilities between the desktop version of OpenGL and OpenGL ES 2.0 persisted until OpenGL 4.1, which added the GL_ARB_ES2_compatibility extension. Subroutines are an interesting but often overlooked feature. Basically, you can attach subroutines to shader programs like uniforms. So you could use the same basic program that will run a lighting function, but you can swap lighting functions without changing the program. The basic program would fetch textures, figure out what the diffuse/specular/etc material parameters are, determine the normal and lighting parameters, and pass that to the subroutine. allows you to dynamically piece together different fragments of shaders. You can more or less attach a function to a specific bind point in a program.
GL4.2 – 2011 -
GL4.3 – 2012 – Compute shaders – openGL ES 3 compatibility -
GL4.4
GL4.5

## Compiling
### WARP3D

Recompiling a program that use Warp3D.library is quite simple. You just need to link it to Warp3D
So compiling cow3d for Aros x86 was as simple as gcc -c -O3 CoW3D-3.c -o Cow3D-Aros -lWarp3D
Wazp3D-Prefs is a little tool for selecting how Wazp3D works (fast or nice).
Aros version is included with Aminet/Cow3D (see Wazp3D homepage for documentation) Option "Renderer:Soft to Image" is safer if your Aros system dont support LockBitmapTags else "Renderer:Soft to Bitmap" If your Aros support "Native Graphics Aros" then you can try "Renderer:hard overlay" or "Renderer:hard" but the display is not perfect as Mesa dont support rendering to bitmap as Warp3D
You need to use W3D_DrawTriFan, W3D_DrawTriSttrip or better still, W3D_DrawArray with their corresponding data structures. Suggest the latter since you have much more control over how the vertex data is organised.
You create a triangle strip or a triangle fan. In a strip, alternate triangles share two points along an edge. In a fan, all triangles share one common vertex and adjacent triangles also share an edge. The simplest to illustrate is the strip. A rectangle is simply a 2 triangle strip, something like this:
Using one of the strip drawing methods, the same texture is applied to all polygons in the strip. If you use the old single triangle routines, you have to either enable global texture environment or specify the texture in each polygon separately.
Warp3D is a rasterizer only. That means that it draws primitives in screen space. Strictly, the axes are defined as X=left to right in pixels, Y top to botton in pixels, Z is plane of the screen into the distance. The valid range for Z is 0.0 – 1.0.
You need to calculate your vertices in screen space directly or write your own transformation pipeline.
See Starship3D

### MESA 3D
#### MESA 12

Creating a window in SDL and binding an OpenGL 3.2 context to it uses these steps

#### MESA 7

From client perspective using mesa.library is quite simple:
1) For programs that simply use OpenGL and Glut (like Aminet/starship) then just compile them
gcc starship.c -lglut -lgl – o starshiparos
2) For programs that use OpenGL and Amiga windowing system
* Create a window
* Call AROSMesaCreateContext passing it the window and some other stuff -> you get rendering context in return
* Call AROSMesaMakeCurrent passing it the context so that AROSMesa knows what to render on
* Render some stuff using glXXX functions
* Call AROSMesaSwapBuffers to have the content of render buffer painted onto your window
* Loop to glXXX functions
* Call AROSMesaDestroyContext(context);
* Call CloseWindow(window);
OpenGL API has been changed in ABI V1, just rename 'glA' to 'AROSMesa' The VBO functions are still there, but you need to access them via glaGetProcAddress.
3D Voxel C, 3D Voxel C++, voxel space c, Minecr*ft simple terrain, Voxel C++,,,
TD C++, 2D Tiles Sprite Sheet Game C++, 2D Tile Youtube,,,

## GLSL openGL Shader Language

Shaders are written in the C-like language GLSL which has no pointers and is not object-oriented.
GLSL is tailored for use with graphics and contains useful features specifically targeted at vector and matrix manipulation.

### GLSL 1.0 to 1.2 (OpenGL 2.x)

Shaders always begin with a version declaration, followed by a list of input and output variables, uniforms and its main function. Each shader's entry point is at its main function where we process any input variables and output the results in its output variables.
Each input variable is also known as a vertex attribute. There is a maximum number of vertex attributes we're allowed to declare limited by the hardware. OpenGL guarantees there are always at least 16 4-component vertex attributes available, but some hardware may allow for more which you can retrieve by querying GL_MAX_VERTEX_ATTRIBS:
Types
GLSL has, like any other programming language, data types for specifying what kind of variable we want to work with. GLSL has most of the default basic types we know from languages like C: int, float, double, uint and bool. GLSL also features two container types that we'll be using a lot, namely vectors and matrices.
Vectors
A vector in GLSL is a 2,3 or 4 component container for any of the basic types just mentioned. They can take the following form (n represents the number of components):
* vecn: the default vector of n floats.
* bvecn: a vector of n booleans.
* ivecn: a vector of n integers.
* uvecn: a vector of n unsigned integers.
* dvecn: a vector of n double components.
Most of the time we will be using the basic vecn since floats are sufficient for most of our purposes.
Components of a vector can be accessed via vec.x where x is the first component of the vector. You can use .x, .y, .z and .w to access their first, second, third and fourth component respectively. GLSL also allows you to use rgba for colors or stpq for texture coordinates, accessing the same components.
The vector datatype allows for some interesting and flexible component selection called swizzling. Swizzling allows us to use syntax like this:
You can use any combination of up to 4 letters to create a new vector (of the same type) as long as the original vector has those components; it is not allowed to access the .z component of a vec2 for example. We can also pass vectors as arguments to different vector constructor calls, reducing the number of arguments required:
Vectors are thus a flexible datatype that we can use for all kinds of input and output.
Uniforms are another way to pass data from our application on the CPU to the shaders on the GPU. Uniforms are global so is unique per shader program object, and can be accessed from any shader at any stage in the shader program. Uniforms also will keep their values until they're either reset or updated.
To declare a uniform in GLSL we simply add the uniform keyword to a shader with a type and a name. From that point on we can use the newly declared uniform in the shader.
Vertex - attributes
Vectors - swizzling
Fragment - vectors
Tut,,,
SDL2
snake c++, Snake C++,,
Game starter, Game start,,,
simple c++ platformer,,,
Simple C 3D engine,,,
SDL1
GLSL tut,,,
For a complete list of OpenGL shader functions see the Quick Reference Card. The most useful functions are below
tut, examples,,

### GLSL 1.3 to 1.5 (OpenGL 3.x) GLSL 4.x (OpenGL 4.x)

Some changes occurred with later OpenGL specs compared to OpenGL 2 and so
Want to have inputs and outputs on the individual shaders so that we can move stuff around. GLSL defined the in and out keywords specifically for that purpose. Each shader can specify inputs and outputs using those keywords and wherever an output variable matches with an input variable of the next shader stage they're passed along. The vertex and fragment shader differ

## raylib

Where Raylib lies regarding other systems
* 1st - C, C++ base level
* 2nd - SDL with OpenGL framework, Raylib with OpenGL
* 3rd - Godot engines, Ren'Py, GameMaker, Scratch, Unity, Unreal ect (AROS does not have)
Raylib's history
* 2013 1.0
* 2016 2.0
* 2019 3.0
* 2021 3.7
* 2023 5.0
It is highly inspired by XNA framework and by Borland BGI graphics lib
* Made for games and animations
* Input polled
* every frame starts from fresh empty screen, you are tracking any state entity data per refresh
* nothing happens until EndDrawing is called
Game loop - Quit -> Handle Input -> Update Game -> begin Drawing -> Draw Game -> End Drawing -> to Quit
DrawFPS, SetTargetFPS,
DrawTexturePro (tex2d, src, dest, origin, rot, color)
Camera2d, beginMode2D , EndMode2D, GetworldToScreen2D (pos, camera) for HUD, health etc, GetScreenToWorld2D (pos, camera) what World items clicked,
Animations, your code covers all motions, use time functions GetFrameTime
Animated 3D models supported (skeletal bones animation) (raylib supports several 3d model formats (obj, gltf/glb, iqm, m3d, vox), some formats support must be enabled in raylib/src/config.h file!)
A* (A star) pathfinding,,, Dijkstra, BreadthFirstS and DepthFirstS
2D Physics engines like Box2D, Velocity Raptor, Torque2D, Chipmunk2D,,, Fluids,
3D Physics like Torque6, , ODE, Jolt, , Cu, Vehicle, Physics3D, qu3e, Newton,
module: rcore
module: rshapes
module: rtextures
module: rtext
module: rmodels
module: raudio
structs
colors
module: raymath

### rlgl5.h

Midless 3D Voxel, Simple M*necraft, 3dship,

## Misc

slowdown when running multiple 3d apps: this happens because of the GL semaphore "ping pong" between the tasks which can cause like >10000 task switches (and GL context switches) per second.
Semaphores are evil! It you have two or more tasks (3d apps) competing for sem then they get into ping pong state when a task is preempted while he owns the sem which is very likely. From then on (until a task switch happens while the sem is *not* locked) what will happen is that only one (GL) call can be made by task #1, then task switch to task #2 happens, which also can only make one (GL) call, then task switch to task #1 happens, which can only make one (GL) call, then task switch to task #2 happens, etc.
One solution to prevent this would be to have some GrabGL/UngrabGL (or ObtainGL,ReleaseGL if that sounds better) functions to be used in 3D apps and then enclose big parts of GL rendering function calls with it. GrabGL would lock the GL sem and make sure context is correct. ReleaseGL would unlock the GL sem. Even better would be if GrabGL switched all the GL functions (through function table) to versions which which don't use semlock/contextcheck/semunlock at all.
Loaders may be required to help with different versions needs Lua based loading libraries with extensions, extensions,
Open Scene Graph claims OGL 3.x and 4.x support, but has some kind of weird LGPL based hybrid license. It's C++ based and they consider subclassing to be outside of the scope of the license. The hybrid LGPL-derived license has an exception which allows the shipment of statically linked binaries, so that eliminates one of the major objections to using the LGPL in commercial work.
Ogre has a new 3.3 renderer that seems to be a work in progress. Forum entries seem to indicate that "modern" shader architecture stuff for both OpenGL and DX11 are WIP. MIT license.
G3D has OpenGL 3.3 but only for Windows and OS X. They used to have Linux support but discontinued it due to too many distros to deal with. A recent mailing list post says they want to reinstate the support. BSD license.
ClanLib seems to support 3.3..4.3 but may not build. Zlib license.
Irrlicht claims OpenGL 3.x on their features page. Zlib license.
Cube 2 looks like OpenGL 2.x. Someone's working on something called Tesseract which might have more "dynamic lighting" capabilities, but it's unclear that this means 3.x+. Zlib license.
3D Physics – Qu3e, [ Bullet],
3D Game Engine – List of,
the bare minimum of a "modernized" engine are
Conditional rendering support (if the engine relies on occlusion queries, which many engines do, it should use conditional rendering as much as possible to avoid CPU-GPU sync points)
GPU based skeletal animation (many engines still use CPU side skinning, despite the technology for GPU based animation is there for a decade now)
Instancing support (especially for particles, vegetation and other similar stuff)
Uniform buffer support (remove all glUniform* calls, despite they are still in core, allows also for batching)
Texture array support (use them as much as possible, batch draw commands together)
The most important take away here is to batch. GL 3.x+ provides dozens of different tech to support this, unfortunately they go unused 99% of the time.

### procedural map generation principles

Simple room placement, BSP room placement, BSP interiors, cellular automata, drunkard's walk, mazes, diffusion-limited aggregation, voronoi, wave function collapse wfc (e.g 2D sprite sheets, tiles placed in terrain maps to 3d objects into 3d spaces) with valid path placed beforehand to save backtracking, and prefabs
Symmetry, layering/combining generators, different corridor algorithms, and doors placement
Domain warping with perturb

### isometric grid view

Grid is rotated 45 deg and height reduced 50%
When a character moves in one direction in the isometric system, always moves both on the X and Y axis in the game.
You have to manage the game data as if you were creating a top-down title, and you must then convert all the positions and motion vectors to render the characters and the levels properly
invert matrix

### rhythm

Simple scrolling in C,,,

### breakout clones

3D in C++,,,

### pathfinding

From ,

### metroidvania

Macro Top down design - Overworld - Area - Room
* Overworld, critical points and necessary destinations
* Area,
* Main routes, Landmarks, POI,
* Storyboard and events
* Landscapes and Lore

### Game design document GDD

Concept (marketing hook in order of difficulty) - gamestyle with gamestyle but ...
Similar games - same ... look / feel / genre / scope / target avatar audience
Measurement (Scale) - how the character / enemies interact, like reach, swing, grab, etc
Prototype - ugly grey box version, mock ups, concepts, screenshots, color schemes, logo, fonts, etc
10min demo - vertical slice for funding, getting initial impressions about good bits, poor ideas, missing parts, etc i.e playtesting
Fun like overcoming obstacles challenges, progression (quests logs to do lists) and rewards, sense of wonder
Design Patterns - finite state machines (behaviors through states entities transitions), event bus singleton (manage signals from objects), entity component patterns (building blocks), Behavior Trees, Goal Action Planners, Hierarchical Tasks, Crowd Pathfinding, Collision Awareness, NPC Attacks
Game Play Loop - , extraction, looter shooter,
Mechanics
* Walls, Spikes, , etc
Story - Narrative, storyline,
Shipping
* game jam to limit scope and allow completion within 1 week with clean code
* then expand to 3,4 and 6 month cycles later as you gain experience and knowledge, later 9 or 12 months max to gain experience and stay focused
* Design
* Programming
* Art
* Audio

### Examples in C C++

Languages in 3 Hours,,,
Raylib Pong Video with, Pong Tutorial C++,,
C game template, game premake, Asteroids in C raylib, Catch items in C,,
bullet hell,,,
Puzzle,
, Co-ordinates, ,,
C++ RPG simple, C++ RPG simple, c++ dungeon crawler,,
2D and 3D examples, Stars c++,,,
Car physics rally, pdf,,
Simple AI Maze runner,,,
wfc in c,,