Hi, > > Hi Rudolf, > >I can imagine the same > >fault sitting in BDirectWindow BTW: did not check. > > I think BDirectWindow works fine, at least on beos r5. BTW, I > uploaded a test app in /src/tests/kits/game/direct_window_info_test which, started from a terminal, prints also the clipping info, you can use it to check if it works fine under dano (which I don't have). I was hoping BDirectWindow works fine: it's much more used I guess :) Also, I guess it could make a difference if you're inside a class 'implementing'(?) it, or if you are outside of it using it? I'm no expert in this kind of stuff as you can see via the question marks.. > You mentioned BGLView... I noticed we don't even have the header in > our repository. Should we implement it as well ? I seem to recall some discussions about GL stuff which involved breaking source and binary compatibility but I could be wrong, someone remember better than me ? The header should be there I'd say. It's on R5 as well.. I don't know what discussions you are talking about BTW. My bad I guess. Anyway: I don't know what road Haiku will take towards HW openGL. I just know that BGLView (especially if fixed) is perfectly usable as far as I'm concerned. And it's compatible with R5.. Although I did not yet look into things as switcing workspaces while an app is running, setting a new more when an app is running. But maybe someone else sees already how that should/could work. Be went another way: something like BDirectGLView or something (dano). It adds multimonitor support and fixes the probs BGLView has. At least, this has been told to me by a betatester. Anyway: I think I already proved now that BGLView in itself is perfectly usable for us for now. > BTW, nice workarounds :) Thank you :-) It's nice (again) to get confirmation on a direction taken: as I am still a bit uncertain in this new area for me. Although I generally am able to detect if something is setup right for (graphics) hardware support ;-) Rudolf.