OS41FE: The Crisot demo "Three" bug (=the stripe bug again)

Hello

The demo from Crisot "Three" has been reported to not work properly on OS41FE
http://forum.hyperion-entertainment.b ... 31646&hilit=crisot#p31646
So I give it try on my Sam4440/M9

test1:
mpega.library fail so no sound
All looks ok . The bump-mapping effect works too . the only problem is that ceilling and floor walls (=textures) are fully trashed

test2:
Ditto. But this time all the walls are ok but this time the blue "particles" are trashed. I mean this tex seems to be here (loaded) as we can see the blue "plots" but trashed with little vertical lines like something wrote in (trashed) the GPU memory

test3:
Using Wazp3D
All works even sound (I mean what is emulated so not the bumpmapping,zbuffer,etc...) so the problem dont come from a load file,load data, load datatype problems as all textures/walls/particles are ok

Conclusion: All looks like something is trashing randomly one texture in the GPU memory

Alain Thellier

After reflexion : I am not sure that the texture is only partially trashed
I mean as the demo use multi-texturing perhaps the diffuse-texture is ok and only the bump-texture is trashed or lost

I mean seeing some details on the walls dont mean that a texture is not fully lost or not readed : the details may come from the "other" texture

Also doing Amiga-M to swap screens change where the "stripes" bug occurs

Alain Thellier

Edit: I mean it may be a "lost texture pointer" bug too

@thellier

They changed byteperrow alignment, I head some trashing in Excalibur as well, because I got a few extra bytes at right side of my Bitmaps, this also effects BMA_Width, I head to switch to BMA_ACTUALWIDTH, in my code to work like it used to, I think this was is what's causing the problems.

BMA_Width returns a padded width with extra pixels, while BMA_ACTUALWIDTH returns the number of pixels you allocated when creating the bitmap.

P96BMA_BYTESPERROW is broken, do not use it, lock the bitmap and get BytesPerRow from RenderInfo struct.

Tring to calculate bytes per row your self is just wrong, always get bytes per row from a bitmap lock, if you need it.

If the demo/games/programs do not blank out padded bytes, you can get parasitic pixels, when using composition.

@LiveForIt

Quote:
Only the bytesperrow alignment of bitmaps allocated in RAM changed to facilitate faster DMA transfers. The bytesperrow alignment of bitmaps in VRAM haven't changed at all, because the GPU sets that requirement. Likewise, BMA_Width returns what it always has (i.e., the padded width).

Hans

@Hans

Quote:

Yes, but I head to change my code, so I guess the same problems might show up in others code, maybe I was just lucky before with padding used then vs how it's now.

@LiveForIt

It's more likely that the problems that thellier describes are Warp3D issues, especially a driver problem. He gets the trouble with real Warp3D, and not Wazp3D. Also, Warp3D textures aren't regular bitmaps at all.

@thellier
Perhaps you could try rolling back just the R200 Warp3D driver, to see if that's the culprit. Remember to reboot before testing, or it'll use the one already loaded in memory. If that doesn't work, then the "Picasso96" driver and Warp3D.library are also candidates worth looking into.

Hans

@all
Thanks for your help

I will investigate more this week

Alain Thellier

@Hans

Using the old libs:Warp3D/HWdrivers and it works again. No need to change other things in the OS41FE install

If Sam440 use the r200 driver then it is:
W3D_R200.library 253572 1/1/2013 = works
W3D_R200.library 230256 8/10/2014 = bug

Alain Thellier

@thellier

Thanks. So it's a driver bug. I've asked beta-testers to check it out, so that the bug gets logged.

Hans

>mpega.library fail so no sound
Oupps was just missing mpega.library in OS41FE's LIBS:

So the sound works
But the driver bug remain

Alain

@thellier and Hans
Reported.