SDL 2.0 Headers for [Object] Pascal?

[WILL]

Hey guys, I'm normally the one to go out and find these things most of the time, but I've been searching around and have no idea who might have created headers for the new 2.0 version of SDL.

There are a lot of changes since the old 1.x version and it supports a lot of new things like multiple screens and windows along with force feedback on all the top 3 desktops. And a whole slew of other things.

Here is the introduction docs in case you want to know more about it yourself: http://wiki.libsdl.org/moin.cgi/Introduction

Currently there is an issue with going fulllscreen on Mac OS X Lion and above using SDL 1.2.X so I'm looking into hopping over to 2.0 which is better, but would require appropreate headers. Does anyone know of a Pascal developer that has started or completed such a project?

[hwnd]

Also my question. If there will be SDL 2.0 for Pascal, will this break the SDL_Image and other things?
I guess they will not work with SDL, because of rewrite of SDL.
Or im wrong?

[Cybermonkey]

I am looking for SDL2 headers, too. But there seems to be no Pascal support as far as I can tell. The only one I found is SDLh.pas for the game Hedgewars but I think SDL2 is only used for the mobile ports ... :(

[Super Vegeta]

If there will be SDL 2.0 for Pascal, will this break the SDL_Image and other things?
Judging from the Mercurial web interface (http://hg.libsdl.org/), SDL 2.0 will come with new versions of _image, _mixer, _net and _ttf.

[WILL]

Also my question. If there will be SDL 2.0 for Pascal, will this break the SDL_Image and other things?

Like Super Vegeta said, there are newer versions of the support libraries like SDL_image and the rest that will support SDL 2.

The main problem is that there are no Pascal-based headers from what I can tell. Perhaps this is a new project for the community?

From what I can tell it would be worth it to work on a new set of headers for SDL. Considering the advantages that 2 brings to the table. Multiple display/window support, Force feedback for Win/Lin/Mac, improved video hardware acceleration support and of course Full Screen functionality that was lost to SDL 1.x in the last 2 versions of Mac OS X. :/

I don't think that Dom is doing much with JEDI-SDL these days other than just holding onto the repository. Honestly though I think that the "JEDI" label should probably be retired at some point considering that Delphi is likely much lower on the list of game dev tools these days.

[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. ;D 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 :P ).

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 :)

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

[Cybermonkey]

What about the unit files here: http://code.google.com/p/swingamesdk/source/browse/trunk/CoreSDK/libsrc/drivers/sdl1.3/?r=1621

[imcold]

Those look great! Nice find.

[Murmandamus]

What about the unit files here: http://code.google.com/p/swingamesdk/source/browse/trunk/CoreSDK/libsrc/drivers/sdl1.3/?r=1621

Those are for SDL 1.3.

I've got several translations of SDL 1.x headers.

[Cybermonkey]

Ah, okay my fault, I thought 1.3 was the development version of 2.0. Never saw a 1.3 version on libsdl.org ...

[Murmandamus]

Well, technically, there was never a 1.3. The repository contains a 1.3 branch, but it is marked as obsolete, and looks to be just a marker to start the development of the "next version". That branch is dated Feb 2010, and the files in the SwinGameSDK are dated Jan 2012. Even if it is a 2.0-dev branch translation, there has been a LOT of development in the last 18 months leading up to the actual 2.0 release, so I don't think it can be considered a good 2.0-compatible translation.

Without looking into it, I think it is, at best, a snapshot of the "latest and greatest" of the dev version of SDL as of 18 months ago, but likely may be just a translation of whatever the obsolete 1.3 tag has in it, which looks to be just a copy of v1.2.14. Note that the latest public version of SDL, 1.2.15, was released pretty much at the same time as those SwinGameSDK files were.

[imcold]

Most of the functions and structures related to window, renderer and management are compatible with 2.0RC, so it is usable at least to some extent - I haven't tested the whole lib of course. I haven't had any trouble getting some simple game running with it, if I used it instead of my own translated header.
So definitely not a 1.2.x copy, and at least somewhat usable in the meantime.
By the way, are you using the source of RC or trunk as a base for your version?

[Murmandamus]

Perhaps, but the main point of the exercise is to get a fully 2.0-API-compliant header set, drawn directly from the released sources. (That and to get a deep view of the library)

I am using the actual 2.0 release headers from the public SDL-2.0.0 download package. The headers should not be changing at this point.

[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 (http://www.pascalgamedevelopment.com/member.php?664-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

[End]

I am looking for SDL2 headers, too. :(

I'm writing SDL 2.0 Pascal Headers from the actual Repository. Here:

https://github.com/ev1313/Pascal-SDL-2-Headers

Actually not all Header-Files are translated yet, but the most important are: i was able creating windows with openGL Support and Event-Handling.

(see my sample section: https://github.com/ev1313/Pascal-SDL-2-Samples/ )

Of course everything is WIP, but you can help me by testing them ;)

Edit:

Actually the RC-Candidat don't works with Pascal, you'll get an error with "missing main-function". this is fixed in the actual release, but this means you have to compile the DLL yourself. Here's an working DLL i've compiled with VSExpress:

32 Bit: https://dl.dropboxusercontent.com/u/512 ... L2_x86.dll (https://dl.dropboxusercontent.com/u/51225594/SDL2_x86.dll)
64 Bit: https://dl.dropboxusercontent.com/u/512 ... 86_x64.dll (https://dl.dropboxusercontent.com/u/51225594/SDL2_x86_x64.dll)

[Cybermonkey]

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

Hey thanks, but why is SDL_BLITSURFACE commented out? There seems also no SDL_LOADBMP in SDL2.0? Is this not available anymore or just missing in your header?

[End]

Hey thanks, but why is SDL_BLITSURFACE commented out? There seems also no SDL_LOADBMP in SDL2.0? Is this not available anymore or just missing in your header?

SDL_BLITSURFACE = SDL_UPPERBLIT;

But SDL_LOADBMP is there. (I have translated it in my header)

[Cybermonkey]

Hm, I got:


Target OS: Win32 for i386
Compiling sdl2test.pas
Compiling sdl.pas
sdl2test.pas(14,21) Error: Identifier not found "SDL_LOADBMP"
sdl2test.pas(59) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted

Also a text research shows SDL_LOADBMP in the 1.2 part.

[End]

Hm, I got:

Also a text research shows SDL_LOADBMP in the 1.2 part.

Well, try with my headers, it should work.

[Cybermonkey]

Well, try with my headers, it should work.

Oh, sorry, I tried the header from BeRo, but in your headers SDL_DELAY is missing. Seems I have to wait a little bit longer until they are finished.

[End]

Oh, sorry, I tried the header from BeRo, but in your headers SDL_DELAY is missing. Seems I have to wait a little bit longer until they are finished.

Yes, today I'll translate sdl_timer => SDL_DELAY.

[End]

Yes, today I'll translate sdl_timer => SDL_DELAY.

Well, this was fast. SDL_Timer.h is translated, so you can access now SDL_Delay and the other Time-Functions.

[WILL]

Wow this effort is moving really fast. Nice work guys!

[Murmandamus]

Just a quick update on my translation..

I completed the first pass, and have been doing some cleanup.. some of the initial assumptions I was working with when I started changed as I slogged through each header file, so I have to go back and harmonize those changes in the earlier conversions.

Hopefully, I will have enough time to get it completed and start testing in the next couple of weeks; have had a spot of planned IT consulting work which is adding a bit of delay, but I will get it done ASAP.

[Murmandamus]

@Murmandamus (http://www.pascalgamedevelopment.com/member.php?664-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.

[kotai]

@End I use your headers and work OK in DelphiXE4 (I add it to sdl.inc) with WIN32 and WIN64 but not with OSX ("uses windows" error).
I change:


{$IFDEF Delphi}
{$DEFINE Windows}
........


for:


{$IFDEF Delphi}
{$IFDEF MSWINDOWS}
{$DEFINE Windows}
{$ENDIF}
........


but is not enough for compile sdl.pas in OSX.
You plan to make it compatible with DelphiXE4 and OSX ?

I use last SDL2.dll download from libsdl.org (I change in sdl.pas SDL_LibName = 'SDL2.dll') and work fine. Not need use SDL2_x86.dll and SDL2_x86_x64.dll

You plan to make headers for SDL2_mixer ?
I convert SDL2_image, SDL2_net and SDL2_ttf from jedi-sdl and work OK, but SDL2_mixer not work ???.
SDL2_mixer generate an access violation in function Mix_LoadWAV_RW of SDL2_mixer.dll (same function in SDL_mixer.dll of SDL1.2 work ok)

In SDL2 not exist SDL_CreateThread and SDL_KillThread ? My games use SDL_Thread and I need to upgrade to SDL2 >:(

Kotai.

[End]

@End I use your headers and work OK in DelphiXE4 (I add it to sdl.inc) with WIN32 and WIN64 but not with OSX ("uses windows" error).
I change:


{$IFDEF Delphi}
{$DEFINE Windows}
........


for:


{$IFDEF Delphi}
{$IFDEF MSWINDOWS}
{$DEFINE Windows}
{$ENDIF}
........


but is not enough for compile sdl.pas in OSX.
You plan to make it compatible with DelphiXE4 and OSX ?

I use last SDL2.dll download from libsdl.org (I change in sdl.pas SDL_LibName = 'SDL2.dll') and work fine. Not need use SDL2_x86.dll and SDL2_x86_x64.dll

You plan to make headers for SDL2_mixer ?
I convert SDL2_image, SDL2_net and SDL2_ttf from jedi-sdl and work OK, but SDL2_mixer not work ???.
SDL2_mixer generate an access violation in function Mix_LoadWAV_RW of SDL2_mixer.dll (same function in SDL_mixer.dll of SDL1.2 work ok)

In SDL2 not exist SDL_CreateThread and SDL_KillThread ? My games use SDL_Thread and I need to upgrade to SDL2 >:(

Kotai.

I've corrected the first mistake, XE4 should be supported now, thanks.

unfortunately i don't own any OSX Version, but i want to support it of course. May you send me your compiler output? Maybe you have to compile the libraries yourself on OSX, cause there was in the RC an bug...

I don't know when I translate the other SDL-Libs, but I'll do that if I finished the main SDL-Lib.

I've translated already Thread (see in the branch "thread") but i don't get it working on 32 Bit... it works only in 64 Bit :/

On 32 Bit I get an Access Violation, maybe is sth. wrong with the pointer sizes, i'm working on this...

Greetings

P.S.
And this _x86.dll Endings:

I've done this, cause i'm using many compilers, 32 and 64 Bit and I was tired of changing the Libnames ;)

[SilverWarior]

I've translated already Thread (see in the branch "thread") but i don't get it working on 32 Bit... it works only in 64 Bit :/

On 32 Bit I get an Access Violation, maybe is sth. wrong with the pointer sizes, i'm working on this...

Make sure yoiu have both 32 bit and 64 bit verson of every dynamic link libraries (dll's) that your library depends upon.
32 bit programs can only use 32 bit dynamic link libraries, 64 bit programs can only use 64 bit libraries.

[phibermon]

I started a SDL 2.x header translation a few years ago (stopped as at the time there were license issues, the API was changing a lot) and would be willing to put some work into this if needed.

I'm surprised to learn that they've got multi-window support covering OpenGL, I will have to look thru the code and see what threading setups they allow, I'm guessing they only support a single thread for all GL windows due to Linux + OSX context sharing abstraction. Tricky on Cocoa in general as well! I disabled multi-window support in my framework as the design required to handle per window thread setups with seperate GL contexts made things very messy, requiring a whole layer of abstraction and another set of concurrency wrappers to upload and track data across multiple contexts.

[kotai]

Sorry, I see reply today.

This is my SDL2 for Delphi XE4: http://www.remakesonline.com/descargas/SDL2.zip
It include:


sdl2.inc
SDL2.pas
SDL2_Image.pas
SDL2_Mixer.pas
SDL2_Net.pas
SDL2_Ttf.pas


All tested and working in Win32 and Win64 (not in OSX :()

This is a example of SDL2 and SDL2_Image for Win32, Win64 and OSX(not work ok): http://www.remakesonline.com/descargas/EjemploSDL2.zip

Kotai.

[End]

I released now the thread-part. It works on Win32 and Win64.

@kotai:

May you send me the Errorlog for OSX? (for a sample working with Windows)

I'll translate sdl_image, if i get the time in the next days.

[kotai]

Hi.

I have translated SDL2_Image, SDL2_Mixer, SDL2_Net and SDL2_Tft, you can download at:

http://www.remakesonline.com/descargas/SDL2.zip

I can compile for OSX in Delphi XE4 without errors, but latter when I execute in MAC I have a error of SDL not found, but I install framework SDL2.framework in /Library/Frameworks



Last login: Tue Jul 30 14:50:12 on ttys001
/Users/kotai/Applications/Embarcadero/RADPAServer/10.0/paserver ; exit;
macosx:~ kotai$ /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/paserver ; exit;
Platform Assistant Server Version 2.0.7.05
Copyright (c) 2009-2012 Embarcadero Technologies, Inc.


Remote Profile password <press Enter for no password>:


Acquiring permission to support debugging...succeeded


Starting Platform Assistant Server on port 64211


Type ? for available commands
>listen
Process Control Server Started pid 283 exe built Aug 21 2012
sentinelFunc 285
dyld: Library not loaded: @rpath/SDL2
Referenced from: /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego/juego
Reason: image not found
^Cdbkexe : interrupt sig->exit
EControlC: Control-C hit
logout


[Proceso completado]


Then, I copy SDL2 (from /Library/Frameworks/SDL2.framework/Versions/A/SDL2 ) to game folder and get next error:



Last login: Tue Jul 30 15:02:55 on console
/Users/kotai/Applications/Embarcadero/RADPAServer/10.0/paserver ; exit;
MacOSx:~ kotai$ /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/paserver ; exit;
Platform Assistant Server Version 2.0.7.05
Copyright (c) 2009-2012 Embarcadero Technologies, Inc.


Remote Profile password <press Enter for no password>:


Acquiring permission to support debugging...succeeded


Starting Platform Assistant Server on port 64211


Type ? for available commands
>listen
Process Control Server Started pid 163 exe built Aug 21 2012
sentinelFunc 166
dyld: Library not loaded: @executable_path/../Frameworks/SDL2.framework/Versions/A/SDL2
Referenced from: /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego//SDL2_image
Reason: image not found




Then, I copy SDL2.framework to /../Frameworks/SDL2.framework and get next error:



Last login: Tue Jul 30 15:15:45 on ttys001
/Users/kotai/Applications/Embarcadero/RADPAServer/10.0/paserver ; exit;
macosx:~ kotai$ /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/paserver ; exit;
Platform Assistant Server Version 2.0.7.05
Copyright (c) 2009-2012 Embarcadero Technologies, Inc.


Remote Profile password <press Enter for no password>:


Acquiring permission to support debugging...succeeded


Starting Platform Assistant Server on port 64211


Type ? for available commands
>listen
Process Control Server Started pid 341 exe built Aug 21 2012
sentinelFunc 343
objc[345]: Class SDLAppDelegate is implemented in both /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego//SDL2 and /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego/../Frameworks/SDL2.framework/Versions/A/SDL2. One of the two will be used. Which one is undefined.
objc[345]: Class SDLTranslatorResponder is implemented in both /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego//SDL2 and /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego/../Frameworks/SDL2.framework/Versions/A/SDL2. One of the two will be used. Which one is undefined.
objc[345]: Class Cocoa_WindowListener is implemented in both /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego//SDL2 and /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego/../Frameworks/SDL2.framework/Versions/A/SDL2. One of the two will be used. Which one is undefined.
objc[345]: Class SDLWindow is implemented in both /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego//SDL2 and /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego/../Frameworks/SDL2.framework/Versions/A/SDL2. One of the two will be used. Which one is undefined.
objc[345]: Class SDLView is implemented in both /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego//SDL2 and /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego/../Frameworks/SDL2.framework/Versions/A/SDL2. One of the two will be used. Which one is undefined.
objc[345]: Class SDLMessageBoxPresenter is implemented in both /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego//SDL2 and /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego/../Frameworks/SDL2.framework/Versions/A/SDL2. One of the two will be used. Which one is undefined.
dyld: lazy symbol binding failed: Symbol not found: SDL_Init
Referenced from: /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego/juego
Expected in: /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego//SDL2


dyld: Symbol not found: SDL_Init
Referenced from: /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego/juego
Expected in: /Users/kotai/Applications/Embarcadero/RADPAServer/10.0/scratch-dir/Vicent-MacOSx/juego//SDL2




I think problem is SDL2.pas:



{$IFDEF MACOS}
SDL_LibName = 'SDL2';
// {$linklib SDL2}
{$ENDIF}



I comment line {$linklib SDL2} because Delphi does not recognize that command $linklib

Kotai

[User137]

I comment line {$linklib SDL2} because Delphi does not recognize that command $linklib
If it's FPC specific command, you can do

{$IFDEF fpc}{$linklib SDL2}{$ENDIF}

[kotai]

Thanks @User137.
In Delphi what command I need use for load external library or framework in OSX ?
I use:


function FName(FParams):FType cdecl; external LibraryName;


like:


function SDL_Init(flags: UInt32): SInt32 cdecl; external SDL2;

But not work in OSX, not found function SDL_Init
Thanks

[End]

Thanks @User137.
In Delphi what command I need use for load external library or framework in OSX ?
I use:


function FName(FParams):FType cdecl; external LibraryName;


like:


function SDL_Init(flags: UInt32): SInt32 cdecl; external SDL2;

But not work in OSX, not found function SDL_Init
Thanks

I don't know, since i have no mac os. may s.o. can help me?

[End]

Well, StoneyFD says it works now with MacOS, try it with the new Release.

[kotai]

Hi

Thanks for update SDL2. I update my version with your updates except modular, I like more all in same file.
I add SDL_messagebox.h:


////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////// SDL_messagebox.h ////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////


const


//SDL_MessageBoxFlags;
SDL_MESSAGEBOX_ERROR = $00000010; //**< error dialog */
SDL_MESSAGEBOX_WARNING = $00000020; //**< warning dialog */
SDL_MESSAGEBOX_INFORMATION = $00000040; //**< informational dialog */


//SDL_MessageBoxButtonFlags;
SDL_MESSAGEBOX_BUTTON_RETURNKEY_DEFAULT = $00000001; //**< Marks the default button when return is hit */
SDL_MESSAGEBOX_BUTTON_ESCAPEKEY_DEFAULT = $00000002; //**< Marks the default button when escape is hit */


function SDL_ShowSimpleMessageBox(flags : Uint32; const title : PAnsiChar; const message : PAnsiChar; window : PSDL_Window): UInt32 cdecl; external {$IFDEF GPC} name 'SDL_ShowSimpleMessageBox' {$ELSE} SDL_LibName {$ENDIF};




And support for load and save BMP in surfaces form TmemoryStream for copy TPicture.TBitmap to surface and viceversa.

I test again to compile for MAC and have same problem:


dyld: lazy symbol binding failed: Symbol not found: SDL_Init

I search in embarcadero help and I see all functions in OSX need begin with "_".
I rename SDL_Init function to _SDL_Init and ;D WORK OK !!!!
I rename several functions and now I can create windows and renderer in OSX.

But now not compile with win32/win64:


Not found the procedure entry point _SDL_Init in the dynamic link library.


I do not know how to make function that add "_ " before name function for MACOS.
I would like the name of the function is always "SDL_Init" but when I compile for MACOS renamed for "_SDL_Init"

Thanks.

[AirPas]

with FPC maybe ( public name ) helps

[kotai]

I not use FPC, I use DelphiXE4 and I like compile SDL2 to WIN32, WIN64, OSX and IOS (and Android when DelphiXE5 relased)

This is article by embarcadero:
http://docwiki.embarcadero.com/RADStudio/XE4/en/Cross-Platform_Shared_Libraries

I like call always to function SDL_Init in my games/engine and if destination is OSX autimatically rename it to _SDL_Init.

I can make this:



interface {$IFDEF MACOS}function _SDL_Init(flags: UInt32): SInt32 cdecl; external {$IFDEF GPC} name 'SDL_Init' {$ELSE} SDL_LibName {$ENDIF};
{$ELSE}
function SDL_Init(flags: UInt32): SInt32 cdecl; external {$IFDEF GPC} name 'SDL_Init' {$ELSE} SDL_LibName {$ENDIF};
{$ENDIF}

But I don't like, because in games/engine I need call to SDL_Init or _SDL_Init and I like call allways to SDL_Init regardless of platform

[kotai]

This is article by embarcadero:
http://docwiki.embarcadero.com/RADStudio/XE4/en/Cross-Platform_Shared_Libraries

I like call always to function SDL_Init in my games/engine and if destination is OSX autimatically rename it to _SDL_Init.

I can make this:



interface
{$IFDEF MACOS}
function _SDL_Init(flags: UInt32): SInt32 cdecl; external;
{$ELSE}
function SDL_Init(flags: UInt32): SInt32 cdecl; external;
{$ENDIF}


But I don't like, because in games/engine I need call to SDL_Init or _SDL_Init and I like call allways to SDL_Init regardless of platform

[kotai]

I found a solution:



function SDL_Init(flags: UInt32): SInt32 cdecl; external SDL_LibName {$IFDEF MACOS} name '_SDL_Init' {$ENDIF};


I will delete all {$IFDEF GPC} name 'XXX' {$ELSE} SDL_LibName {$ENDIF};
and I will use {$IFDEF MACOS} name '_XXX' {$ENDIF};
I not need compile with GNU Pascal Compliler, I need compile only with DelphiXE4

Kotai :-[

[kotai]

This is my SDL2 for Delphi XE4 with support for MACOS: http://www.remakesonline.com/descargas/SDL2.zip

Only work with latest SDL2 library (Sun Aug 18 2013) because SDL_CreateWindow now return new param between "title" and "x" param ¿?.

It include:


sdl2.inc
SDL2.pas
SDL2_Image.pas
SDL2_Mixer.pas
SDL2_Net.pas
SDL2_Ttf.pas


Kotai

[End]

Now my headers should work with Delphi + MacOS, too. Could you test them, kotai?

[kotai]

Hi.

I don't test (I use last sdl.dll and I have more functions and my test program not work) but I think it not work because you can no add "_" at begin of function names:

My SDL:


function SDL_Init(flags: UInt32): SInt32 cdecl; external SDL_LibName {$IFDEF MACOS} name '_SDL_Init' {$ENDIF};


Your SDL:


function SDL_Init(flags: UInt32): SInt32 cdecl; external SDL_LibName {$IFDEF DELPHI} {$IFDEF MACOS} name 'SDL_Init' {$ENDIF} {$ENDIF};


In name '_SDL_Init' you put name 'SDL_Init' without "_"

Kotai.

[End]

fixed.