This is just silly...
BlitzMax Forums/BlitzMax Programming/This is just silly...
| ||
| I've just got the DX9 renderer for CEGUI working... Yay! However, I needed to retrieve the d3d device. Given a TGraphics object, I can find it like this : TD3D9Graphics(TMax2DGraphics(g)._graphics).GetDirect3DDevice() But I'm pretty sure I shouldn't be using fields beginning with _ And then there's all the interesting (and obviously useful) stuff that's "Private" in the modules... Has anyone got any better ways to get at this information, or is this the "official" method of getting it? |
| ||
| I know this isn't helpful, but... I have also run into a few things I wanted access to in the brl libraries that are marked as Private. Sure, you can make it public on your own build and that will work for your own game, but if you are developing a mod for public release, then you are kinda screwed. |
| ||
| @TaskMaster: Yup, plenty of times I have run into that issue. It's rather disappointing. |
| ||
| Hi, I generally mark things as 'private' because I consider them 'part of the implementation' and as such subject to change. I'm also conservative in this respect - since the whole idea of Max2d is to 'abstract out' a 2D API to the point where it doesn't matter if it's using gl/d3d or whatever, then I tend to conservatively 'hide' anything that's NOT abstracted. Of course, source-less modules would completely solve this 'problem' (as would 'public global soup hell')...but in the meantime if you want something made public that's currently private, the best you can do is ask nicely! |
| ||
| but in the meantime if you want something made public that's currently private, the best you can do is ask nicely! I (sort of) tried that a long time ago. No responses. |
| ||
| I'd suggest making the change to your local copy to achieve your result and then make your case to Mark showing him why rather than making arbitrary requests without justification... IMHO |
| ||
| I'd suggest making the change to your local copy to achieve your result and then make your case to Mark showing him why rather than making arbitrary requests without justification. Something like an ugly workaround (which should be proof enough of how flawed the implementation is)? |
| ||
| Hi, I get what your saying, but in the case of making GLMax2d 'compatible' with GL - no sorry, I don't want to do that. Or more specifically, I don't want the *responsibility* of integrating it, dealing with any issues that may arise now or in future and in general maintaining it. While it may have taken you a day or so to hack together, *I'm* left with the responsibility of maintaining it forever, and past experience has made me wary of just dropping stuff in glibly. And, no offense hopefully, but this one is just screaming NO at me! And can't you just push/pop GL state to do this anyway? I also don't want that BindTex stuff public because I want the flexibility to be able to mess with it in future - making EVERYTHING public means you effectively *freeze* the entire implementation. Feel free to create a frozen fork like this if you want, but I'm not finished with the various Max2d modules yet and the 'private stuff' will likely change in future. Making the D3D driver(s) 'public' on the other hand is a lot easier and I'll more than likely do it eventually. But it'll be via some kind of API function (ie: an abstraction I can change the implementation of in future if I want) - and not by just making a global 'public'. This wasn't exactly a priority when I was trying to get the D3D9 driver going though, so for now you'll have to live with the hack above. |
| ||
| Not to worry :-) I found a way to eek out the information I was after (as the above hack)... then changed the API so that the user only needed to pass a TGraphics instance into the method, and I do all the hackiness casting deep inside the module. It just concerns me that I'm using fields with underscore prefixes, which I always assume to be "private". I suppose that generally, there are only 1 or 2 users who actually need access to such low-level stuff - those crazy module writers, mostly, I presume. Of course, having that access can then allow those 1 or 2 users to open up lots of interesting functionality for many more users :-) |
| ||
| And can't you just push/pop GL state to do this anyway? Sure, but with so many calls it became rather slow.Anyhow, I've gone and written my own engine to get around these limitations, so it doesn't matter. |
| ||
| so it doesn't matter. Since it doesn't matter anyway, your previous post seem rather troll-ish. |
| ||
| Since it doesn't matter anyway, your previous post seem rather troll-ish. ... |
   |