SDL 2.0 Headers for [Object] Pascal?

[Cybermonkey]

Don't forget another big plus: statical linking is allowed on all platforms...

[WILL]

Yes true!

Also you can in fact use it for your Android and iOS games as I read from the SDL website.

[Murmandamus]

Just wanted to give a FYI on this topic.. since SDL 2.0 has gone RC, I have started doing the FPC header conversion for it. Not sure when or how much of it will be done -- I am trying to convert as much as possible, though some of the headers don't have a natural analogue in FPC.

Once I get a clean pass and can compile some test/example apps with it, I'll publish it on github.

[Cybermonkey]

Just wanted to give a FYI on this topic.. since SDL 2.0 has gone RC, I have started doing the FPC header conversion for it. Not sure when or how much of it will be done -- I am trying to convert as much as possible, though some of the headers don't have a natural analogue in FPC.

Once I get a clean pass and can compile some test/example apps with it, I'll publish it on github.

Those are really good news!

[WILL]

...I have started doing the FPC header conversion for it... ...Once I get a clean pass and can compile some test/example apps with it, I'll publish it on github.

That's great! Please keep the community informed. There are many that have been using SDL as a starting point into game graphics programming. It would be great if we could finally get an updated resource.

Dominique Louis (aka savage) no longer updates JEDI-SDL so it's kind of hard to tote it as the best beginners library out there now. Though it's not 100% obsolete, it's starting to age and compatibility and stability will start becoming an issue as desktop OSes start to evolve.

[Darkhog]

Well, while I have nothing against SDL, here's my two cents: I've tried it and found out that it is harder to grasp for beginners in "actual" game programming (by "actual" I mean not in software like Game Maker/The Games Factory/Stencyl/CraftStudio, though I have nothing against them) than Allegro.pas (or even C allegro). That being said, I don't consider SDL inferior or anything like that, it's just that I had troubles with understanding SDL and have no troubles with understanding Allegro.

Also are you sure JEDI-SDL is not updated anymore? I've look here: http://sourceforge.net/projects/jedi-sdl/ and in Last update it says some date in May 2013. If Dominique is not doing it, maybe it's someone else?

[Cybermonkey]

Well, while I have nothing against SDL, here's my two cents: I've tried it and found out that it is harder to grasp for beginners in "actual" game programming (by "actual" I mean not in software like Game Maker/The Games Factory/Stencyl/CraftStudio, though I have nothing against them) than Allegro.pas (or even C allegro). That being said, I don't consider SDL inferior or anything like that, it's just that I had troubles with understanding SDL and have no troubles with understanding Allegro.

Ok, it's vice versa in my opinion. I had not trouble starting with SDL (especially having that great ressource here: http://www.freepascal-meets-sdl.net/) but have almost no clue about Allegro ...

[Darkhog]

Well, I've seen APIs of both and Allegro's IMHO easier to comprehend. Plus need to carry just one dll around with your app instead of SDL_mixer.dll, sdl.dll, sdl_ttf.dll, etc. is also a feat. Just read APIs and way of doing things in both (may be even C examples - they're surprisingly easy to translate into Pascal) and you'll get to same conclusion.

But this is offtopic, so I'd like to get this on PM if you have further questions/discussion/dead threats about the subject.

[WILL]

Also are you sure JEDI-SDL is not updated anymore? I've look here: http://sourceforge.net/projects/jedi-sdl/ and in Last update it says some date in May 2013. If Dominique is not doing it, maybe it's someone else?

Really?! Well that's a surprise.

Well to be honest I'm not too sure what he's been doing with it lately. I recall that he hadn't touched it in ages and I know that he was the last person that was managing the JEDI-SDL repository. He was working on adding better support for Mac when we talked last, but since then I have heard nothing. Perhaps he decided to poke around and clean up something or the odd missing files/demos or something.

On beginning...

Well truthfully I don't think that there has been quite as nice a beginner programmer's tool as there used to be for a time. Its not so much SDL's fault, but that of the landscape of all the tools changing so much in the last 5+ years. Lazarus was alright, but if you were learning on any platform other than Windows XP/7 you were practically up a creek. Delphi became office fodder that cost to much for anyone with any budget sense. And Oxygene wasn't what it is now.

I know someone is going to mention FPC so let me put this to rest. Straight FPC isn't the best for beginners and new programmers aren't going to be patient with ASCII IDEs, save those few "different" folks.

So to do it right you had just Lazarus and even there you had some issues for a short while.

Bringing SDL back to it's glory....

Hands down SDL had been the easiest to get into and start learning and it allowed you to easily learn and migrate to OpenGL while continuing to use it for those missing features from other API like DirectX's DirectInput, DirectSound and such. SDL was a good match, but then tools changed and setup became more involved and instructions and documentation less accurate with more exceptions causing you to do more reading and guesswork. Beginners, in some ways rightfully so, don't like too much of that right at the beginning.

If someone could foster a new set of headers for SDL 2.0 and maintain it well enough I could see it coming back as a good first game library for any potential beginners. It's the future of SDL so if Pascal developers want to keep current it'll need to be translated and kept up. Such is similar as the translating of the DGL OpenGL headers. Who else has brought the OpenGL headers up to 4.0? Not Embarcadero from what I've been told.

[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.