haskell-game / sdl2 Goto Github PK

As it is, it accepts a (Data.Vector.Storable.Vector Word8) as it's "pixel data" argument, and the implementation uses 'unsafeWith' to get the underlying memory pointer, in order to pass it to SDL_CreateRGBSurfaceFrom. However, https://wiki.libsdl.org/SDL_CreateRGBSurfaceFrom says:

"No copy is made of the pixel data. Pixel data is not managed automatically; you must free the surface before you free the pixel data."

Moreover, the SDL Surface API assumes that this surface memory may be mutated (see https://wiki.libsdl.org/SDL_LockSurface).

So, obviously this is wrong. There are several paths we could go here, and I'm not sure which is best:

1. The interface remains as is, and a copy of the memory is made internally. The high-level Surface object keeps a reference to this memory and it is be freed appropriately from "destructors".

2. The interface is changed to a MVector (mutable vector). The Surface object keeps a reference to the mutable vector to avoid it's garbage collection. The documentation should mention something about locking the surface for mutation.

3. The interface is changed to a Ptr, no references are kept, the documentation should state clearly that the user must manage memory manually.

So far, (2) looks best to me, however, I'm not at all familiar with MVector and so may miss an obvious issue with this approach. (1) seems wasteful, and (3) too low-level. And of course, there probably is some better way. Opinions?

Take the following program:

{-# LANGUAGE OverloadedStrings #-}

module Main where

import Linear
import qualified SDL

width, height :: Int
width = 1280
height = 720

main :: IO ()
main =
  do SDL.initializeAll
     w <-
       SDL.createWindow
         "bgfx with SDL2"
         SDL.defaultWindow {SDL.windowInitialSize =
                              fromIntegral <$> V2 width height}
     return ()

When compiled with the following cabal Executable all is well:

executable on-the-limit
  main-is:             Main.hs
  build-depends:       base >=4.8 && <4.9, sdl2, linear
  hs-source-dirs:      src
  default-language:    Haskell2010

However, if a build-dependency on libusb is added:

executable on-the-limit
  main-is:             Main.hs
  build-depends:       base >=4.8 && <4.9, sdl2, linear
  hs-source-dirs:      src
  default-language:    Haskell2010
  pkgconfig-depends: libusb-1.0 >= 1.0.16

Then the program will segfault.

Are there plans to support sdl2_ttf et al.? In particular I would like to load fonts and render text, but I don't believe it has been implemented yet.

What do people think about renaming things in SDL.Video.Renderer so we have things like clear instead of renderClear?

That's the "press s to fade out" / "press w to fade in" one. Pressing S once goes all the way to the full fade, pressing W does nothing ever.

It looks like the problem is not anywhere in the loop's math, at least putStrLn $ show alphaAdjustment just above the recursion shows 32/-32 on appropriate keypresses even when the render window isn't responding.

This is not an issue, I'm just unsure where to post this. Feel free to move it.

First of all, congratulations on the release of sdl2-2.0.0. We have some really nice improvements here.

I would like to talk about the state of the various SDL2 sub-libraries.
So far the most used ones are:

• sdl2_image
• sdl2_ttf
• sdl2_mixer
• sdl2_net
• sdl2_gfx

There are existing wrappers for those ones. Some are not on Hackage, some are but relies on sdl2-1.3.1.
And so on. Some work have been started, for example by @sbidin, he updated his libs to work with the current version of sdl2.

I'm not sure what is the best way to deal with this, like contacting old library mainteners or starting doing them on our own. They should have the same treatment that you guys did for the sdl2 one. I think it would be awesome to have those wrappers inside haskell-game and Hackage.

Please tell me what do you guys think about this.

I am willing to help doing them.

I am writing a game library using sdl2 (timeless-RPG). This is a really nice library wrapped around SDL2! Are there any plans to support other modules?

Thanks

At the moment, surfaceColorKey has the signature of surfaceColorKey :: Surface -> StateVar (Maybe Word32). This is probably because it should use a colour key in the pixel format of the surface, and the function that does that returns a Word32.

Possible fixes are:

• Make surfaceColorKey use V4 Word8 and retrieve the pixel format under the hood, since the surface is being passed as a parameter anyways
• Mandate the usage of the surface's pixel colour format by using an opaque data type
• Mention this in the docs for surfaceColorKey

I've built latest (from git) audioExample with GHC 7.10.3 and sdl2 2.1.1 version (from NixOS repos).

When I run it in ghci (cabal repl) it works almost well, but there is some glitches with sound. But when I try to run compiled version (cabal run), there are 3 different ways it fails:

It plays a sound for a second or shorter and freezes, so I can only kill it

Second way is this one:

audioExample: internal error: audioExample: internal error: scavenge: unimplemented/strange closure type 41049 @ 0x7f30e29f1fa8
(GHC version 7.10.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
scavenge: unimplemented/strange closure type 41049 @ 0x7f30e29f1fa8
(GHC version 7.10.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
zsh: abort cabal run`

And the last one -- just segfault.

What should I do? Check my sdl2 lib, GHC or something else?

According to the C docs, SDL_BlitSurface returns the clipped destination rectangle in case of dstrect != NULL. Even though fixing this implies a certain performance penalty because of the additional peek it should nevertheless be done in order to be compatible with the original library (or shouldn't it perhaps?).

....
Loading package primitive-0.5.2.1 ... linking ... done.
Loading package reflection-1.5.1 ... linking ... done.
Loading package split-0.2.2 ... linking ... done.
Loading package vector-0.10.9.1 ... linking ... done.
Loading package lens-4.5 ... linking ... done.
Loading package linear-1.10.1.2 ... linking ... done.
Loading object (static) dist/build/cbits/sdlhelper.o ... /usr/bin/ld: dist/build/cbits/sdlhelper.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
dist/build/cbits/sdlhelper.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

It seems the github repo is already at this point. This issue is just a reminder to cut a release to hackage. sdl2 is one of the final puzzle pieces to upgrading lens and linear on stackage nightly. See commercialhaskell/stackage#832

This Reddit post contains a description of how to get sdl2 installed under Windows. I don't know if this is the expected process, but if it is, we should add it to the README, and maybe the description field in the Cabal file (so it is very prominent on http://hackage.haskell.org/package/sdl2).

This is more of a comment than an issue but still worth bringing to your attention.

I'm currently working on a game that targets both iOS and Android. I am using an older binding to SDL2.
Today I tried to build the new-api branch and found that the dependency on package 'linear' introduces
a whole stack of extra dependencies. Normally I wouldn't care about this but I've found that in cross-compiling environments a lot of packages don't just build "out of the box".

Seeing at this library is intended to be used for building games in in Haskell, and one might want to target a mobile devices (necessitating a cross-compilation environment) this is something to keep in mind.

...because the raw texture pointer type is used by SDL.Raw.lockTexture. Thanks!

For example, this page:

https://hackage.haskell.org/package/sdl2-1.3.1/docs/src/Graphics-UI-SDL.html

is missing.

To get a quick glimpse at what's there and what's missing I've grepped through Raw and roughly compared that with grepping through the other modules. Here [1] is a quick overview of the "missing symbols" so far. Feel free to close this issue ;-)

[1] https://gist.github.com/anonymous/4c0475fcb28d55dbc23b

Crossposting HeinrichApfelmus/reactive-banana#103, I'll update this ticket tomorrow with a more minimal example.

Neither Ubuntu nor Debian have packages for 2.0.3 in their latest releases (so Mint probably doesn't have it, either), and according to https://hg.libsdl.org/SDL/file/e12c38730512/WhatsNew.txt#l96 there is no need for them to upgrade, because 2.0.2 => 2.0.3 fixed only a Mac OS X issue. To make things much, much easier for users of the top 3 used Linux distros, it would be good to lower pkgconfig-depends: from sdl2 >= 2.0.3 to sdl2 >= 2.0.2.

(Yes, I know how to install newer SDL2 versions by hand, but that't not the point here. 😉 )

All modules should use MonadIO constraints instead of explicitly returning IO. One or more modules need to be adapted accordingly, such as SDL.Video.

The idea is to move SDLException and the associated error checks of SDL's functions' return values to the low-level bindings (SDL.Raw and Graphics.UI.SDL).

Advantages include:

• The user does not have to explicitly check the return value of almost every SDL function invocation.
• It is less error-prone as we can be more certain that we haven't left any needed error checks out in both the high-level bindings and other application code.

One disadvantage I have been able to conceive is if a user wants to completely ignore the error checking. I have, however, not yet been able to think of any circumstances where this is desirable.

Any comments?

In order to migrate away from the SDL haskell package to SDL2 and your bindings, I would need SDL_mixer bindings. Do you have any plans to support that?

Thanks,
Joachim

Can anyone confirm? cabal-install produces the following error:

$ cabal install sdl2-2.1.1 --dry-run
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: sdl2-2.1.1 (user goal)
trying: vector-0.11.0.0/installed-6uB... (dependency of sdl2-2.1.1)
next goal: primitive (dependency of vector-0.11.0.0/installed-6uB...)
rejecting: primitive-0.6.1.0/installed-Ip4... (conflict: primitive =>
transformers==0.5.2.0/installed-0.5..., sdl2 => transformers>=0.2 && <0.5)
rejecting: primitive-0.6.1.0, primitive-0.5.4.0, primitive-0.5.3.0,
primitive-0.5.2.1, primitive-0.5.1.0, primitive-0.5.0.1, primitive-0.5,
primitive-0.4.1, primitive-0.4.0.1, primitive-0.4, primitive-0.3.1,
primitive-0.3, primitive-0.2.1, primitive-0.2, primitive-0.1, primitive-0.6
(conflict: vector => primitive==0.6.1.0/installed-Ip4...)
Dependency tree exhaustively searched.

This rejection of primitive >= 0.6 seems to have its origin in the linear package.

Please, dear sdl2 author(s): whilst I see the theoretical beauty of using an external data type for point and color vectors (e.g. V2 or V4 of linear): the linear package is absolute bloatware defining myriads of instances completely unnecessary to your use case. Furthermore it depends on lens for no good reason except to save a little bit of boilerplate in its source text, without improving its (human-)readability at all in any way.

This is the already the second time, this combo of linear + sdl2 blows up in my face during the last 3 months. The last time I wrote a castrated (i.e., removing offending/unsatisfiable dependencies) drop-in fork (see my account on github) of linear, removing a lot of code in the process, showing that it's an absolute overkill to use in this case (I'm using sdl2 in production).

I urge you, I beg you, dear authors: get rid of that package. For sdl2's use case, it's overkill. Anyone using some engine on top of SDL2 rendering, will have their own data types + instances + algorithms anyway (or indeed be using linear), to do the math, and then convert to sdl2's types.

Please please please please please please please please get rid of it. It doesn't add value, it just adds pain.

For example (after fixing import SDL):

[nix-shell:~/src/sdl2/examples/lazyfoo]$ ghc --make Lesson43.hs
[1 of 1] Compiling Lazyfoo.Lesson43 ( Lesson43.hs, Lesson43.o )
Lesson43.hs:23:43:
    Not in scope: type constructor or class ‘SDL.TextureAccess’
Lesson43.hs:23:67:
    Ambiguous occurrence ‘Texture’
    It could refer to either ‘Lazyfoo.Lesson43.Texture’,
                             defined at Lesson43.hs:21:1
                          or ‘SDL.Texture’,
                             imported from ‘Graphics.UI.SDL’ at Lesson43.hs:15:1-22
                             (and originally defined in ‘Graphics.UI.SDL.Types’)
Lesson43.hs:24:59: Not in scope: data constructor ‘SDL.RGBA8888’
Lesson43.hs:26:34:
    Ambiguous occurrence ‘Texture’
    It could refer to either ‘Lazyfoo.Lesson43.Texture’,
                             defined at Lesson43.hs:21:1
                          or ‘SDL.Texture’,
                             imported from ‘Graphics.UI.SDL’ at Lesson43.hs:15:1-22
                             (and originally defined in ‘Graphics.UI.SDL.Types’)
Lesson43.hs:26:45:
    Ambiguous occurrence ‘Point’
    It could refer to either ‘Linear.Affine.Point’,
                             imported from ‘Linear.Affine’ at Lesson43.hs:14:1-20
                          or ‘SDL.Point’,
                             imported from ‘Graphics.UI.SDL’ at Lesson43.hs:15:1-22
                             (and originally defined in ‘Graphics.UI.SDL.Types’)
Lesson43.hs:26:69:
    Not in scope: type constructor or class ‘SDL.Rectangle’
Lesson43.hs:26:116:
    Ambiguous occurrence ‘Point’
    It could refer to either ‘Linear.Affine.Point’,
                             imported from ‘Linear.Affine’ at Lesson43.hs:14:1-20
                          or ‘SDL.Point’,
                             imported from ‘Graphics.UI.SDL’ at Lesson43.hs:15:1-22
                             (and originally defined in ‘Graphics.UI.SDL.Types’)

Lesson43.hs:29:23: Not in scope: data constructor ‘SDL.Rectangle’

Lesson43.hs:33:30: Not in scope: data constructor ‘SDL.Rectangle’

Lesson43.hs:38:44:
    Ambiguous occurrence ‘Texture’
    It could refer to either ‘Lazyfoo.Lesson43.Texture’,
                             defined at Lesson43.hs:21:1
                          or ‘SDL.Texture’,
                             imported from ‘Graphics.UI.SDL’ at Lesson43.hs:15:1-22
                             (and originally defined in ‘Graphics.UI.SDL.Types’)

Lesson43.hs:44:3: Not in scope: ‘SDL.initialize’

Lesson43.hs:44:19: Not in scope: data constructor ‘SDL.InitVideo’

Lesson43.hs:46:26:
    Not in scope: data constructor ‘SDL.HintRenderScaleQuality’

Lesson43.hs:46:53: Not in scope: data constructor ‘SDL.ScaleLinear’

Lesson43.hs:53:7: Not in scope: ‘SDL.defaultWindow’

Lesson43.hs:53:26:
    ‘SDL.windowSize’ is not a (visible) constructor field name

Lesson43.hs:60:8:
    Not in scope: data constructor ‘SDL.RendererConfig’
    Perhaps you meant ‘SDL.RendererInfo’ (imported from Graphics.UI.SDL)

Lesson43.hs:61:12:
    ‘SDL.rendererAccelerated’ is not a (visible) constructor field name

Lesson43.hs:62:12:
    ‘SDL.rendererSoftware’ is not a (visible) constructor field name

Lesson43.hs:63:12:
    ‘SDL.rendererTargetTexture’ is not a (visible) constructor field name

Lesson43.hs:64:12:
    ‘SDL.rendererPresentVSync’ is not a (visible) constructor field name

Lesson43.hs:69:71:
    Not in scope: data constructor ‘SDL.TextureAccessTarget’

Lesson43.hs:81:21: Not in scope: ‘SDL.eventPayload’

Lesson43.hs:90:43: Not in scope: data constructor ‘SDL.Rectangle’

Lesson43.hs:94:36: Not in scope: data constructor ‘SDL.Rectangle’

I'm trying to profile my project which depends on sdl2 and am running into a compilation error. It looks like stack or cabal can't find sdlhelper.p_o:

stack build --executable-profiling --library-profiling --ghc-options="-fPIC -threaded -Wall -fprof-auto -rtsopts -with-rtsopts=-N"
sdl2-2.1.2: configure
sdl2-2.1.2: build
Progress: 1/3
--  While building package sdl2-2.1.2 using:
      /Users/schell/.stack/setup-exe-cache/x86_64-osx/setup-Simple-Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:sdl2 --ghc-options " -ddump-hi -ddump-to-file"
          Process exited with code: ExitFailure 1
              Logs have been written to: /Users/schell/Code/odin/.stack-work/logs/sdl2-2.1.2.log

                  Configuring sdl2-2.1.2...
                      Preprocessing library sdl2-2.1.2...
                          ar: .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/cbits/sdlhelper.p_o: No such file or directory

I initially tried without using "-fPIC" and then figured it's worth a shot. Kinda thrashing - but there's no difference in output.

The logs simply list the above error.

SDL.hs has the following example:

{-# LANGUAGE OverloadedStrings #-}
module Main where

import SDL
import Linear (V4(..))
import Control.Monad (unless)

main :: IO ()
main = do
  initialize [InitEverything]
  window <- createWindow "My SDL Application" defaultWindow
  renderer <- createRenderer window (-1) defaultRenderer
  appLoop renderer

appLoop :: Renderer -> IO ()
appLoop renderer = do
  events <- pollEvents
  let eventIsQPress event =
        case eventPayload event of
          KeyboardEvent keyboardEvent ->
            keyboardEventKeyMotion keyboardEvent == Pressed &&
            keysymKeycode (keyboardEventKeysym keyboardEvent) == KeycodeQ
          _ -> False
      qPressed = not (null (filter eventIsQPress events))
  rendererDrawColor renderer $= V4 0 0 255 255
  clear renderer
  present renderer
  unless qPressed (appLoop renderer)

I propose making 2 changes:

1. Change initialize [InitEverything] to initializeAll.
2. Change qPressed = not (null (filter eventIsQPress events)) to qPressed = any eventIsQPress events.

The reason for the first change is that InitEverything is deprecated, and the reason for the second is that hlint complains about the "null . filter" portion, and because I consider it simpler and more readable to use any.

If anyone is in favor of these change, I am willing to make the PR myself if needed.

I have currently exactly this problem on Windows 64: http://stackoverflow.com/questions/15996796/haskell-sdl-cant-find-mingw32-dll

building sdl2 from source and hackage is successful, but using it in a project results in a build error during linking:

Loading package sdl2-1.3.0 ...
<no location info>:
    <command line>: can't load .so/.DLL for: mingw32.dll (addDLL: could not load DLL)

<no location info>:
    ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.8.4 for x86_64-unknown-mingw32):
        Dynamic linker not initialised

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

some ideas whats the problem here or how to workaround it? A mingw32.dll does not exist, I think the lib is statically linked in and is not meant to be dynamically.

I wrote it here (fpco/minghc#28) too, because I'm using minghc 7.8.4 64bit on windows, but I think it's not minghc related.

If SDL_RENDERER_PRESENTVSYNC is set without SDL_RENDERER_ACCELERATED, SDL won't find a valid renderer. This is a new problem, possibly related to dropping OpenGL 1.x support. Not sure.
-- openfl/lime#116

However, we allow presentVsync = True, accelerated = False, which always throws an exception.

As far as i can see there is no easy way to enable antialiasing in the
documentation (as of yet). So maybe you could add something like the following:

-- | See https://wiki.libsdl.org/SDL_GLattr#multisample
enableAntialiasing :: IO ()
enableAntialiasing = do
  glSetAttribute SDL_GL_MULTISAMPLEBUFFERS 1
  glSetAttribute SDL_GL_MULTISAMPLESAMPLES 2
  return ()

I think, that a lot of users would like to see this feature and it takes a while to figure out if
you don't know these options beforehand.

The system details are:
ArchLinux x64, GHC Version 7.10.1, stage 2 booted by GHC version 7.8.4, cabal-install version 1.22.2.0.

I have removed all previous libraries to avoid possible package corruption. All libraries were installed in a fresh install of GHC and Cabal. And compiling "sdl2/examples/lazyfoo/Lesson01.hs" gives the error:

src/App/Main.hs:7:18:
Could not find module ‘SDL’
Use -v to see a list of the files searched for.

I used 2.0.4 to compile sdl2 and compile my project without any problems. We may want to put this info in the README, which currently specifies == 2.0.3.

When importing SDL the following program will no longer print anything:

module Main
    where

import qualified SDL

main :: IO ()
main = print "5"

Removing the SDL import will print as expected. My linux box's 256MB of ram is insufficient to compile the bindings so I'm assuming this issue is Windows only otherwise someone would have already noticed. I installed the bindings on Windows with these steps.

Most likely the stdout/stderr (and probably stdin) handles are getting clobbered somewhere, causing the apparent no-op? Replacing the print in the above program w/ trace similarly yields no output. Not that familiar w/ the FFI, but do the handles need to be explicitly preserved when interfacing w/ C code (e.g. SDL2)? Creating new file handles and reading/writing to them do not have any issues w/ the SDL import, fwiw

A complete build log that shows the error is at http://hydra.cryp.to/build/246041/nixlog/2/raw.

What do people think about this:

newtype RenderM a = RenderM { runRenderM :: Renderer -> IO a }
  deriving (Monad, Functor, Applicative, MonadReader Renderer, MonadIO, etc)

The idea being that when you're working with a renderer almost everything needs a pointer to the renderer, which is a lot of annoying plumbing. Maybe it's nicer to abstract this out with a reader monad?

I would like to get the pixel information of a surface (i.e. I have a surface and coordinates (x,y), I want to get the color of that pixel.

I don't think it is possible with sdl2 bindings as now. Or am I wrong?

I sketched out SDL.Hints for Lazyfoo tutorials, but didn't implement all hints. Need to do this.

When a window's mode is Fullscreen, it is not possible to switch to windowed by calling
setWindowMode window Windowed.

As far as I can tell, the reason is that setWindowMode calls Raw.restoreWindow which does nothing on fullscreen windows.

Some possible solutions:

• Call Raw.setWindowFullscreen w 0 and then Raw.restoreWindow w.
• Add another WindowMode, e.g. Restore (but that kinda defeats the reuse for WindowConfig)
• Simply add a non raw call to restoreWindow and setWindowMode only uses setWindowFullscreen

$ cabal install --only-dependencies
Resolving dependencies...
Notice: installing into a sandbox located at
C:\Users\phaazon\dev\quine\.cabal-sandbox
Configuring sdl2-1.3.0...
Failed to install sdl2-1.3.0
Build log ( C:\Users\phaazon\dev\quine\.cabal-sandbox\logs\sdl2-1.3.0.log ):
Configuring sdl2-1.3.0...
setup-Simple-Cabal-1.22.1.1-i386-windows-ghc-7.8.3.exe: The program
'pkg-config' version >=0.9.0 is required but it could not be found.
cabal.exe: Error: some packages failed to install:
sdl2-1.3.0 failed during the configure step. The exception was:
ExitFailure 1

I tried to install pkg-config, guess what, it doesn’t exist. :(

I am trying to build sdl2 on windows , and am getting the following error message.

C:\Users\kaervin>cabal install sdl2 --extra-include-dirs=C:\SDL2-2.0.3\include --extra-lib-dirs=C:\SDL2-2.0.3\i686-w64-mingw32\lib
Resolving dependencies...
Configuring sdl2-1.3.1...
Building sdl2-1.3.1...
Failed to install sdl2-1.3.1
Last 10 lines of the build log ( C:\Users\kaervin\AppData\Roaming\cabal\logs\sdl2-1.3.1.log ):
C:\Users\kaervin\AppData\Local\Temp\sdl2-1.3.1-8956\sdl2-1.3.1\dist\doc\html\sdl2
doesn't exist or isn't a directory
sdl2-1.3.1: library-dirs: /usr/local/cross-tools/i686-w64-mingw32/lib is a
relative path which makes no sense (as there is nothing for it to be relative
to). You can make paths relative to the package database itself by using
${pkgroot}. (use --force to override)
sdl2-1.3.1: include-dirs: /usr/local/cross-tools/i686-w64-mingw32/include/SDL2
is a relative path which makes no sense (as there is nothing for it to be
relative to). You can make paths relative to the package database itself by
using ${pkgroot}. (use --force to override)
cabal: Error: some packages failed to install:
sdl2-1.3.1 failed during the building phase. The exception was:
ExitFailure 1

I already have pkg-config installed and it seems to be working.
I am following the steps provided here:
http://stackoverflow.com/questions/25635043/installing-sdl-on-windows-for-haskell-ghc

When you try to get the BlendMode of a texture that has BlendNone and then reassign it, you will crash your program with the following error message:

test: fromNumber<BlendMode>: unknown blend mode: 0

The problem is an error in the instance declaration of FromNum, where the pattern for SDL_BLENDMODE_NONE is not caught by the case expression.

I will issue a pull request that will solve this problem and highlight what I mean.

BTW: Thanks for the new API, you are great :)

See #97 , this has happened before. Not sure if the problem is in sdl2 itself or the Hackage buildbot.

I just installed ghc 7.10.2 and that required me to update some packages.

sdl2 then failed to build because:

linear is now 1.19.1.3
vector is now 0.11.0.0

Both seem like very minor version upgrades.
i've rebuilt, making the appropriate changes to the .cabal file and ran a very (very) basic test using
haskell-sdl2gl and things seem to work fine.

Since I'm updating the hssdl2-gfx (doing it over here, not much to see yet) library to be in line with sdl2, I'd like to reuse as much as possible. Currently I cannot re-use your clever exception techniques, which is a pity.

Possibly first put it under an Internal submodule.

Thanks for considering.

I use mostly high-level bindings everywhere in the program, and it is fine. Until I try to create a surface:

createRGBSurface :: (Functor m,MonadIO m)
                 => V2 CInt -- ^ The size of the surface
                 -> CInt -- ^ The bit-depth of the surface
                 -> V4 Word32 -- ^ The red, green, blue and alpha mask for the pixels
                 -> m Surface

I have no way to get the bit depth and mask information unless I either hard code them, or retrieve them from SDL.Raw.Types.PixelFormat. Reading the source code, I notice that there are two functions toNumber and fromNumber that converts the two. However, they are apparently not exported. Would it be a good idea to export them?

There are various parts of the SDL 2 API where we need a coordinate pair, or a vector for the size, or a vector of RGB components. How do people feel about depending on linear for this? linear has mostly established itself as the go-to vector library - with many in #haskell-game reaching for it, and also the diagrams project are now moving to it.