Quote Originally Posted by WILL View Post
I would take care with this. Your approach of making it something you can include or leave it is a good one so I recommend you stick to that! I am saying take care with regards to it's implimentation so that it doesn't perform that much slower then if they just used the strait wrapper portion. It is very easy when adding an extra layer to an API or game library to bloat it or get in the way of the advantages of how it was originally designed. Any code layer adds something to it, but if you keep it thin enough (and how to do that is a matter for argument) you can add enough value of the extra functionality of your class based code layer without getting in the way of the original library's design and desirable perks.
Yeah, OOP-izing a procedural API has these pitfalls and other ones as well, so it will have to be looked at carefully to ensure the best performance as well as usability. That's one of the nice things about sticking with procedural APIs, as they avoid the OOP bloat that inevitably results. So, yeah, the idea here is to keep it as lightweight as possible, especially for the parts of the API which are sensitive to performance issues. Regardless, keeping it as a wrapper ensures that the developer can always drop back to procedural if need be for those areas which require it.

That's also why I was saying that, in order to truly take full advantage of the OOP paradigm, it would probably be best to refactor the entire library itself, rather than going the wrapper route, but it is mainly an exercise in experimentation to see what will work. I am sure there will be a few iterations on it, so we'll see how it turns out.

Well when it comes to compiler specific, we have IFDEFs which you can use to assign global constants which will activate and turn off specific part of the code that will work in those specific tools where an object pascal solution is available. I assume that research will take up much of this time.
Well, conditional compilation won't help those functions; they depend on operations and core functions in the C library which simply don't have analogues in FPC.

As for OpenGL, could you not use the OpenGL headers from the German DelphiGL community? They are the best that I know of.
It is possible, presuming they have an up-to-date set of OpenGL headers. It looks to me like SDL just includes them wholesale without significant modification, so it is something I can look at. That said, one of the reasons behind the effort is to get a "guts-eye" view of the code, not only for SDL, but for OpenGL as well. If I am going to be fiddling with the guts at this level, it is probably a good idea if I "grok" it as thoroughly as I can. I like doing conversions because they force you to learn all the bits and bobs, so there's a practical reason for "reinventing the wheel" in this case. I still can use other translations as guides, though; just like I am using the old SDL 1.2 Pascal translations to assist in doing the 2.0 one. Having as much information as possible makes the task easier.