I think that you can use W3D_VFORMAT_PACK_COLOR but not W3D_VFORMAT_PACK_SCOLOR that is broken from my own Microbe3D's experiments
So something like this is correct
UBYTE RGBA[4];
float RGBA2[4];


Also in MGLvertex some fields may be packed more like
GLuint frame_code;
GLuint tex_frame_code;
GLuint outcode;
GLboolean rhw_valid[MAX_TEXTURE_UNITS];
GLboolean inview;

GLboolean may be changed to UBYTE (or even one bit)
frame_code & tex_frame_code may use UWORD (but then need to adjust the same vars that are in context) as those var are only checked this way if(V->frame_code!=context->framecode) then v_not_up_to_date

outcode may be UWORD too

Alain

MGL_Vertex use 224 bytes

Cow3D on Sam440 reach 38 fps or 41 fps with bufferized animation
Cow3D is 5813 triangles so 5813*3 vertices to draw 41 times per second so 715 000 vertices/second
We can say that it is the max speed limit for the Sam440 as Cow3D is a very simple program

So doing the same with the big MGL_Vertex structure will need 160 MB/sec

Alain

OK my sources + binaries are here
http://thellier.free.fr/src-02-jul-2015.zip
No changes in src/glu
23 files modified in src/ mostly just for fixing warnings in fact only hclip.c light.c texture.c and especially draw.c
were truly modified
include/mgl/context.h modified too

bug in draw.c/DrawStoredLines() still here : i give up

Alain Thellier

@BSzili
>accumulating the clipped primitives into the vertex buffer, instead of drawing them one by one
This is what I did too : It dont seems to have enhanced the speed (at least on Ioquake....)

When the "glexcess lines bug" will be fixed (when I will have some courage) then I will release this sources+binary


Alain Thellier

I am using AllocVecTags() + MEMF_Private almost everywhere and MEMF_Shared only where needed

The chip is needed here in video.c

static void vid_Pointer(GLcontext context, struct Window *window)
{
if (!context->MousePointer) {
context->MousePointer = IExec->AllocVec(12, MEMF_CLEAR|MEMF_CHIP); /* still use deprecated AllocVec to obtain chip on real classic Amigas */
}
if (window) {
IIntuition->SetPointer(window, context->MousePointer, 1, 16, 0, 0);
}
}

I am using AllocVecTags() + MEMF_Private almost everywhere and MEMF_Shared only where needed

The chip is needed here in video.c

static void vid_Pointer(GLcontext context, struct Window *window)
{
if (!context->MousePointer) {
context->MousePointer = IExec->AllocVec(12, MEMF_CLEAR|MEMF_CHIP); /* still use deprecated AllocVec to obtain chip on real classic Amigas */
}
if (window) {
IIntuition->SetPointer(window, context->MousePointer, 1, 16, 0, 0);
}
}

Hello

Last month I have tried to recompile latest MiniGL to optimize it
So I have a Cygwin based cross compiler
1) I have fixed all "deprecated" warnings about MsgPort,etc.. in gl & glut sources
2) I have fixed all "deprecated" warnings about AllocVec in gl & glut sources
So no more "deprecated" warnings on glut & minigl sources (except an allocvec for chip memory that cant be removed)
==> clean compilation on gl & glut
(I didnt checked glu sources because glu is not so important)
3) tried to rewrite the "transform" part to use registers ==> but it dont speed up Huno's Ioquake
4) Apply the functions transform,CodePoints(clip test),LightVertices,VerticesToScreen to the whole primtive not on a per triangle basis
5) rewrote all the "Draw a primitive" functions in draw.c to make them bufferize the non clipped triangles (or points or lines) so allowing to draw a (clipped) primitive in a single pass
==> but it dont speed up Huno's Ioquake
6) Test if primitive not clipped (fully on screen)then draw it immediatly
==> but it dont speed up Huno's Ioquake
7) I have also tried to fully remove the "lighting" (ie vertex is simply colored with white) ==> almost dont speed up Huno's Ioquake ===> So the "lighting" almost have no influence on this program

All that changes have introduced new errors : so now Glexcess crash on lines drawings = certainly ane easy bug but I am too tired to look after
Hopefully Ioquake, that serve as test, still run perfectly but at almost the same speed (even a few slower)

Now I am very tired : those who says "MiniGL can be easily faster" are wrong : I have spend a lot of time on this for zero progress

Alain Thellier - Wazp3D

I dont know : you should better ask directly hans de ruiter or post the changelog
Perhaps a problem related to bus bandwidth or vertices format too big?

Alain Thellier

OK thanks

Here it is my own test that I use to benchmark Microbe3D versions on differents hardware or emulators

1) Install Microbe3D
2) Start Demo-View_ppc (It is a 3d object viewer) not demo_view (68k version that works too with petunia)
3) Menu Scene/Read Object
load partygirl/partygirl.obj (NOT partygirl.bon)
Dont move this object (key 'j' can restore default position)
4) Menu Test & Debug/ FPS Limit:OFF
Else the FPS speed is limited aroun 10 fps

You obtain on the first line
current FPS for current frame (example: 19 fps)
average FPS on 50 frames (example: 20 fps)
average Time Per Frame (TPF) as milliseconds (example: 50 ms)

You can also start a full benchmark test :
Menu Test & Debug/ Time Tests
It is veeerrryyy long but very accurate
Touch nothing during tests


Alain Thellier

@Kimmok
Yes Cow3D is extremely simple it almost not use the cpu (only to rotate the vertices) so you almost only benchmark the Warp3D-drawing-speed (and the graphic bus) with this program.

With Cow3D when you hit 'b' the full animation (the cow 360° turn) is bufferized so the cpu is no more used for the rotation
But for the faster cpus it dont make much differences anyway

Alain Thellier

Hello all

If you are tired of using my infamous Cow3D then you can also use/test my Microbe3D/demo-view-ppc with some of the animated babes joined in the package ;-P
https://www.youtube.com/user/wazp3d

http://aminet.net/package/util/libs/Microbe3D

Alain Thellier

(Just answering for myself for archive)

INSTALLING AN OS4 CROSS COMPILER ON CYGWIN
Cygwin is a pseudo Linux environnement on Windows (kinda GeekGadgets for Windows)
So you can manipulate files the Cygwin side but also the Windows side
You can paste/copy a command to Cygwin Shell no need to type manually
You can use a Windows editor like "Scite" to edit easily your code
You can have WinUAE-ppc installed the Windows side
So this seems a good solution for coding/testing AmigaNG programs

1) Just install cygwin
https://www.cygwin.com/install.html
Run setup-x86.exe

2) Think to check the "make" package to install it too (not done as default)
If you forgot to install "make" then you can add it easily to your current Cygwin install just by running the setup tool again

3) Also the cross-compiler need particular versions of libmp & libgmp
I have installed them like "make" but the needed versions werent the same
So I renamed them to obtain that in /bin/
cyggmp-10.dll
cyggmp-3.dll
cygmpfr-1.dll
cygmpfr-4.dll

4) download the AmigaNG cross compilers and tools
http://kas1e.mikendezign.com/zerohero ... aos-binutils-2.18.tar.bz2
http://kas1e.mikendezign.com/zerohero ... amigaos-gcc-4.4.3.tar.bz2
copy them to /usr/local in the cygwin directory

5) start cygwin
copy/paste in the shell-prompt those commands :
cd /usr/local
tar jxf binutils-2.18.tar.bz2
tar jxf ppc-amigaos-gcc-4.4.3.tar.bz2

6) create the directory SDK to obtain that :
/usr/local/amiga/ppc-amigaos/SDK

7) cygwin side
copy/paste in the shell-prompt this command :
ln -s /usr/local/amiga/ppc-amigaos/SDK /SDK

8) The Windows side edit Cygwin/home/yourlogin/.bashrc and add the line
export PATH=/usr/local/amiga/bin:$PATH

9) From a real AmigaNG (or WinUAE-ppc) that have the SDK installed : make an archive with the following directories (including contents)
/SDK/clib2
/SDK/newlib
/SDK/include
/SDK/local
Windows side just extract the archive in /usr/local/amiga/ppc-amigaos/SDK

Et Voilà

10) Transfering your prog in WinUAE
For transferring my progs "inside" WinUAE-ppc I use this solution
2 hardfiles :
OS41FE:(Accelerator board scsi)
WORK: (Ide)

2 WinUAE configurations :
1) "OS41" this config boot on os41FE: with Work:
2) "Transfer" this config boot on workbench3.adf with Work: and a PC directory as TEMP: so can copy from TEMP:(pc) to WORK:(Amiga)


Alain Thellier

Hello
@all
Thanks for helping

>1) An archive of zerohero's cross-compiling ..
>http://kas1e.mikendezign.com/zerohero ... p/cross-compiler_os4.html
OK I installed it on cygwin
but "make" is not installed
Should I install a simple cygwin "make" or a special cross-amiga one ? how ?

Alain Thellier

Ok thanks Karlos
Ok I see : GCC is 4.2.4 here
Do you mean that it is YOUR MiniGL version that is in OS41FE ?

Could you indicate me some documentation about "howto install a cross compiler environment from linux for Amiga"

Thanks for your help

Alain Thellier

Edit: It is MiniGL

Hello

I have recompiled the minigl sources with the given makefile but I dont obtain the same performance on quake3 time demo
= it is now slower than original minigl

So 2 possible causes
* original was maded with a better compiler
* original use differents (and better) sources

So where are those sources ...

Alain Thellier

Hello

I am searching a small program for testing my minigl.library build INSIDE WINUAE-PPC game,demos,whatever...
So the prog :
* must be small
* must not use much memory
* must really use minigl.library not minigl.a
* must really use minigl.library not directly Warp3D
* must not need game data or other exotic dependancies...

Alain Thellier

Note: in this WinUAE-ppc the 3D is rendered via WaZp3D's soft-renderer so slooow but not a problem for my tests

@BSzili

You can also analyze MiniGL behaviour with Wazp3D as it can output (debug) all the Warp3D calls & parameters

Typically you can full-debug a single display frame (from says Quake) to a file then begin to analyze it

Some stuffs that may need improvements :
(dont have checked the sources myself yet....)

- Lighting optim
- Clipping optim
- Vertices format (size of the struct used) = bandwiths problems occurs when drawing 250 000 triangles secondes if vertices format is too big
- bufferize triangles from several drawing operations (including new triangles created with the clipper)
- "State tracker" = dont set again a Warp3D states when not truly modified since last drawing
Often things like that happen in 3D progs

setstate x to default
setstate x to value y
draw n tris
setstate x to default
setstate x to value y
draw m tris

But it should be like that

setstate x to value y
draw (n+m) tris

Alain Thellier - Wazp3D

@zzd10h
>Yes, I tested it, Bears or all your others animated objects work fine. (RxMicrobe3D too)
Many thanks again Guillaume

Alain

PS: For those who dont know Microbe3D available on Aminet :
https://www.youtube.com/user/wazp3d

Hello

There is nothing complicated with cow3D just need a directory with

Cow3D-Amiga-ppc
Cow_256X256X32.RAW
Cosmos_256X256X32.RAW

and it should run

Also your workbench must be in a Warp3D compatible screen mode like ARGB 32 bits or RGB 24 bits for example

Alain Thellier

@Zzd10h

I agree with Hans for quake :it use much the cpu
for cow3d only the bus speed may explain the differences

Alain