Strange Flag 256 behavior

I've been doing some testing with a 3D GUI lib I've been working on. It's a single-surface-per-window lib that uses Skid's 'pixie' thinking with fredborg's PickedUVW stuff to give easy rotation, scaling, alpha and all that other nice stuff.

I've run into an odd thing though. I update the texture when gadgets and windows change, and on most rigs all things work fine. The odd thing is that, on some rigs, using flag 256 to create the texture makes the changes to the texture invisible -- while on some rigs, NOT using flag 256 to create the texture will do the same exact thing. I expected that =using= flag 256 might cause trouble... but I certainly didn't expect that NOT using it would!

Here's the code -- it's based in part on others' work and going to be free for use anyway so if anyone can work out why, exactly, it's doing this -- or at least how to sensibly test what flag I need to use without actually asking the user -- I'd be much obliged.)

http://www.echthros.com/files/3gui.rar

(PS -- even if you can't work out why this is happening, a note on your FPS would be much appreciated)

(PPS -- if you're one of the unlucky souls that require flag 256 to see anything (or just want to change it to get faster window update times), go to the WIN3_Create() routine, go to the line under 'If masked = False' and change the flags in the call to CreateTexture() from 1 to 257.)

(PPPS -- if you just want to have a play, be sure to read the readme.txt so you can see what you can do with it.)

504fps in windowed mode the flag has to be set to 1 for me :)

From testing in #blitzbasic and #blitzcoder, it's looking as though nVidias can't handle the 256 flag, ATIs can handle either, and certain Intel chipsets are the ones that require 256.

Thinking I may need to do a quick initialization call that creates two small textures, one with flag 1 and one with flag 256, plot a point to both and then test that point to see which flags 'work'. Ugly but doable.

FWIW: I've added an initialization routine that does exactly what I've described above and it seems to work consistently. I know it seems a bit like I'm talking to myself here, but lots of folks helped in both #blitzbasic and #blitzcoder and I'd like to thank em for bearing with me as I got this sorted out.

Definitely some unusual findings -- nice to know it's the sort of thing you can work around though.

Damn, this thing's fast! =))) Try commenting out the 'Delay 1' -line from the mainloop and run in fullscreen... ;)
Edit: morduun already took it off from the new version

1500 fps with no changes... o.O

Forgot specs, P4 3.0ghz HT, 1gig ram, Radeon 9800 pro(128meg), xp corp.

Thanks for checking it out you three -- looks like the compatibility problems are over and I can get down to coding the rest of this thing. Got 3D cameraview gadgets working on the train tonight, and I'll probably have the rest of it done to my satisfaction before Christmas, so I'll post a new post in the showcase when it's openly available.

Thanks again to everyone for testing!