SDL 2.0 Headers for [Object] Pascal?

[Murmandamus]

Regarding JEDI-SDL and the SF "last activity" date..

Anything you do to the project, including update the summary info, updates the "last activity" date. I can't find any files in the actual repository that have been touched in many years, most of them 10 years or more. So, no, I doubt the project has been touched. Of course, it really hasn't needed it -- SDL 1.x hasn't changed much in that time, either.

As for starting off, each library is going to have its own advantages and disadvantages, and will appeal to different developers as a result. Beginners will, most often, support what they started off using first, because they know it the best, and will often shun other libraries as a result. Sometimes it is just a lack of time, or maybe a touch of fanboi-ism, but it doesn't matter -- use whatever works and you feel most comfortable with, even if it isn't the absolute best tool for the job. However, I urge folks to try to be open-minded because, ultimately, if your stubbornness causes you to take the harder or lesser route, you and your players/customers will be the ones to suffer, not anyone else. Of course, I say this as the penultimate Object Pascal fanboi, so take my preaching with a nanogram of salt (or pillar of salt, given the audience and the venue ).

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 am only doing the main SDL library at the moment. I haven't looked at SDL_image, SDL_mixer, SDL_net, SDL_ttf, or SDL_rtf yet. Chances are, I will get to them before I am done, but no promises.

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.

[Darkhog]

Well, as I said, I've tried SDL before and it was a chore to code with it. Coding is supposed to be fun unless you're debugging (and even that can be fun). Allegro isn't OOP either, but it is easy enough and actually fun to code for.

[Murmandamus]

Well, as I said, I've tried SDL before and it was a chore to code with it.

I understand. I am sure there are people who feel the same about other libraries.

Coding is supposed to be fun unless you're debugging (and even that can be fun).

"Fun" isn't really an objective metric. One man's fun is another's drudgery.

Allegro isn't OOP either, but it is easy enough and actually fun to code for.

Yeah, lack of OOP is a separate issue, really. Some people don't care for it, and I understand and respect their choices. That's why I am doing any OOP in SDL as add-on wrappers (only sensible way to do it anyway); the straight procedural stuff will be as close as possible to the API itself. Though name-mangling and enum/macro/define/etc restructuring is unavoidable, it will at least be rational.

[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