DESCRIPTION
===========
StormMesa is a 68020-40 OpenGL implementation that use hardware Warp3D
So programs like glExcess,Cube,etc... may be hardware rendered in WinUAE/Wazp3D or on real Amiga/Warp3D
Now works also on OS4 as a 68k program
New in v2.5: if LibBase in A6 is lost then try to find it again with GetTaskLibBase();
New in v2.4: StormMesa2010-Prefs is now OS-friendly
New in v2.3: Mipmapping is fixed (was crashing in Cube). Default setting is LOCKMODE2 + VERYFAST so faster
New in v2.2: Option "Use DrawArrray"
StormMesa2010 2.1b reworked sources :
This was an attempt to recompile the old StormMesa with GCC
This was very difficult and we are not sure that this version is better or usefull...
Sources changes & testing : Alain THELLIER - 'Wawa' TOKARSKI - Bernd ROESCH - 'Kas1e' - Matt HEY - Philippe BOVIER
This is juste an update so see old StormMesa archives for more informations
LICENSE
=======
StormMESA V3.1
A freeware (GNU) 3D graphics library for 68K AMIGA's
Almost completely OpenGL compatible
Based on MESA V3.0 beta 8 by Brian Paul
Based on AMESA V1.6 by Stefan Zivkovic
StormMESA V3.0 is presented by HAAGE & PARTNER Computer Gmbh
StormMESA V3.0 implementation maintained by Sam Jordan - 10.12.98
MOST IMPORTANT FEATURES
=======================
o Now StormMesa sources can be recompiled with a standard GCC
o Old StormMesa binary compatibility
o Perhaps will works better now for some Warp3D-drivers
INSTALLATION
============
copy agl.library TO LIBS:agl.library
STORMMESA 2010 SPECIFICITY
==========================
We describe here how StormMesa sources were modified to be recompiled
1) MultiBase library
StormMesa never give the current GLcontext as a parameter
In fact there is a GLcontext per GL task
But Amiga libraries only know the LibraryBase in a6
So we need to have a new LibraryBase for each new task
Each LibraryBase contain a current GLcontext and a current Task
It give a LibraryBase chained list
So for a given task we obtain a given LibraryBase that contain the current GLcontext
MyTask = FindTask(NULL);
ThisBase=FirstBase;
while(ThisBase!=NULL)
{
if(ThisBase->Task==MyTask)
return(ThisBase);
ThisBase=ThisBase->ChildBase;
}
When OpenGL is started the current GLcontext is stored in the current LibraryBase
So when a library function is called
void glPointSize( GLfloat size )
{
GET_CONTEXT;
PointSize(CC,size);
}
The GET_CONTEXT macro recover the current GLcontext
It do LibraryBase=a6; then CC=LibraryBase->CurrentContext;
2) Standardized glue-functions
We removed all the compiler specific part inside the glue-functions in glapi.c
So we defined registers like this
#define FP0(var) register var __asm("fp0")
and the glue functions like this one
void smglPointSize(GLfloat a)
{
FP0(GLfloat size);
glPointSize(size);
}
That give
void smglPointSize(GLfloat a)
{
register size __asm("fp0")
glPointSize(size);
}
So the "a" parameter is only a dummy one that allow the compiler to check the arguments
and the real parameter "size" is directly read in the register fp0 in the Amiga way
3) StormMesa-Prefs
No more env/vars
Now there is a Gui to change the StormMesa settings
GCC OPTIONS FOR RECOMPILATION
=============================
We describe here the parameters to recompile the agl.library
CODEGEN = -m68020-40 -m68881 -noixemul
OPTIMIZATION = -O3
OPTIONS = -nostartfiles -w -DTHREADS -DAMIGA -DNOASM_68K -DNOASM_PPC -DDRIVEREXT
Warning: Most of those defines are already defined in the .h files
STORMMESA 1999 KNOWN BUGS
=========================
1) a bug in stormesa's glut (found in 4dtris sources & wazp3d debugger) ==> will need a fix
glutInit(&argc, argv);
[...]
glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH);
glutCreateWindow("4D-TRIS");
[...]
glutDisplayFunc(display);
[...]
glEnable(GL_DEPTH_TEST);
static void display(void)
{
[...]
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); [...] }
The "display" call-back function do a clear zbuffer (=depth buffer) but zbuffer is not enabled (yet) = no zbuffer at all
Glut on other OS seems to handle that but StormMesa then try to fallback to software-functions for zbuffer :-(((
Errors in StormMesa or Glut or MiniGL:
2) glExcess : glut dont understand "Game Mode" (=full scren) it begin to start Wazp3D,create context,etc... ==> all works fine (no warp3d error) then glut decide itself (?) to fail and close all =strange Especially strange as StormMesa CAN do full-screen in other demos
3) 4Dtris: it dont use the hardware Zbuffer
We see the error but we dont know yet where it happen in the StormMesa or Glut sources
Seems related to others Zbuffer bugs
It seems that sometime StormMesa lost itself
4) PointBlast: ground should have a texture (?)
5) Oreilly-Cube: often crash at startup
STORMMESA 2010 OTHER KNOWN BUGS
===============================
PointBlast: dont use Zbuffer
STORMMESA PREFS
===============
Four new options in StormMesa2010 :
"Enable Debugger" "Debug Function" "Step Function" "Change Primitive Funcs"
Enable Debugger:
Enables the output of messages. This is used for debugging of OpenGL programs.
(need to close StormMesa-Prefs to make it works)
Debug Function:
Print all the GL functions names
Step Function:
Step before all GL functions
Change Primitive Funcs:
Usually old StormMesa test (query) all the time the hardware and then choose to use
hardware or software for each Primitive Funcs.
Defaut is Off : So StormMesa2010 just test & choose once for all so can be
faster if the hardware can fully render the given program
Use DrawArray
If a GL program want to draw some GL_TRIANGLES then
we use a fast call to W3D_DrawArray(context,W3D_PRIMITIVE_TRIANGLES,0,count);
So can speed up more when using Warp3D (or Wazp3D in hardware mode)
Badly there is not much existing GL programs that use GL_TRIANGLES
You can try it with starship (the gl one not starshipw3d)
Glexcess use draw GL_TRIANGLES only for the spaceship in the tunnel
This option still got bugs so the default is OFF
Other options were env/vars in the old StorMesa
Their old documentation is given again here
DIRECT:
Forces the application to run in 'direct render' mode,
even if the application attempted to run in the
'indirect render' mode. The use of 3D hardware is only
possible in 'direct render' mode.
NOHW:
Forces the graphics to be drawn by the CPU, the 3D
hardware is not touched.
SYNC:
Enforces synchronized refreshing of the graphics in window
mode. Since StormMesa 3.1 no synchronisation is done
by default in window mode.
TRIPLE:
Enables triple buffering. This leads for fast applications
to better performance in fullscreen mode and to a more
constant animation. The disadvantage is the much bigger
video memory usage.
NOCLAMP:
If this option is activated, then 'texture wrapping' is also used,
if the application wants to use 'texture clamping'. This option
should be used when a Virge 3D processor is used, because the
amount of demos capable of running 3D hardware accelerated grows
a lot.
NICETEX:
Cares, that the graphics quality concerning textures is as good as
possible, even if the overall graphics quality was reduced using
the variables FAST and VERYFAST.
NICEFOG:
Cares, that the graphics quality concerning fogging is as good as
possible, even if the overall graphics quality was reduced using
the variables FAST and VERYFAST.
NOHWLINES:
Forbids the use of 3D hardware rendering for line drawing.
LOCKMODE0:
Default. The graphics isn't drawn directly, an 'indirect context' of the
Warp3D software is used. The drawing operations are collected
in a buffer and drawn later, by enclosing such drawing operations
by an lock/unlock call.
This mode is the most system friendly mode and also works for
applications, that call system functions during OpenGL drawing
which might also cause graphical output.
The disadvantage of this mode is the low performance.
LOCKMODE1:
All objects are drawn directly and every begin-end-block is
enclosed by a lock/unlock call. This mode is right now useless,
since it's performance is very low due to massive lock/unlock
call overhead.
LOCKMODE2:
All objects are drawn directly and the lock is held during the
whole display function. This is the fastest mode, but very
system unfriendly, because it freezes the system very much.
LOCKMODE3:
This mode works very similar to mode 2, but here the lock is
broken in periodic intervals to let the system 'breathe air'.
Practice has shown, that the performance usually isn't
noticeable lower than for the mode 2, but the system
friendliness is much better.
FAST:
If this option is activated, the 3D hardware is also used when some
effects aren't supported completely by the hardware. But StormMesa
still tries to achieve an acceptable graphics quality.
VERYFAST:
If this option is activated, the 3D hardware is mostly used, but
the graphics quality might be unacceptable low.
STATS:
Some information is printed out into the shell after completion
of the application. First, the reasons are displayed, which were
responsible for not using the 3D hardware and second, the amount of
drawn primitives (points, lines, triangles, quads) are printed out.
If there is no statistical output after completion of the application,
then some of the mentioned conditions, which are necessary for 3D
hardware support, are not satisfied.
PROFILE:
Not documented
NORASTER:
Not documented
NODITHER:
Not documented
NOZB:
Not documented
NOZBU:
Not documented
LIN:
Not documented
|
aminet net>