GLMax2DDriver unbind all textures?

BlitzMax Forums/BlitzMax Programming/GLMax2DDriver unbind all textures?

ima747 (Posted 2010) [#1]

Is there a way to wipe out all the textures from VRAM and clear the list of textures openGL is tracking? Or possibly force the driver to reset which might have the same effect?

N (Posted 2010) [#2]

Why would you need to do this? And as far as I know, the answer is no.

ima747 (Posted 2010) [#3]

Because I'm having a problem with shared contexts from some canvases in maxgui when I switch to MiniB3D display (causes a crash on one of my tester's computers unless I kill off the shared context and rebuild it since I need a clean one for minib3d) and then switching back to maxgui and canvases (again killing off the shared context, but some texture links seems to remain in openGL since as I recreate my 2D graphics from scratch some of them come out corrupted despite the first ones being nulled and garbage collected) so it looks to me like openGL is holding on to some stuff and not going clean. Basically I need to totally reset the graphics system when I switch between maxgui with canvases and minib3d, and then reset again when switching back or it can crash on one tester's computer (which isn't a junky intel or S3 or anything so it's not just a crap graphics card). He has no problems with either component individually, just when you switch between then stuff gets ugly. It's specifically the shared contexts (if I turn them off no crash, but then I can't use multiple canvases which I need)

N (Posted 2010) [#4]

Edit: Hm, now I'm just confused. Removed my comment since I need to think this over a bit more. Edit 2: Although I will re-add that I do think your problem comes down to a bad design more than anything else.

ima747 (Posted 2010) [#5]

I would love to design around it but the crux of the issue is this. 1) I use MaxGUI with 3 canvases (and therefore GLSharedContext()) for the setup portion of the application. The canvases are used for 3 custom GUI controls that can't just be replaced with something more standard. 2) All of the setup from that GUI is used to prepare data structures to be used for a 3D display. So if I can't switch to minib3D it doesn't really do anything, and likewise if I can't do the setup then the 3D has no information to work with. 3) None of the graphics used in the 2D are re-used in 3D. All of the 2D are thumbnails or just images needed for the GUI elements (buttons and such). When switching to 3D I need to unload all of that and re-load the user images in higher resolution for use as textures in 3D. I need to keep very tight control over what is loaded into openGL as I'm basically using all available VRAM to display onscreen items, when openGL handles too much there are hicups as it loads/unloads images which can be avoided by forcing it to load when I'm not busy drawing things. 4) The only reason I need to turn off shared contexts at all and manually unload everything is to prevent a crash on one computer used by one of my testers. A mac Pro with both an ATI and NVIDIA graphics card. We've tried to eliminate the chance that it's a software conflict by shutting off everything else he's running that could be in any way related to the graphics system. We've paired down to 1 monitor and with that tried both cards and it still crashes. Doesn't crash on any of the 3 other macs I've tested it on or 4 PCs, so it could be just him but he is my main tester. He doesn't have any problem with the GUI with shared contexts OR with the 3D, it's switching from the GUI to 3D that causes a crash when graphics try to initialize. The screen goes black (like it should) then the program just closes, no crash report. If I could find a way to keep him from crashing without disabling the shared contexts when switching that would be much better but I'm all out of ideas there...