Page 2 of 7 FirstFirst 1234 ... LastLast
Results 11 to 20 of 64

Thread: SDL 2.0 Headers for [Object] Pascal?

  1. #11
    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?

  2. #12
    Quote Originally Posted by Darkhog View Post
    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 ...
    Last edited by Cybermonkey; 13-06-2013 at 01:28 PM.
    Best regards,
    Cybermonkey

  3. #13
    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.

  4. #14
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    Quote Originally Posted by Darkhog View Post
    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.
    Jason McMillen
    Pascal Game Development
    Co-Founder





  5. #15
    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.

  6. #16
    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.

  7. #17
    Quote Originally Posted by Darkhog View Post
    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.

  8. #18
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    Quote Originally Posted by Murmandamus View Post
    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.

    Quote Originally Posted by Murmandamus View Post
    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.
    Jason McMillen
    Pascal Game Development
    Co-Founder





  9. #19
    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.

  10. #20
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    Quote Originally Posted by Murmandamus View Post
    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.

    Quote Originally Posted by Murmandamus View Post
    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.
    Jason McMillen
    Pascal Game Development
    Co-Founder





Page 2 of 7 FirstFirst 1234 ... LastLast

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •