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
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
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.
Edited by LiveForIt on 2015/2/6 14:10:15
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
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.
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).
Likewise, BMA_Width returns what it always has (i.e., the padded width).
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.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
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.