SDL 2.0 Headers for [Object] Pascal?

[WILL]

Regarding the SDL conversion (which is the thread topic *HMMPHF* *pokes in the ribs with a sharp claw*), there are going to have to be several passes at it. It is a C library, which contains NO OOP support at all. I mean, you can compile and link it to C++, but none of the code is OOP. So, my first pass is just going to be a straight procedural/header conversion. Like the library itself, it will be ugly, but will be as compatible and complete as possible. The second pass will be trying to wrap some of the more obvious targets in the code with classes to try to bring it into the 21st century. After that, further refinement would require bringing the whole library into FPC, which I would love to do, but that would be a job and a half.

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.

There are some compiler-specific pieces which likely will either not be implemented, or will have to be implemented differently/outside of the library. Things like debugger support in SDL_assert and atomic operations in SDL_atomic come to mind.

Also, since SDL pretty much includes the current OpenGL / OpenGLES headers, I will have to convert those as well. I'm saving that mess for last.

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.

As for OpenGL, could you not use the OpenGL headers from the German DelphiGL community? They are the best that I know of.

[Murmandamus]

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.

[WILL]

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.

Well I figured as much. Probably not possible to make use of them without adding some kind of extra functionality into FPC it's self.

It is possible, presuming they have an up-to-date set of OpenGL headers.

I'm sure you'll find them to be the best ones for the job. I recall Sascha Willems practically scolding Embarcadero on theirs and suggesting the use and inclusion of the DGL headers in future releases of Delphi instead.

Though I understand why you want to get into the mud and learn everything.

OpenGL is a bit of a monster though and I think it would be more of a benefit to let someone else fight that battle. Especially when it's already been fought. It might be a good idea to take on one API/framework at a time anyhow.

Now if the DGL community starts dropping the ball then that's a whole new bag of worms and I'd say go for it.

[imcold]

There are pascal headers for development version of SDL in HedgeWars and TURBU, not sure how recent they are, but they may be helpful.

Edit: Turbu header is probably just delphi only, I got into quite a few issues when trying to use it in FPC. There also seem to be some sort of SDL2 pascal headers on github, but the repository is messy and the files are full of syntactic errors; probably some h2p translation that wasn't cleaned up.
The headers from Hedgewars look nice, I added some minor stuff and got a basic Display class up and running. Going to play with events now

[Darkhog]

There are pascal headers for development version of SDL in HedgeWars and TURBU

Hedgewars were written with FPC? Interesting...

Anyway, I hope you'll get it working. While I don't like SDL for reasons stated on this site many times, others like it and more choices is always welcomed!

[imcold]

Hedgewars were written with FPC? Interesting...

They are (with a tiny commit by yours truly); it's my favourite fpc game. Except the GUI, that's C++ and Qt, and server, that was Haskell iirc.

[kotai]

@Murmandamus You make headers only for FPC or you make it compatible with DelphiXE4 ?
I'm change my Delphi DirectX games to SDL1.2 and I like port it to SDL2.0 with DelphiXE4

[BeRo]

Here my also-SDL20-staticlink-capable SDL 2.0 (and SDL 1.2 hybrid per IFDEF) headers, which I've made in early 2012 for my c64 emulator Micro64 ( http://www.micro64.de ) on base of the old SDL 1.2 headers: http://rootserver.rosseaux.net/stuff/sdl.pas

[Murmandamus]

@Murmandamus You make headers only for FPC or you make it compatible with DelphiXE4 ?
I'm change my Delphi DirectX games to SDL1.2 and I like port it to SDL2.0 with DelphiXE4

Unfortunately, I don't have Delphi, and I am using a few FPC-specific extensions, though I am considering adding a "standard" version with conditionals during the cleanup phase that will probably be Delphi-compatible; I just have no way to test it. Once I publish it all, if someone wants to do that testing and any additional cleanup for Delphi, I'll be happy to merge those changes, or they can fork it and maintain a Delphi-compatible version, either way.

[Murmandamus]

I'm sure you'll find them to be the best ones for the job. I recall Sascha Willems practically scolding Embarcadero on theirs and suggesting the use and inclusion of the DGL headers in future releases of Delphi instead.

Yeah, I had them downloaded from a while back. Just needed to get an updated copy.

OpenGL is a bit of a monster though and I think it would be more of a benefit to let someone else fight that battle. Especially when it's already been fought. It might be a good idea to take on one API/framework at a time anyhow.

Well, it's not a monster because of complexity.. they are just header files. A bunch of function prototypes, some structs/unions, and a cubic arseload of constant #defines. It is just the sheer amount of them that is daunting. The DGL translation adds a few helper functions for loading function pointers and such, and weighs in at around 20k lines. I need to do some comparison checking to the SDL_opengl source file to make sure it is more or less the same, which I think it is.

Now if the DGL community starts dropping the ball then that's a whole new bag of worms and I'd say go for it.

The only problem I have with DGL (and it is my problem, not theirs) is that I don't speak/read German. Fortunately, the dglOpenGL.pas unit is in English, but little on their wiki is translated. That, or I am having trouble finding the translated pages, even after appending the standard /en for English pages in wikimedia. Google translate works to a degree, but isn't very good for technical articles.

Anyway.. I am almost done with the raw conversion. Have to do a more intensive functional cleanup pass, then a logic verification pass, and then a "feed it to the compiler and see what happens" set of passes. After that comes the fun part... testing.