Hello

I am the Wazp3D author and often people ask me the bugs I know in original Warp3D
So iI have maded this list : feel free to add the bugs you know (especially the ones that dont appear for all Warp3D version/driver )

==========================================================================
KNOWN PROBLEMS WITH ORIGINAL WARP3D
Alain Thellier - 2011
==========================================================================

==========================================================================
ULONG W3D_DrawElements(W3D_Context* context, ULONG primitive, ULONG type, ULONG count,void *indices)
This function dont works for some drivers
==========================================================================
ULONG W3D_DrawLine(W3D_Context *context, W3D_Line *line)
ULONG W3D_DrawLineStrip(W3D_Context *context, W3D_Lines *lines)
ULONG W3D_DrawLineLoop(W3D_Context *context, W3D_Lines *lines)
ULONG W3D_DrawPoint(W3D_Context *context, W3D_Point *point)
some drivers/version dont support linewidth/pointsize != 1.0
some drivers/version dont support blended line/point
some drivers/version dont support textured line/point
==========================================================================
W3D_GetTexFmtInfo()
W3D_QueryDriver()
W3D_Query()
1) Often warp3D return incoherents results when the driver is asked with W3D_QueryDriver/W3D_Query realated to the supported driver->formats
See debug from CoW3D :

W3D_Driver INFERIOR S3 ViRGE> soft:0 ChipID:2 formats:27
So 16+8+2+1 are the supported screen modes
1=clut (so 256 colors)
2=R5G5B5 (32768 colors)
8=R5G5B5PC (32768 colors)
16=B5G5R5PC (32768 colors)

Current bitmap destformat is 128
so R5G6B5PC that is an incompatible format

But Warp3D answer
QueryDriver[x] Query[x] DRAW_POINT for destformat R5G6B5PC
QueryDriver[x] Query[x] DRAW_LINE for destformat R5G6B5PC
QueryDriver[x] Query[x] DRAW_TRIANGLE for destformat R5G6B5PC
Meaning it can do points/lines/triangles in this current 16bits mode but in fact it cant :-/

2) Same for textures and W3D_GetTexFmtInfo()
cow3d use a 24 bits texture so R8G8B8
Hardware Support for texfmt R8G8B8
desfmt CLUT [....][........][....][NO][...]
desfmt R5G5B5 [....][........][....][..][SUP]
desfmt B5G5R5 [....][........][....][..][SUP]
desfmt R5G5B5PC [....][........][....][..][SUP]
desfmt B5G5R5PC [....][........][....][..][SUP]
desfmt R5G6B5 [....][........][....][..][SUP]
desfmt B5G6R5 [....][........][....][..][SUP]
desfmt R5G6B5PC [....][........][....][..][SUP]

So we learn that it can use 16M colors textures on a 256 colors screen = it should be right and is a good information
For a R5G5B5 screen we get [SUP] so a supported texture format (after internal conversion) = coherent
For a R5G6B5PC screen we get [SUP] so a supported texture format but on a screen mode we know that it is not supported =uncoherent
==========================================================================
ULONG W3D_ReadZSpan(W3D_Context *context, ULONG x, ULONG y,ULONG n, W3D_Double *z)
void W3D_WriteZSpan(W3D_Context *context, ULONG x, ULONG y,ULONG n, W3D_Double *z, UBYTE *mask)
ULONG W3D_ReadZPixel(W3D_Context *context, ULONG x, ULONG y,W3D_Double *dz)
void W3D_WriteZPixel(W3D_Context *context, ULONG x, ULONG y,W3D_Double *dz)
Those functions dont works for some drivers
Those functions return a corrupted result on Sam440 = zvalues are not read sequentially
==========================================================================
ULONG W3D_SetBlendMode(context,srcfunc,dstfunc);
Often it return W3D_SUCCESS when it should not
Should return W3D_ILLEGALINPUT for all the modes that cant be used as srcfunc
Should return W3D_ILLEGALINPUT for all the modes that cant be used as dstfunc
Should return W3D_ILLEGALINPUT for all the combinations srcfunc+dstfunc that got no sense or are unsupported

dest only
if(srcfunc==W3D_SRC_COLOR) return(W3D_ILLEGALINPUT);
if(srcfunc==W3D_ONE_MINUS_SRC_COLOR) return(W3D_ILLEGALINPUT);

source only
if(dstfunc==W3D_DST_COLOR) return(W3D_ILLEGALINPUT);
if(dstfunc==W3D_ONE_MINUS_DST_COLOR) return(W3D_ILLEGALINPUT);
if(dstfunc==W3D_SRC_ALPHA_SATURATE) return(W3D_ILLEGALINPUT);

if(WC->SrcFunc==W3D_ZERO)
if(WC->DstFunc==W3D_ZERO)
return(W3D_ILLEGALINPUT);
==========================================================================
W3D_Texture *W3D_AllocTexObj(W3D_Context *context, ULONG *error,struct TagItem *taglist)
W3D_Context *W3D_CreateContext(ULONG *error, struct TagItem *taglist)
StormMesa Problem: error can be NULL if you don`t want an error code returned
==========================================================================
ULONG W3D_QueryDriver(W3D_Driver* driver, ULONG query, ULONG destfmt)
ULONG W3D_GetDriverTexFmtInfo(W3D_Driver* driver, ULONG texfmt, ULONG destfmt)
StormMesa Problem: can send driver=NULL
StormMesa Problem: can send this undocumented destfmt=0 meaning all dest_formats
==========================================================================
void W3D_FreeTexObj(W3D_Context *context, W3D_Texture *texture)
void W3D_ReleaseTexture(W3D_Context *context, W3D_Texture *texture)
ULONG W3D_SetTexEnv(W3D_Context *context, W3D_Texture *texture,ULONG envparam, W3D_Color *envcolor)
StormMesa Problem: use this undocumented NULL value for texture
==========================================================================
ULONG W3D_DrawPoint(W3D_Context *context, W3D_Point *point)
Skulpt Problem: dont set point->pointsize so this value stay at 0 ==> no point
==========================================================================
ULONG W3D_SetBlendMode(W3D_Context *context, ULONG srcfunc, ULONG dstfunc)
BlitzQuake/MiniGL Problem: use SetBlendMode but forget to activate the blending with SetState(context,W3D_BLENDING,TRUE);
==========================================================================
ULONG W3D_DrawArray(W3D_Context* context, ULONG primitive, ULONG base, ULONG count)
ULONG W3D_DrawElements(W3D_Context* context, ULONG primitive, ULONG type, ULONG count,void *indices)
MiniGL Problem: it dont use W3D_VertexPointer & W3D_TexCoordPointer & W3D_ColorPointer
it directly change context->VertexPointer; context->TexCoordPointer[unit]; context->ColorPointer;

MiniGL Problem: it dont use W3D_BindTexture it directly change context->CurrentTex
==========================================================================
ULONG W3D_SetDrawRegion(W3D_Context *context, struct BitMap *bm,int yoffset, W3D_Scissor *scissor)
ULONG W3D_SetDrawRegionWBM(W3D_Context *context, W3D_Bitmap *bm,W3D_Scissor *scissor)

StormMesa Problem: If window is resized then it call W3D_SetDrawRegion
so change the drawregion(=bitmap) dimensions but dont allways change the Zbuffer(size)
==========================================================================
Quake dont set blending for the transparent texs
so I force blending if 32bits tex

if(WC->TexEnvMode==W3D_REPLACE) if tex and no coloring function
if(WC->BlendMode ==BLENDREPLACE) and write flat with src=W3D_ONE + dst=W3D_ZERO
if(Wazp3D->QuakeMatrixPatch.ON)
{
SREM(Quake use own BlendMode )
WC->BlendMode=WT->BlendMode; then use current tex BlendMode (BLENDNOALPHA or BLENDALPHA or BLENDFASTALPHA)
}
==========================================================================
ULONG W3D_SetState(W3D_Context *context, ULONG state, ULONG action)
MiniGL/OS4 forgot to enable zbuffer when setting zbufferupdate
if( state==W3D_ZBUFFERUPDATE)
if(action==W3D_ENABLE)
SetState(context,W3D_ZBUFFER,W3D_ENABLE);
==========================================================================
void W3D_FreeTexObj(W3D_Context *context, W3D_Texture *texture)
driver need to flush all fragments that use this texture before freeing it
==========================================================================
ULONG W3D_SetBlendMode(W3D_Context *context, ULONG srcfunc, ULONG dstfunc)
{

MiniGL/OS4 send some opengl's src & dst unimplemented values
if(srcfunc==GL_CONSTANT_COLOR) srcfunc=W3D_CONSTANT_COLOR;
if(srcfunc==GL_ONE_MINUS_CONSTANT_COLOR) srcfunc=W3D_ONE_MINUS_CONSTANT_COLOR;
if(srcfunc==GL_CONSTANT_ALPHA ) srcfunc=W3D_CONSTANT_ALPHA;
if(srcfunc==GL_ONE_MINUS_CONSTANT_ALPHA) srcfunc=W3D_ONE_MINUS_CONSTANT_ALPHA;

if(dstfunc==GL_CONSTANT_COLOR) dstfunc=W3D_CONSTANT_COLOR;
if(dstfunc==GL_ONE_MINUS_CONSTANT_COLOR) dstfunc=W3D_ONE_MINUS_CONSTANT_COLOR;
if(dstfunc==GL_CONSTANT_ALPHA ) dstfunc=W3D_CONSTANT_ALPHA;
if(dstfunc==GL_ONE_MINUS_CONSTANT_ALPHA) dstfunc=W3D_ONE_MINUS_CONSTANT_ALPHA;

if(15 INFERIOR srcfunc) return(W3D_ILLEGALINPUT);
if(15 INFERIOR dstfunc) return(W3D_ILLEGALINPUT);
They only converted the src/destmodes that existed in Warp3D v4
and forgot that OpenGL can also send some other values.
It is only a "parameter is not converted nor checked" problem

Error is in MiniGL/others.c in cgl_GLBlendFunc() -> It should be like that:

switch(sfactor)
{
BLS(ZERO);
BLS(ONE);
BLS(DST_COLOR);
BLS(ONE_MINUS_DST_COLOR);
BLS(SRC_ALPHA);
BLS(ONE_MINUS_SRC_ALPHA);
BLS(DST_ALPHA);
BLS(ONE_MINUS_DST_ALPHA);
BLS(SRC_ALPHA_SATURATE);
BLS(CONSTANT_COLOR);
BLS(ONE_MINUS_CONSTANT_COLOR);
BLS(CONSTANT_ALPHA );
BLS(ONE_MINUS_CONSTANT_ALPHA);

default:
GLFlagError(context, 1, GL_INVALID_ENUM);
}

switch(dfactor)
{
BLD(ZERO);
BLD(ONE);
BLD(SRC_COLOR);
BLD(ONE_MINUS_SRC_COLOR);
BLD(SRC_ALPHA);
BLD(ONE_MINUS_SRC_ALPHA);
BLD(DST_ALPHA);
BLD(ONE_MINUS_DST_ALPHA);
BLD(CONSTANT_COLOR);
BLD(ONE_MINUS_CONSTANT_COLOR);
BLD(CONSTANT_ALPHA );
BLD(ONE_MINUS_CONSTANT_ALPHA);
default:
GLFlagError(context, 1, GL_INVALID_ENUM);
}

==========================================================================
ULONG W3D_SetBlendMode(W3D_Context *context, ULONG srcfunc, ULONG dstfunc)
BlitzQuake/MiniGL use SetBlendMode but forget to activate with SetState() the blending
if(!CallSetBlending)
SetState(context,W3D_BLENDING,TRUE);

==========================================================================
ULONG W3D_SetZCompareMode(W3D_Context *context, ULONG mode)
{
MiniGL/OS4 forgot to enable zbuffer
if(mode!=W3D_Z_ALWAYS) if truly need a z testing ? then need the zbuffer
if(mode!=W3D_Z_NEVER)
SetState(context,W3D_ZBUFFER,W3D_ENABLE);

==========================================================================
ULONG W3D_ClearBuffers(W3D_Context *context, W3D_Color *color,W3D_Double *depth, ULONG* stencil)
{
QT on OS4 clear the Zbuffer with value z=0.0 : that is stupid
if(depth!=NULL)
if(*depth==0)
{
*depth=0.999;
}
==========================================================================
GlMatrix dont use the good BlendMode

if(Wazp3D->QuakeMatrixPatch.ON) : for glmatrix transparency
if(BlendMode==W3D_ONE_MINUS_SRC_ALPHA*16 + W3D_SRC_ALPHA)
BlendMode=W3D_SRC_ALPHA*16 + W3D_ONE_MINUS_SRC_ALPHA;
==========================================================================
Blender/OS4 use direct mode so it can draw text with graphics.library upside 3d-polygons
In Wazp3D need to finish (=flush) each polygon (=dont keep fragments in the buffer)
void DrawPolyP()
if(Wazp3D->BlenderPatch.ON)
SOFT3D_Flush(SC); patch: For Blender flush buffer = finish this poly so Blender can draw texts upside menus
==========================================================================

Last edited by thellier on 08-Jul-2011 at 09:05 AM.
Last edited by thellier on 08-Jul-2011 at 09:03 AM.
Last edited by thellier on 08-Jul-2011 at 09:00 AM.

@thellier

Quote:

Blender/OS4 use direct mode so it can draw text with graphics.library upside 3d-polygons In Wazp3D need to finish (=flush) each polygon (=dont keep fragments in the buffer) void DrawPolyP() if(Wazp3D->BlenderPatch.ON) SOFT3D_Flush(SC); patch: For Blender flush buffer = finish this poly so Blender can draw texts upside menus ==========================================================================

Can you expand on this one? Blender doesn't explicity use direct mode, only direct mode is supported in OS4 warp3d (if I understand correctly) An I do call glflush before swicthing to graphic lbray text calls.

Last edited by broadblues on 08-Jul-2011 at 09:50 AM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues
OK i explain

Blender to draw a menu
1) draw a panel with Warp3D
2) draw a text with graphics.library (i suppose)
3) draw next panel with Warp3D
4) draw next text with graphics.library (i suppose)
5) etc...

My Wazp3D always works in (a somehow) indirect mode as it bufferize all the fragments (ie pixels) then draw when the buffer is full
So it may happen that the panel is not yet drawn when the text is written

So I maded special patch for os4 (blender) : each time a polygon is drawn i do a flush

>Blender doesn't explicity use direct mode
It should as there is no garantee that a driver with indirect mode will never exists
>only direct mode is supported in OS4 warp3d (if I understand correctly)
OK so we agree there is no problem on OS4/Warp3D
And i maded a patch for OS4/Wazp3D so no problem too
Just keep it in mind if blender is ported on an other Amiga-like

>An I do call glflush before swicthing to graphic libray text calls.
Curious my Wazp3D didnt seen W3D_Flush calls
I suppose MiniGL convert glflush to noop if we are in directmode

Alain

BTW I have uploaded my latest Wazp3D v50 for Os4 as many people search it especiallly those without 3d-drivers & that want to use Blender

http://thellier.free.fr/Warp3D.library-ppc

@thellier

Just for curiosity i try a quick test with the usual WipeOut 2097 and it crash as before (and it's terrible slow with this library but this is normal for now)

Quote:

Crash log for task "Wipeout" Generated by GrimReaper 53.2 Crash occured in module Wipeout at address 0x54269EEC Type of crash: ISI (Instruction Storage Interrupt) exception Register dump: GPR (General Purpose Registers): 0: 000005C8 53BBFB40 549A3008 53BBFDD0 5252A610 53BBFDD0 00000000 0000027F 8: 000001DF 561A7474 5FF48150 53BBFB30 00000004 558A9D90 00000027 00000024 16: 53F002D8 00000026 00000013 54E165E0 5254D050 53B5B6A8 00000002 00000002 24: 00000001 5252A048 00000003 00000020 52B75210 00000025 00000000 00000000 FPR (Floating Point Registers, NaN = Not a Number): 0: nan 256 256 0.951803 4: 0.0243102 -3.43259e-05 1.71551e-05 142.783 8: 204599 4447.8 4.5036e+15 0.950223 12: 0.000154589 0.951306 0.999 0.5 16: 15 256 256 0 20: 0 0 -240 320 24: 0.5 0.5 240 320 28: 0.00392157 1.35808e-312 8.6917e-311 -0.0146484 FPSCR (Floating Point Status and Control Register): 0xA2064100 SPRs (Special Purpose Registers): Machine State (msr) : 0x0002F030 Condition (cr) : 0x88424482 Instruction Pointer (ip) : 0x54269EEC Xtended Exception (xer) : 0x00000002 Count (ctr) : 0x01816334 Link (lr) : 0x5426D840 DSI Status (dsisr) : 0x00000000 Data Address (dar) : 0x57BA7794 680x0 emulated registers: DATA: 00000001 FFFFFFFF 00000001 59785760 00000001 FFD50001 FFD60001 5FD4C174 ADDR: 53BC0F5C 59785760 59785760 5FD4C174 53BC0FFC 53BC0FF0 5588E4D0 53BC0F3C FPU0: 0 0 0 0 FPU4: 0 0 0 0 Symbol info: Instruction pointer 0x54269EEC belongs to module "Wipeout" (HUNK/Kickstart) Stack trace: module Wipeout at 0x54269EEC (section 1 @ 0x85EE4) module Wipeout at 0x5426D840 (section 1 @ 0x89838) module Wipeout at 0x53C76888 (section 17 @ 0xB880) module Wipeout at 0x5429C998 (section 1 @ 0xB8990) module Wipeout at 0x5426F610 (section 1 @ 0x8B608) native kernel module kernel+0x00031f58 native kernel module kernel+0x00022a74 native kernel module kernel+0x00022c24 module LIBS:powerpc.library at 0x6FA7ECF0 (section 5 @ 0x4CD0) module LIBS:powerpc.library at 0x6FA7DF3C (section 5 @ 0x3F1C) native kernel module kernel+0x0005457c native kernel module kernel+0x009bd7f6 PPC disassembly: 54269ee4: d0230028 stfs f1,40(r3) 54269ee8: 4e800020 blr *54269eec: 80c40010 lwz r6,16(r4) 54269ef0: c0640018 lfs f3,24(r4) 54269ef4: 80a60010 lwz r5,16(r6) System information: CPU Model: AMCC PPC440EP V1.3 CPU speed: 799 MHz FSB speed: 133 MHz Extensions: Machine Machine name: Sam440EP Memory: 1048576 KB Extensions: bus.pci

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

I may be able to shed some light on some of these issues, so let's see.

Quote:

thellier wrote: ULONG W3D_DrawElements(W3D_Context* context, ULONG primitive, ULONG type, ULONG count,void *indices) This function dont works for some drivers

This doesn't work at all yet for R200, but it's on my todo list. The Permedia implements this fully including 8/16/32 byte index sizes.

Quote:

some drivers/version dont support linewidth/pointsize != 1.0

This is not a bug per se, but a limitation. The Permedia2, for example, has a hardware line rasterizer based on DDA algorithm with full support for Gouraud, Z buffering and texturing but absolutely no support whatsoever for line width!=1 or pointsize!=1. The Warp3D documentation wasn't very clear about it but arbitrary pointsize/linewidth were only ever for hardware that supported it.

The only way to render 'thick' lines on some chips (P2 included) would be to write an emulation that does it using triangle strips. Likewise, fans could be used to render points larger than 1 pixel. As it happens, I've done some experimentation in this area and to be honest, the triangle rasterizer on the Permedia is significantly faster than the line rasterizer, albeit slightly less accurate. I'm considering it as an option.

Quote:

some drivers/version dont support blended line/point some drivers/version dont support textured line/point

See above. It might actually be better to simply do away with line and point rendering where such limits exist and implement using triangle primitives.

Quote:

So we learn that it can use 16M colors textures on a 256 colors screen = it should be right and is a good information

One thing to be wary of is that 8-bit screens were never properly supported for 3D, but some drivers allow it. AFAIK, 8-bit screenmode support is deprecated since v5 since few chips support it and those that do have many further limitations when using it.

Quote:

ULONG W3D_ReadZSpan(W3D_Context *context, ULONG x, ULONG y,ULONG n, W3D_Double *z) void W3D_WriteZSpan(W3D_Context *context, ULONG x, ULONG y,ULONG n, W3D_Double *z, UBYTE *mask) ULONG W3D_ReadZPixel(W3D_Context *context, ULONG x, ULONG y,W3D_Double *dz) void W3D_WriteZPixel(W3D_Context *context, ULONG x, ULONG y,W3D_Double *dz) Those functions dont works for some drivers Those functions return a corrupted result on Sam440 = zvalues are not read sequentially

Yep, again I think the R200 driver for example has no support for these. A point to note is that one should never assume contents of the Z buffer are going to be valid during rendering unless you've explicitly invoked WaitIdle() first. Score 1 to the Permedia2 driver again ;)

Quote:

W3D_Texture *W3D_AllocTexObj(W3D_Context *context, ULONG *error,struct TagItem *taglist) W3D_Context *W3D_CreateContext(ULONG *error, struct TagItem *taglist) StormMesa Problem: error can be NULL if you don`t want an error code returned

This isn't a bug, it's just not properly documented. In the main library, passing NULL for *error is checked for and is thus safe, if a bit foolish since you'll never know why something didn't work.

Quote:

void W3D_FreeTexObj(W3D_Context *context, W3D_Texture *texture) void W3D_ReleaseTexture(W3D_Context *context, W3D_Texture *texture)

Passing null for the texture is checked for in the main library currently (it wasn't before).

Quote:

ULONG W3D_SetTexEnv(W3D_Context *context, W3D_Texture *texture,ULONG envparam, W3D_Color *envcolor) StormMesa Problem: use this undocumented NULL value for texture

Actually, it can only pass NULL when W3D_GLOBALTEXENV is enabled. In fact, more strictly than that, passing NULL is expected when W3D_GLOBALTEXENV is enabled, since you are setting the global texture environment. Any texture pointer you pass is ignored in that case.

Quote:

ULONG W3D_DrawPoint(W3D_Context *context, W3D_Point *point) Skulpt Problem: dont set point->pointsize so this value stay at 0 ==> no point

See the notes above about hardware-dependencies in support for point and line primitives. For hardware like the P2, the point will be rendered since it only supports single-pixel point primitives.

The rest of the items on the list are pretty much mostly buggy MiniGL and client applications passing nonsense data rather than bugs in Warp3D itself.

Where appropriate, I've added fixes for some of these issues in the main library. For example, it will tolerate the MiniGL enums for blend modes without simply returning an error and attempting to free/release null texture pointers has been guarded against along with attempting to pass invalid vertex array data and so on. I've had no time for a few weeks to work on it at all but I'm hoping to be able to get some stuff done this weekend.

_________________
Doing stupid things for fun...

PS:

W3D_INDIRECT is deprecated and not supported *at all* in the OS4 drivers as far as I can tell since all the code for it in the main library is commented out.

It never actually worked that well anyway, in my experience it was always slower than making optimal use of direct rendering.

_________________
Doing stupid things for fun...

@Karlos

>This is not a bug per se, but a limitation
ah ah you work for microsoft isnt it ? ;-P

>simply do away with line and point rendering where such limits exist and implement using triangle primitives.
have a look to cow3d on Aminet it already contain patched function for doing lines/points
aminet.net/package/dev/src/Cow3D.lha/patches_for_Warp3D.c
feel fre to use them in real Warp3D too

You didnt answered about warp3D that say that it cant use (say) R5G6B5PC in driver->formats and answer differently if asking a texture format on a (say) R5G6B5PC screen
I mean if a screen format is NOT supported in driver->formats then all other w3d calls that test this destfmt must answer "not supported"

>Those functions return a corrupted result on Sam440 = zvalues are not read sequentially
I mean something like
7 6 5 4 2 1 0 15 14 13 12 11 10 9 8 16th zvalue ...
When it should be

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16th zvalue ...
just try cow3d with key g (it read the zbuffer)

>The rest of the items on the list are pretty much mostly buggy MiniGL and client applications passing nonsense data rather than bugs in Warp3D itself.
I agree but badly legacy apps sometime passed nonsense data that worked on tolerant drivers

Many thanks for your works

Alain

@samo79
>i try a quick test with the usual WipeOut 2097
Thanks for your report
Badly it dont help me much as i dont know what is the faulty function

Have you tried this :

1) Start waz3d-prefs and disable "hack RGB/ARG/RGBA texs" then restarts WipeOut 2097

2) Start waz3d-prefs and Set
Enable Debugger
DebugFunction
DebugCalls
DebugState
DebugVar
DebugVal
DebugSOFT3D
DebugError

Then do wipeout > ram:debug.txt
You will obtain a several MB debug file but only the last page will interest me : send this last page to me
If the program crash due to Wazp3D then the faulty function is the last function in debug.txt
But if the last line is Error=W3D_SUCCESS then the crash is not Wazp3D fault and occurs outside Wazp3D.

3) Send me a WipeOut2097 copy so i will debug it myself for sure

Alain

Hi Alain

Ok i download the entire Wazp3D archive and in Libs i put your latest library beta 50 linked above, just set the option you say in Prefs/Wazp3D-Prefs and then start the game from shell

Quote:

Processo: Shell 3 3.AmigaOS4:> AmigaOS4:Giochi/WO2097/ 3.AmigaOS4:Giochi/WO2097> wipeout > Work:debug.txt

I choose "Work:" instead of "RAM:" because if eventual freeze happen i have all saved into another partition

But there are some problem:

WipeOut todat decide to always crash at startup with a DSI, if i ignore it the game start with no problem (along with its stdout shell output running) but i can't be able to go forward after the logo, if i press enter to play the game seems to turn back to the logo !?

Also the debug.txt file will be created correcly in "Work:" but after a close the game session and look at it .. it's seems empty ?!?

Any tips ?

BTW For now you can try the demo on Aminet:

http://aminet.net/package/game/demo/WipeOut_2097_Demo

Last edited by samo79 on 11-Jul-2011 at 03:10 PM.
Last edited by samo79 on 11-Jul-2011 at 02:58 PM.

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@thellier

Quote:

@broadblues OK i explain

Thanks

[/quote]
Blender to draw a menu
1) draw a panel with Warp3D
2) draw a text with graphics.library (i suppose)
3) draw next panel with Warp3D
4) draw next text with graphics.library (i suppose)
5) etc...

My Wazp3D always works in (a somehow) indirect mode as it bufferize all the fragments (ie pixels) then draw when the buffer is full
So it may happen that the panel is not yet drawn when the text is written
[/quote]

OKay I see why that could fail.

Quote:

So I maded special patch for os4 (blender) : each time a polygon is drawn i do a flush

Okay
Quote:

>Blender doesn't explicity use direct mode It should as there is no garantee that a driver with indirect mode will never exists

Ah, but blender does not direct Warp3D stuff it's all down to MiniGL. I think MiiGL assumes OS4 warp3d does no indirect modes.

Quote:

>only direct mode is supported in OS4 warp3d (if I understand correctly) OK so we agree there is no problem on OS4/Warp3D And i maded a patch for OS4/Wazp3D so no problem too Just keep it in mind if blender is ported on an other Amiga-like

How much does you patch affect performance though? As to other amigalikes, I lack the time for porting to them, so it'll be someone elses problem

Quote:

>An I do call glflush before swicthing to graphic libray text calls. Curious my Wazp3D didnt seen W3D_Flush calls I suppose MiniGL convert glflush to noop if we are in directmode

Not quite a Noop it does

void cgl_GLFlush(struct GLContextIFace *Self)
{
        GLcontext context = GET_INSTANCE(Self);

        Self->UnlockDisplay();

 //       if (context->windowed)
                vid_MaybeBlitFrontBuffer(context);
}

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@thellier

[quote]
>Those functions return a corrupted result on Sam440 = zvalues are not read sequentially
I mean something like
7 6 5 4 2 1 0 15 14 13 12 11 10 9 8 16th zvalue ...
When it should be

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16th zvalue ...
[quote]

Z buffer access is definetely broken for radeons. Originally it was "unimplemented" but after dicussion about blenders need for it HJF did a first pass at implementing it, but it didn't work as expected. If it did work I have a patch for MiniGL whch would make use of it.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

I should point out that almost all major library functions are passed straight through to the individual drivers with at most a bit of validation. Most of the main library bugs are simple things. Stuff not rendering (or rendering wrongly) or returning some invalid value from a query is almost always a bug in the hardware-specific driver itself.


Software Z buffer access can be fiddly to implement and isn't used by many applications which is why it's probably been neglected.

There's no guarantee at all that the Z buffer is stored in a manner that is remotely linear (the same is true for textures, which is why W3D_UpdateTexSubImage() so rarely does as it advertises).

At the end of the day, it's all down the the specific hardware requirements and thus the actual driver as to how this data is formatted. Even when it is linear, access to it is going to be abysmally slow since you are reading (for example) 15, 16, 24 or 32 bit values, masking off any stencil bits and then scaling them to doubles before writing them to the target buffer. Writing to the Z buffer is even worse, since you will have to take care to preserve any stencil data, thus read before write.

So, even if/when this is fixed for Radeon, *if* you can implement something without having to hit the Z buffer in software then it is almost certainly going to be faster than doing so.

Last edited by Karlos on 11-Jul-2011 at 09:15 PM.
Last edited by Karlos on 11-Jul-2011 at 09:10 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

At the end of the day, it's all down the the specific hardware requirements and thus the actual driver as to how this data is formatted. Even when it is linear, access to it is going to be abysmally slow since you are reading (for example) 15, 16, 24 or 32 bit values, masking off any stencil bits and then scaling them to doubles before writing them to the target buffer. Writing to the Z buffer is even worse, since you will have to take care to preserve any stencil data, thus read before write.

Add to that MiniGL then needs to convert all values to single floats, and that's why I've never made much more fuss about it.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

broadblues wrote: Ah, but blender does not direct Warp3D stuff it's all down to MiniGL. I think MiiGL assumes OS4 warp3d does no indirect modes.

MiniGL doesn't assume, it sets Warp3D to use direct mode.

Quote:

Quote: >An I do call glflush before swicthing to graphic libray text calls. Curious my Wazp3D didnt seen W3D_Flush calls I suppose MiniGL convert glflush to noop if we are in directmode Not quite a Noop it does void cgl_GLFlush(struct GLContextIFace *Self) { GLcontext context = GET_INSTANCE(Self); Self->UnlockDisplay(); // if (context->windowed) vid_MaybeBlitFrontBuffer(context); } So it waits for hardware to become available, but doesn't call Warp3d->W3D_Flush() I guess as it's a noop under OS4 warp3d it's 'optimised' away. It would seem sensible to add it if suport for wazp3d was considered sensible, for the ineterim where hardwarre drivers are catching up.

If you want to wait for OpenGL to finish rendering something, then you should call glFinish() not glFlush(). GlFlush()'s task is to send the remaining commands to the graphics card, and NOT to wait until it's done. Notice how MiniGL's glFinish() function has a Warp3D wait until idle call?

Unlocking Warp3D should flush any unexecuted commands to the graphics card prior to unlocking. Doing anything else wouldn't make any sense. It just so happens that unlocking the context also waits until the graphics card is done (it would be dangerous to unlock the bitmap before Warp3D is completely done with it.

The code above really should be modified so that if it is in windowed mode, then it waits until Warp3D is idle before calling vid_MaybeBlitFrontBuffer(). Incidentally, if it is in full-screen mode, then glFlush() should probably use Warp3D's flush function instead of unlocking, since any 3D app/game that calls glFlush() a lot while rendering would add a significant amount of context locking and unlocking. Context locking should be minimised due to the overhead incurred.

EDIT: I might try this modification out, and see what happens.

Hans

Last edited by Hans on 12-Jul-2011 at 02:11 AM.
Last edited by Hans on 11-Jul-2011 at 09:35 PM.
Last edited by Hans on 11-Jul-2011 at 09:34 PM.

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@Hans

Quote:

Hans wrote: @broadblues Quote: broadblues wrote: Ah, but blender does not direct Warp3D stuff it's all down to MiniGL. I think MiiGL assumes OS4 warp3d does no indirect modes. MiniGL doesn't assume, it sets Warp3D to use direct mode.

Okay maybe I said that wrong, Given that MiniGL sets direct mode, the code will asume that it is in direct mode, whereas with Wazp3D it appears that it's in indirect mode, that's bound to cause problems. Anyway blender accepts the minigl defaults in respect of direct / indirect mode.


Quote:

If you want to wait for OpenGL to finish rendering something, then you should call glFinish() not glFlush(). GlFlush()'s task is to send the remaining commands to the graphics card, and NOT to wait until it's done. Notice how MiniGL's glFinish() function has a Warp3D wait until idle call? Unlocking Warp3D should flush any unexecuted commands to the graphics card prior to unlocking. Doing anything else wouldn't make any sense. It just so happens that unlocking the context also waits until the graphics card is done (it would be dangerous to unlock the bitmap before Warp3D is completely done with it.

Reviewing my code in more detail, it seem I don't call glFlush or glFinish (at least not at the low level stuff that I wrote, it get used a lot higher up in te main blender code).

I actually call mglUnlockHardware() or IMGL->UnlockHardware() just before starting graphics library rendering. This seems to work fine for Warp3D. But presumably 'unlocking the hardware' doesn't cause a flush of render operation in Wazp3d nor wait for them to finish.

Last edited by broadblues on 12-Jul-2011 at 11:37 AM.
Last edited by broadblues on 12-Jul-2011 at 11:36 AM.
Last edited by broadblues on 12-Jul-2011 at 11:34 AM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@all
>about directmode
It is my fault I should have implemented direct/indirect tag in Wazp3D
But i never imagined someone will wish to make a program slower
(i mean direct mode)

@samo79
>about WipeOut2097
I have downloaded and tried the WipeOut2097 demo on Aminet:
and it works with Wazp3D on my Sam440

Screen 640x480 32 bits

Then i let run 500 000 calls to Warp3D without crash
But after some more time it crashed on SetTexEnv()

It sems that WipeOut2097 need the original Warp3DPPC.library in LIBS:
(an old powerup game ?)
and of course Warp3D.library(=Wazp3D)

Also keep in mind
that Wazp3D CANT use display bigger than 1024x1024
that you need to close Wazp3D-Prefs to make the debugger really start
Not closing Wazp3D-Prefs dont let the StateTracker works (=> slower)


Alain

@thellier

For what i understand it work more or less good on Sam440 but not on Sam Flex, almost it doesn't work on my Sam Flex 800 Mhz (1 GB, Radeon 9250)

I have 3 possible type of problems:

- An instantanely ISI crash (in this case i need to reboot)
- A DSI error at startup or in a game but almost i can play a bit
- A freeze during the game (i can play 1 minute max before it hang completely)

This with default Warp3D and powerpc.library 16.41

With Wazp3D the game start but if i press "enter" after the logo the game turn back to the logo and doesn't permit me to play the game

Also I didn't have any debug output saved, i see the stdout output on the shell but it doesn't save anythings on a debug.txt file (it remain empty)

BTW: This game it rock solid and works great on my secondarian AmigaOne G3 800, there are some issue with the graphics of course but it's 100% playable and no crash at all !

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

Quote:

Ah, but blender does not direct Warp3D stuff it's all down to MiniGL. I think MiiGL assumes OS4 warp3d does no indirect modes.

Actually, as I said earlier, since V5 Warp3D doesn't support indirect mode any more, so such an assumption would be correct anyway.

_________________
Doing stupid things for fun...

@broadblues

Quote:

broadblues wrote: @Hans Okay maybe I said that wrong, Given that MiniGL sets direct mode, the code will asume that it is in direct mode, whereas with Wazp3D it appears that it's in indirect mode, that's bound to cause problems. Anyway blender accepts the minigl defaults in respect of direct / indirect mode.

If that is true, then this is a bug in Wazp3D. If a Warp3D app (or MiniGL) requests direct mode, then it should get direct mode.


Quote:

Reviewing my code in more detail, it seem I don't call glFlush or glFinish (at least not at the low level stuff that I wrote, it get used a lot higher up in te main blender code). I actually call mglUnlockHardware() or IMGL->UnlockHardware() just before starting graphics library rendering. This seems to work fine for Warp3D. But presumably 'unlocking the hardware' doesn't cause a flush of render operation in Wazp3d nor wait for them to finish.

That's something that should be fixed in Wazp3D then (for direct mode). It should eliminate the application specific workaround that's currently in place.

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@Hans

>This is a bug in Wazp3D. If a Warp3D app (or MiniGL) requests direct mode, then it should get direct mode.
>that should be fixed in Wazp3D then (for direct mode).
I agree I will fix that in the next Wazp3D release (i mean the official v50)
You can add this Wazp3D bug to my big bug-list

But let resume
1) Os3
createcontext(....W3D_CC_INDIRECT...) so use indirect
createcontext(....not precised ..) so use direct
2) Os4
createcontext(....W3D_CC_INDIRECT...) so use direct too
createcontext(....not precised ..) so use direct

Anyway i will add an option "Use only Indirect" in wazp3D-Prefs that will let override this behaviour and so speed up a few

BTW well written apps that use W3D_Flush() when needed should not see the difference between direct/indirect mode

Alain