Hyperion Entertainment Message Boards

Just a note to add, a few people have contacted me using X1000 systems. If you are using a Warp3D supported RadeonHD card, this updated W3D_Picasso96.library will not be of any use to you as the memory management routines it provides are not used. This update is strictly for R100, R200, Voodoo and P...

Apologies for the glacial delay. Today is the first time in ages I've had any time work on personal stuff. There is a debug build of the W3D_Picasso96.library (53.11) available at the following location: http://extropia.co.uk/warp3d/ Username: warp3dbeta Password by PM to anybody that wants it for t...

@Daytona

I might have found something. Please check your PM.

@Karlos As I don't presently have access to an OS 4 system, much less a working R200 based one, all I can do is conjecture. Are you still want to have only classic amigaos4 system, or, for the sake of development can go for sam or something ? I mean, we for sure can help with it if you want to spen...

This might be related to a bug I found when working on the R200 Warp3D driver which uses the same radeoncp.resource for talking to the chip. For whatever reason, the maximum number of words in a command packet seems to be less than implied in the hardware documentation. I never could find a reliable...

4. it also happens with 2048x1024 and 1024x2048 at both 32bit and 16bit (! so it fails even at about low 4 MB tex-data). 5. it works with 2048x512 and 512x2048 at both 16bit and 32bit (! so it can also work if about 4 MB tex-data). This behaviour doesn't make sense. I'm nowhere near as familiar wit...

@Karlos So it may be that all your realign fun is useless because at the end what you got was normal RAM? No. Please re-read the above posts. The allocator function takes your Context's display bitmap and tells P96/Graphics to use it as a friend bitmap when allocating. This ensures the bitmap is cr...

If P96/Graphics AllocBitMap() functions returned VRAM resident allocations that were already texture-friendly aligned for the target GPU, *none* of this complex allocation strategy would be necessary; you'd just allocate BitMaps directly using a pixel depth that matches your required texel depth. Al...

"I don't get it why perfectly 32bit-pot texture size calculations shouldn't be trivial. Under certain conditions (unsupported texture format, non-pot-texture, conversions) I'd understand that, but not in such a case where the conditions are optimal." Again, It is not the texture allocation...

PS:Try a 2048x2048 16 bit supported texture. That shouldn't lead to a 2048x2048 BitMap allocation if your context is on a 32-bit display because the BitMap allocation will likely be in the same format as the display (it uses friend allocation in p96 to ensure the BitMap memory is in VRAM and this us...