Welcome, Guest. Please login or register.

Author Topic: Curse of the SDL  (Read 24779 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16882
  • Country: gb
  • Thanked: 6 times
    • Show all replies
Re: Curse of the SDL
« on: August 21, 2011, 12:43:52 PM »
Poking the native texture surface in warp 3d is a bad idea. It's abstracted away for a good reason. The permedia alone will do your head in, you have subpatched addressing that makes any simple linear sequence of texels considerably more awkward to access.
int p; // A
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16882
  • Country: gb
  • Thanked: 6 times
    • Show all replies
Re: Curse of the SDL
« Reply #1 on: August 21, 2011, 06:37:10 PM »
Quote from: matthey;655606
I know it's a bad idea. I was just pointing out that it's easy to figure out where the textures "probably" are on the card. If the Permedia can't access the texture in VMEM as a linear "bit map" then it's highly probable that SDL doesn't do that either.


Sorry, I don't think I was entirely clear. The Permedia2 supports 3 addressing modes that are used for internal VRAM buffers.

1) Linear - bog standard, hardware-aligned buffers that are linear spans of pixels. All AmigaOS/RTG BitMaps, whether visible or off-screen use this format.

2) Patched - reorganised buffer that effectively dices a larger buffer into small squares that are then stored sequentially. These cannot be displayed and are intended for things like the LocalBuffer (Z and stencil). Warp3D doesn't use this format yet, but I have been experimenting with it for the Z-buffer.

3) Subpatched - this is an even more transformed version in which a set of the low order bits of the x and y coordinates into the buffer are interleaved, resulting in an order that generally keeps spatially-neighbouring pixels nearby in memory (often adjacent). This format is typically used for texture data, as it helps increase the performance of filtering (since you always need to sample your nearest neighbours). In Warp3D, textures may or may not be in subpatched format, depending on their size. For textures below a certain width, it is often not faster. IIRC, this format may not be used on the 68K because doing the transform is so slow that not even the bus speed hides it.

(3) is also the reason why the update texture sub image operation in Warp3D is so slow, since performing the operation on only rectangular subset of texels is such a PITA that it's simpler to redo the whole image. I do have problems with that and am aiming to fix it at some stage.

Quote
Are you the author of the 68k Warp3D Permedia drivers? If you are, there is a floating point rounding bug with at least one variable of Warp3D which kas1e (author of the Vague magazine) pointed out to me. Any chance of getting a fix for that or are you prohibited again? I guess wrong colors with the Permedia driver isn't as bad as trampling innocent memory trying to write the Zbuffer with the Avenger driver.


Yes and no. I did not write the stock Warp3D 4.2 driver, but I am the author of a range of unreleased revisions that ultimately served as the basis for the OS4.1 driver I'm now doing*. I'll see what the crack is with releasing those as personally, I can't see any reason not to.

*when I have free time, which has not been a lot lately :(
int p; // A