iDevGames Forums

Full Version: funky texture corruption
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
look at this:
http://www.variableaspect.com/gallery/Te...uption.jpg

this is on my powerbook G3 running X.2 (8MBvram) set at millions of colors. the corrupted texture is 1024x512.

I thougth it was funky anyways Cool The mirrored texture even updates accordingly when you move the view window around Smile It's kinda like pointing a video camera at the monitor that is displaying the output. Now only if it wasn't a bug Grin At least I know how to fix it.
btw, does anyone know how to determine the amount of VRAM a computer has?
You can use IOKit to find out how much VRAM the card has, but that's not necessarily any indication of how much texture memory you've got...

That's a very cool effect Cool

What call is causing those messages to be printed?
Quote:but that's not necessarily any indication of how much texture memory you've got
true, however, if I know how much VRAM I have I can at least do a test to see if the texture will fit in the space leftover after I subtract the screen pixel and depth buffers.

1024x768x32 for pixel buffer +
1024x768x32 for depth buffer
= 6MB!
so logically I have a max of 2MB for textures, displaylists and what not.

doing a quick calculation,
1024x512x32 = 2MB (not going to work)
1024x1024x32 = 4MB (definitly not going to work)

however, if I set the monitor to 16bit, I only use 3MB for the screen. so I have 5MB for the textures and display lists. Now, 1024x512 will probably work. 1024x1024 will probably still choke though. (considering lists and other gl)

Quote:What call is causing those messages to be printed?
if I knew, I would be a much happier man.

henryj

I've seen this affect when the context or the texture hasn't been created correctly. The texture ends up pointing to randowm video mem.
Quote:Originally posted by kelvin
btw, does anyone know how to determine the amount of VRAM a computer has?


from agl.h:
"...
/*
** Property names for aglDescribeRenderer
*/
...
#define AGL_VIDEO_MEMORY ...
#define AGL_TEXTURE_MEMORY ...
..."
Quote:Originally posted by kelvin
look at this:
http://www.variableaspect.com/gallery/Te...uption.jpg

this is on my powerbook G3 running X.2 (8MBvram) set at millions of colors. the corrupted texture is 1024x512.

I thougth it was funky anyways Cool The mirrored texture even updates accordingly when you move the view window around Smile It's kinda like pointing a video camera at the monitor that is displaying the output. Now only if it wasn't a bug Grin At least I know how to fix it.

OT, can I get that desktop from you? Grin
Quote:Originally posted by henryj
I've seen this affect when the context or the texture hasn't been created correctly. The texture ends up pointing to randowm video mem.


Can you expand on this?

I also see the same recursive texture problem, in the following situation:

* 350Mhz iMac, Rage128 8 meg.
* Mac OS X 10.2.4.
* offscreen context (attached to a window for acceleration. the window is left at 0,0 and sized to 1024x512)
* window context, sized to 640x400, shared with the offscreen context to get to it's textures. A new texture is made from the offscreen context via createTexture: fromView: internalFormat:.
* fullscreen context, shared with the window context.

The offscreen and window contexts are created at startup. The fullscreen context is created when the user enters fullscreen mode, so that I can create it on the display that the window is currently on.

All of this works fine on a variety of Radeon and Geforce cards. But on the Rage128, in the fullscreen context, the texture shared from the window context (the one that is render-to-texture from the offscreen context) is wrong. Instead of being the offscreen context's content, it is the fullscreen context's content, so there is a weird recursive effect.

I read on mac-opengl that this *used* to be an issue with contexts that are created after textures are set up, but is supposedly fixed now. I have to create my context on the fly, and it doesn't appear to be fixed on the Rage128.

So, any insight? Is the Rage128 driver busted, or is there something obvious that I'm missing. I can post the (long) context code if that helps.
Reference URL's