A week's romp with SDL

Discussion in 'Discussions' started by Kaidelong, Aug 25, 2012.

  1. Kaidelong

    Kaidelong Member

    Thought I would just speak my mind here since Nicholas was the one who finally made me attack it:

    What I've been doing:

    Most of my early time was spent figuring out how I was going to deploy a SDL application easily on both linux and windows. In the end I settled on .NET as being the least nightmarish option. More on why later. I've spent my time writing reactive versions (via Rx) of all the SDL events, after making a few demo applications run directly against cs-sdl's exposed .NET events. I've confirmed that the reactive layer is working as well, but I'll need to make an actual complicated... thing... probably a game, to test how well it works.

    The Good:

    It really is simple. SDL is absolutely tiny. Well okay, it's not, but by the standards of "how many hoops do you need to jump through to draw a pixel on a screen" it's stellar compared to all the other options I've tried. There's only about four hoops or so, in fact, from memory: initialize, set the display mode, create a surface, blit it onto the buffer, update the screen. Okay so five hoops. I'm still rather amazed after coming from Win32 and GLUT land. Definitely much better.

    So far, I haven't been surprised by any of the SDL functions, this might just be luck on my part but they mostly seem to work how you expect. I've found this to be amazingly rare in practice, so it is refreshing not to have struggled with bizarre behavior here (in fact, so far, only Rx gave me this kind of problem, and then made it worse giving me an awkward runtime exception instead of a type error).

    SDL, when deployed, only requires SDL's libraries to be deployed with your application. This isn't terribly unusual but you do not have to do anything like run the DirectX installer first when you first launch the game, or point the user to a smalltalk VM, or some other fancy thing like that.

    The Bad:

    SDL is made for blitting raster graphics. I'm writing this post on a very unconventional netbook screen right now. Other people may be on 1080p or on tiny 4:3 screens. This worries me a little.

    The unfortunately common pattern of a few big functions that each take a ton of parameters to give you different permutations of results is followed loyally here, with bool arguments and flags galore. A real time waster, I am surprised it is done so often; it increases the need to pass pointless parameters and makes the resulting code less self documenting.

    The Ugly:

    It irks me that geometry and loading of image formats other than bitmaps are not built in to SDL itself. Is a libpng dependency really that bad?

    It also irks me that SDL loads bitmaps from a filename. Is all that IO really needed to store a bitmap in a surface? What about transient bitmaps for which you have little reason to ever put them on a disc, but which you still need to display? In particular, it'd make it much more sensible to try to adapt SDL to work with vector graphics if you weren't passing filenames.

    SDL itself has a mingw32 binary available. sdl_image, sdl_ttf, and a myriad other essential extra libraries do not. I've yet to get them to build against mingw32 from source.

    You must pull events with a central game loop. Very ugly, but I guess this is the C way of doing things. Fortunately, on .NET, cs-sdl completely hides this away and lets you have .NET events instead, which push to callbacks.

    On the inverse, surfaces need to be pushed to by blitting on them in a game loop. Am I perhaps too spoiled by Haskell? Not very nice, but covering this up with some new abstraction is my next goal after wiring up all the events to Rx.


    All in all so far I'm enjoying it a fair deal now that I've started using cs-sdl, but I'm probably going to hide it behind some other abstraction rather than working with it directly, as it has proven to be pretty low level so far.
     
    Kazeto and OmniNegro like this.
  2. OmniaNigrum

    OmniaNigrum Member

    To be honest, I have only dabbled in a half dozen programming languages. I understand most of what you are saying, but a few things still baffle me. .NET was made by Microsoft, yet you are using it in conjunction with SDL and this is a solution for Linux too? Or am I missing something? Is there a .NET emulator for Linux now?
     
  3. delta534

    delta534 Member

    Yes, it is called mono.

    Personally I am not a big fan of SDL for reason's you've stated. I prefer SFML over SDL because it solves a lot of my issues with SDL.
     
    OmniNegro likes this.
  4. Nicholas

    Nicholas Technology Director Staff Member

    False - it also provides an interface for OpenGL (which is what we're using for Odin.) You can use SDL's input stuff to do all your cross platform input and audio, and then drive GL graphics as per usual.

    Yes, because once you go down that path you also start bundling JPEG loaders, PNG loaders, TIFF loaders, EPS loaders, god knows what else, and you get a big block of goo. I think the BMP stuff is just there so you can do something quickly and easily. If you want a good loader, look at Sean Barrett's stb_image, which I replaced SDL_Image with in Dredmor and need to do to Odin as well, because... well, SDL_Image craps out on OS X a bunch.

    Use RWops.
     
    Kazeto and OmniNegro like this.
  5. Kaidelong

    Kaidelong Member

    Have any recommendation on a 3D engine to use for that?
     
  6. Nicholas

    Nicholas Technology Director Staff Member

    We wrote our own. :D
     
  7. OmniaNigrum

    OmniaNigrum Member

    I have never written an original program besides a few tiny snippets unworthy of posting anywhere under the sun, but I think the Unity Engine used by Wazhack may work very well as a 3D engine. It uses full OpenGL ES as the renderer by default, and is fully open so you can not only see how it works, but can even change it. Licensing is a gray area that I do not yet understand. It *May* cost to use it, or it may be free like it is for the end users.

    Here is the actual site of the engine:
    https://unity3d.com/unity/

    I am really impressed with it. I expected Wazhack to play like Java-built excrement. But it played smooth as butter.
     
  8. Kaidelong

    Kaidelong Member

    Unity is what we were looking at ourselves, I figured I'd ask here anyway though since Nicholas has experience doing 3D SDL stuff.

    Likely though our first effort will just use SDL's raster graphics. We have a mock up of the basic map structure and how walls look, all boring and gray. Rendering something that vaguely resembles the mock up would be a first step.

    Also although you got the answer you want, just to clarify to you, mono doesn't emulate .NET so much as it re-implements it. Which, considering that the .NET CLR is standardized (looking at you, java), is unsurprising and exactly what the .NET team intended to happen.
     
    OmniNegro likes this.
  9. OmniaNigrum

    OmniaNigrum Member

    Thanks for the clarification. .NET is not like the awful monster named Java! Hallelujah!