z0w0 / helm Goto Github PK

The plan is to eventually have an OpenGL backed 2d renderer. But I think we should just make some sort of graphics system module out of the box. This could be extended somehow so that we could have a 2d and 3d renderer. They would all return Element in the long run, or perhaps a new abstract Screen type. This would allow us to have both a 2d cairo engine and 2d OpenGL engine in the one release, with the OpenGL one marked as experimental.

There's an animation module now for animations that consist of a list of forms over time. But I think there should also be some concept of transitions in the same module, for simple things like pulsing transparency (glowing visible and invisible), moving left, etc. Bonus points for implementing these using automatons so that they can be logically combined.

Trying to compile helm-0.6.0 with cabal:

src/FRP/Helm.hs:222:108:
    Couldn't match type ‘[Char]’
                  with ‘text-1.1.1.3:Data.Text.Internal.Text’
    Expected type: glib-0.13.0.0:System.Glib.UTFString.DefaultGlibString
      Actual type: String
    In the ‘Pango.paFamily’ field of a record
    In the expression:
      Pango.AttrFamily
        {Pango.paStart = i, Pango.paEnd = j, Pango.paFamily = textTypeface}

I'm using Gtk2Hs's glib and pango versions 0.13.

import FRP.Helm hiding (green)
import qualified FRP.Helm.Window as Window

green = rgb 60 100 60

render (w, h) =
  collage w h [rect (fromIntegral w) (fromIntegral h) |> filled green |> move (half w, half h)] 
  where
    half = (/2) . fromIntegral

main = run defaultConfig $ render <~ Window.dimensions

This code results in this http://imgur.com/i5m3ET2

Will need to install SDL2 & Cairo onto the instance in the Travis config.

helm-0.7.0 will not build sdl2-1.3.0. Need to change helm's dependencies to 1.2.0 max.

SDL2 is officially released now and it looks great. I mentioned on a few issues that we should look to GLFW3, but I really think SDL2 would be a better option (no offence to the GLFW3 project - SDL2 just has more features that I think are an important if Helm is to get anywhere beyond usage for hobbyist games).

Would require either creating new bindings for SDL2, porting the SDL1 bindings to SDL2 or manually binding functions in-tree and only using the ones we need. I'm leaning towards just creating new SDL2 bindings from scratch because there is quite a big change and I feel like the SDL bindings could use a bit of fresh air.

EDIT: SDL2 bindings are being worked on by the current SDL bindings maintainer at a hackathon next week. Yay!

http://hackage.haskell.org/package/helm-0.5.0/docs/FRP-Helm.html

I guess you forgot to build the haddock documentation. :P Just made this issue in case you missed it.

While trying to build on Mint 17 using GHC 7.8.3, the build fails with exactly the same error shown here: http://hackage.haskell.org/package/helm-0.7.1/reports/1

The error seems to come from glib 0.12.5.4. glib 0.13.0.7 builds successfully on my system, so it might be a good idea to upgrade to the newer version.

Elm recently completely revamped their automaton module in favor of a more consistent design around arrowized FRP. I haven't actually seen automatons get used for stuff (although they are actually useful, just you don't necessarily need them because it's quite easy to map from signal to signal). I think we should just remove it. Thoughts?

Matrix transformations are pretty useful. Currently we just take a Cairo matrix forcing other uses to expose Cairo as a module in their build description. Sure it's nice to not abstract too much redundant stuff into Helm, but I think in this case it'd be a good idea.

Unit testing things like the color composing functions is obvious, but I'm not too sure how to automate testing the rendering functions, although it could definitely be done by creating a PNG surface, using that to render and then comparing the final output to a static PNG file.

There also needs to be benchmarking so potential optimizations can be spotted and made.

I am on OSX 10.10 and building cairo fails with an error very similar to this one:
http://hackage.haskell.org/package/helm-0.7.1/reports/1

Cairo and pango 0.13 do build, so I suggest updating them

I am trying to install Helm in a sandbox so that I can start learning and playing with Haskell. After setting up a sandbox environment and solving the simple dependency issues, I ran into one that isn't simple to a Haskell noob like me:

src/FRP/Helm/Color.hs:36:8:    
    Could not find module `GHC.Generics'
    It is a member of the hidden package `ghc-prim'.
    Perhaps you need to add `ghc-prim' to the build-depends in your .cabal file.

I followed the suggestion by cloning Helm into a subdirectory, adding "ghc-prim" to it's build-depends, and adding my local Helm clone to my project using cabal sandbox add-source. I then ran cabal update for good luck and cabal install --only-dependencies again with my fingers crossed, but I got the same error.

cabal sandbox add-source didn't produce any output, and neither cabal.sandbox.config nor my .cabal file seem to have changed, so I am suspicious that add-source failed silently. What exactly is it supposed to do?

This error message shows up in the issues of several Haskell projects (processing, statistics, pretty-show). In the processing repo, the commit that is credited with solving the issue actually did add "ghc-prim" to the build-depends section of the project cabal file. I feel like I'm so close to solving this, but I'm totally new to Haskell and Cabal, and I've gotten lost.

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1

$ cabal --version
cabal-install version 1.19.2
using version 1.19.2 of the Cabal library

FRP/Helm.hs should use StateT to manage the EngineState. I imagine most of the rendering functions could become StateT EngineState Cairo.Render ().

This will scale much better than the current solution if more (possibly mutable) fields are added to EngineState in the future.

It can't load system fonts and only uses a few builtin fonts by default. Plus trying to use different builtin fonts isn't working for me in the first place..

I think we need to use the Pango bindings which have wrappers for rendering with Cairo.

I'm getting:

[10 of 11] Compiling FRP.Helm ( src/FRP/Helm.hs, dist/dist-sandbox-473dfa24/build/FRP/Helm.o )

src/FRP/Helm.hs:222:108:
Couldn't match type ‘[Char]’
with ‘text-1.1.0.0:Data.Text.Internal.Text’
Expected type: glib-0.13.0.5:System.Glib.UTFString.DefaultGlibString
Actual type: String
In the ‘Pango.paFamily’ field of a record
In the expression:
Pango.AttrFamily
{Pango.paStart = i, Pango.paEnd = j, Pango.paFamily = textTypeface}
cabal: Error: some packages failed to install:
helm-0.6.0 failed during the building phase. The exception was:
ExitFailure 1

trying to do cabal install helm inside a cabal sandbox using GHC 7.8.3.

Getting Started:

• Introduction: done, but could be refined a bit
• Installing: needs to be a bit more straight forward and updated for 0.6. Potentially provide an installer for Windows.

Basics:

• Colors: done
• Forms and Shapes: todo, needs to show off lines as well
• Gradients: done, but could be a more interesting demo
• Signals: todo, needs to show the misc. operations for working with signals
• Input: todo, needs to show how to handle keyboard/mouse input nicely. Perhaps show how to have a way to map a number of input signals to some sort of abstract structure for simplicity too

Basics (low-prio):

• Gamepads/Joysticks: todo

Tutorials:

• Platformer: todo
• Pong: todo
• Asteroids: todo

Tutorials (low-prio):

• Time-travel: todo, something I've been thinking about doing

Seems to segfault occasionally when I CTRL^C inside a terminal running a game using the engine. From a quick GDB session it seems to be a crash in Cairo's pixel management library, so it's probably something to do with the SDL surface being invalidated so the Cairo library panics (as it depends on the SDL surface's pixel data to render into). Also, there's no proper code to handle signals (cross-platform) in place anyway.

As cabal is specifically designed for isolated testing only where security has no importance, it is necessary to advise users that they may be compromised by an attacker by installing packages with cabal.

More information can be seen here:
haskell/cabal#936

As it is unlikely the intention of the project to only be used in an isolated environment, I advise signing all the necessary packages and hosting them yourself, or finding another project that has security in mind.

The following code (taken directly from the example) fails with the error "user error (invalid value for stride)":

import FRP.Helm
import qualified FRP.Helm.Window as Window

render :: (Int, Int) -> Element
render (w, h) = collage w h [move (100, 100) $ filled red $ square 64]

main :: IO ()
main = do
        engine <- startup defaultConfig
        run engine $ render <~ Window.dimensions engine

This error does not occur when the line is changed to

render (w,h) = collage w h []

I am running Gentoo Linux with the Awesome window manager (though I don't think that the WM matters) with Cairo 0.12.5.0 and Helm 0.6.1 from hackage, tough it also fails with the latest source from git.

The Installing doc notes Cairo 1.x.x as a dependency, but Hackage says you're limited to <.13, which won't install for me (on OS X 10.9.4):

Preprocessing library glib-0.12.5.4...
gtk2hsC2hs: Error in C header file.

/usr/include/dirent.h:147: (column 10) [FATAL]
  >>> Syntax error!
  The symbol `^' does not fit here.

Should Hackage be updated, or the installation doc? If the latter, is this a known problem?

A meta-issue: the Hackage page for the latest helm has no documentation! All past versions do, but not the latest. Makes it harder than it should be to learn.

Is it possible to get a monad transformer stack over Signal? I want to pass around the current Level in a Reader, but can't seem to figure out how to do it.

There might be a better way of doing this, like maybe making a Signal Level and thread it through, but this doesn't seem particularly fun to write, and unlikely to play nicely with foldp.

Am I missing something? FRP is hard =)

Cheers!

Use of this function produces the same result as FRP.Helm.Graphics.fittedImage (i.e. given dimensions are cut out instead of picture scaled)

Did you help close this issue? Go claim the $5 bounty on Bountysource.

The examples that are both on the site and the Readme are incorrect, unfortunately.

The error when compiling the follow is:

import FRP.Helm
import qualified FRP.Helm.Window as Window

render :: (Int, Int) -> Element
render (w, h) = collage w h [move (100, 100) $ filled red $ square 64]

main :: IO ()
main = run defaultConfig $ render <~ Window.dimensions

$ ghc --make helm.hs
[1 of 1] Compiling Main             ( helm.hs, helm.o )

helm.hs:8:12: Not in scope: `defaultConfig'

Whereas the example on haddock works.

I've been following the Linux installation instructions at with a clean Fedora 20 install, and I've hit a few issues with cabal complaining of missing dependencies (alex and happy). I got them working by running cabal install alex and cabal install happy before installing gtk2hs-buildtools, but I have hit some similar issues with cabal install helm.

I'll keep working through it until I get helm working, then make a pull request with updated instructions.

I've extended the demos/gradient to also draw a line. In elm it seemed to work as expected, but in helm it doesnt draw the line. This seems like a bug to me, but correct me if I'm wrong.

render :: Time -> (Int,Int) -> Element
render _ (w,h) = collage w h [ move (250,150) $ gradient linearGrad
                                              $ rect 300 100
                             , move (500,500) $ gradient radialGrad
                                              $ circle 64
                             , move (10,10)   $ traced (solid red) $ segment (0,0) (300, 100)]

I'm having trouble installing Helm on Mavericks.

Install log and setup info: https://gist.github.com/ZachMassia/5edc0a01f51148846bc4

I found http://www.haskell.org/pipermail/haskell-cafe/2013-October/111001.html which seems to indicate a problem with glib and ghc 7.6, however I am running ghc 7.8 which should of fixed the problem.

The following is definitely low priority and possibly away from the author's intent for this library, especially considering that it doesn't mimic Elm. But I also think that this is an opportunity to make helm interface more "open world friendly", given that Haskell has a much wider public than Elm which is specific to its own web-restricted world.

Haskell's support for math with pairs is basic to say the least. This often leads the user of this library, to have to define a vector class of its own, with its own definition of Applicative, Functor and Num to make things a little better. An example is this:

data Vec2 a = Vec2 a a deriving (Eq, Show)

instance Functor Vec2 where
    fmap fn (Vec2 a b) = Vec2 (fn a) (fn b)

instance Applicative Vec2 where
    pure a = Vec2 a a
    (Vec2 fa fb) <*> (Vec2 a b) = Vec2 (fa a) (fb b)

instance (Num a) => Num (Vec2 a) where
    (+)           = liftA2 (+) 
    (*)           = liftA2 (*)
    abs           = fmap abs
    signum        = fmap signum
    fromInteger = pure . fromInteger
    negate        = fmap negate

magnitude :: Floating a => Vec2 a -> a
magnitude (Vec2 ax ay) = sqrt $ (ax ^^ (2 :: Int)) + (ay ^^ (2 :: Int))

normalize :: Floating a => Vec2 a -> Vec2 a
normalize v = liftA2 (/) v (pure . magnitude $ v)

The user will then need to define its own version of fromPair and toPair to later interact with helm.

One way to solve this would be to provide a Vec2 class for the library itself, but the user might need to use other vector data structures of their own (due to compatibility with other libraries; for example a physic library).

What if we define a simple class:

class IsVec2 vec where
    toPair     :: vec a -> (a, a)
    fromPair   :: (a, a) -> vec a

-- utility functions
getX :: IsVec2 => vec a -> a
getX = fst . toPair

getY :: vec a -> a
getY = snd . toPair

and then modify the interface so that it accepts and return any IsVec2 structure polymorphically? An example would be:

arrows' :: IsVec2 vec => Bool -> Bool -> Bool -> Bool -> vec Int
arrows' u l d r = fromPair $ (-1 * fromEnum l + 1 * fromEnum r, -1 * fromEnum u + 1 * fromEnum d)

or:

move :: IsVec2 vec => vec Double -> Form -> Form
move v f = f { formX = (getX v) + formX f, formY = (getY v) + formY f }

so the user could use move, and all the functions that currently accept or return pairs, directly with their own data structures:

move (Vec2 1 1) $ ...

In addition to this, we could provide a Math/Vector module that could contain a Vec2 data like above for the user to use directly if they have no other preferences.

The initial delta given from FRP.Helm.Time.fps, on Mac OS X 10.10 at least, is huge. With this simple program:

view :: Signal Element
view = (\i -> traceShow i $ G.collage 800 600 [G.blank]) <~ T.fps 70

main :: IO ()
main = run defaultConfig view

I get the following numbers:

1.419062936110501e12
93.72802734375
43.881103515625
16.248779296875
16.812255859375
16.7587890625
16.449951171875
16.713134765625
16.7529296875

If Helm is going to be a complete game engine it probably needs a easy way to handle audio. I've looked around and I think the best option is either SDL_mixer(http://hackage.haskell.org/package/SDL-mixer) or as someone pointed out on #haskell OpenAL(http://hackage.haskell.org/package/ALUT).

My question is, is there a need for an audio module and if so, what will be the best library, and also, could this be abstracted in a nice way using FRP?

Take care, hope it's no problem that I submit it here since there's no mailing-list or IRC channel for this project atm.

Currently Helm works like Elm does - there's no way to kill rendering (AFAIK). There needs to be some sort of state sent back as well as the Element objects used for rendering (as well as something like Sound). This state would allow you to signify that the engine should be destroyed.

I see a weird rectangle when I use this code.

simpleLine :: Position -> Position -> Form
simpleLine p1 p2 = traced s p
  where
    p = segment p1 p2
    s = solid white

render f1 f2 (w, h) = collage w h [f1,f2]

main = run defaultConfig $ do
  dimensions <- Window.dimensions
  return $ render (simpleLine (0,100) (100,200)) (move (100,100) $ filled white (circle 10)) <$> dimensions

Rendering in reversed order doesn't show the line at all.

return $ render (move (100,100) $ filled white (circle 10)) (simpleLine (0,100) (100,200)) <$> dimensions

I think a turtle/cursor drawing wrapper around Helm would be pretty interesting and useful for education. Potentially this could be a separate project on Hackage.

Did you help close this issue? Go claim the $10 bounty on Bountysource.

Helm does not need to re-render when inputs haven't changed.

See discussion here:https://groups.google.com/forum/#!topic/helm-dev/xZCffo1yboU

The $50 bounty on this issue has been claimed at Bountysource.

Form transformations don't take into account the order in which they're applied.

For instance, if I apply a scale to a moved form with scale 10 . move (1, 1) then the resulting form is 10 times bigger and at the position (10, 10), as expected, but applying them in the other order with move (1, 1) . scale 10 produces the same effect. I was expected the form to be 10 times bigger but only at position (1, 1) because the move takes place over the already scaled form.

I'm pretty sure this behaviour isn't intentional, because these operations don't propagate into groups. At the moment I can get around it by placing the scaled form into a singleton group and then moving that.

I just tried to install using "cabal install" and got an error with the dependencies:

$ cabal install
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: helm-0.6.0 (user goal)
next goal: SDL2 (dependency of helm-0.6.0)
Dependency tree exhaustively searched.

This is a general bug to organize efforts in the following areas:

• Audio support
• Timer and frame rate deltas
• Animation support or examples for it

collage should just create a collage that renders without any parent transformation, centeredCollage creates one that is centered at the middle of the dimensions and fixedCollage creates one that is centered at a specific point. It's useful for games that follow an entity around, e.g. following a player character in a side scroller.

hello,
im @ ubuntu 14.04. ghc 7.10.2.20151102, cabal 1.22.4.0. i have tried to install helm both via cabal install helm and via sandbox but without success... :-(

cabal install helm

[ 5 of 12] Compiling FRP.Helm.Automaton ( src/FRP/Helm/Automaton.hs, dist/build/FRP/Helm/Automaton.o )

src/FRP/Helm/Automaton.hs:34:9:
    Ambiguous occurrence ‘pure’
    It could refer to either ‘FRP.Helm.Automaton.pure’,
                             defined at src/FRP/Helm/Automaton.hs:40:1
                          or ‘Prelude.pure’,
                             imported from ‘Prelude’ at src/FRP/Helm/Automaton.hs:17:1-31
                             (and originally defined in ‘GHC.Base’)

src/FRP/Helm/Automaton.hs:40:23:
    Ambiguous occurrence ‘pure’
    It could refer to either ‘FRP.Helm.Automaton.pure’,
                             defined at src/FRP/Helm/Automaton.hs:40:1
                          or ‘Prelude.pure’,
                             imported from ‘Prelude’ at src/FRP/Helm/Automaton.hs:17:1-31
                             (and originally defined in ‘GHC.Base’)
cabal: Error: some packages failed to install:
helm-0.4 failed during the building phase. The exception was:
ExitFailure 1

and in sandbox (after cabal sandbox init and cabal install) it goes like:

resolving dependencies...
cabal: Could not resolve dependencies:
trying: helm-0.7.1 (user goal)
trying: base-4.8.2.0/installed-cda... (dependency of helm-0.7.1)
trying: transformers-0.4.2.0/installed-ee7... (dependency of helm-0.7.1)
next goal: mtl (dependency of helm-0.7.1)
rejecting: mtl-2.2.1, 2.2.0.1, 2.2 (conflict: helm => mtl>=2.1 && <2.2)
rejecting: mtl-2.1.3.1, 2.1.2 (conflict:
transformers==0.4.2.0/installed-ee7..., mtl => transformers==0.3.*)
rejecting: mtl-2.1.1, 2.1 (conflict: base==4.8.2.0/installed-cda..., mtl =>
base<4.6)
rejecting: mtl-2.0.1.1, 2.0.1.0, 2.0.0.0, 1.1.1.1, 1.1.1.0, 1.1.0.2, 1.1.0.1,
1.1.0.0, 1.0 (conflict: helm => mtl>=2.1 && <2.2)
Dependency tree exhaustively searched.

any help or suggestions please? :)

The contents of Graphics.UI.SDL.Enum rather radically changed in 1.3.0, and the < 2 version bound you've been using on hackage since helm 0.6.0 doesn't work.

You can now change these retroactively on hackage by using the edit package description to lower the upper bound to < 1.3. If you did this before pushing a new version, you'd have a lot fewer user install problems.

There's a demand for utility functions that don't necessarily play well with the idea of Helm being an (almost) 1<>1 port of Elm to Haskell. There should be a separate package for these sort of functions / types / classes, etc. The original animation and transition modules that were removed should also be readded to this. See #78 for an example of another function that could be added.

The width and height arguments to collage are currently ignored, for similar functionality to Elm (which I think is nice), it should center all forms and clip the dimensions.

It's only tested on Linux atm. Platforms I'd like to have a development process for:

• Linux
• Windows
• OS X
• iOS
• Android

I created a simple animation example, then added a large background to the scene. FPS dropped by a factor of 4. Profiling shows around 60% of application time spent in the getSurface function, specifically in surface <- liftIO $ Cairo.imageSurfaceCreateFromPNG src.

total time  =       16.62 secs   (16616 ticks @ 1000 us, 1 processor)
total alloc = 116,918,680 bytes  (excludes profiling overheads)

COST CENTRE     MODULE              %time   %alloc
getSurface      FRP.Helm            59.9     0.7
renderElement   FRP.Helm            23.1    18.7
render.\.\.\.\  FRP.Helm             8.6     0.2
render'         FRP.Helm             3.8     0.0
run''.\         FRP.Helm             1.1     0.0
withTransform   FRP.Helm             0.9     1.2
getKeyState.\   FRP.Helm.Keyboard    0.4    57.0
toFps           Main                 0.2     5.9
run'            FRP.Helm             0.1     7.9
times           FRP.Helm.Animation   0.0     2.8 

Investigation shows the first call to Map.lookup on each frame returns Nothing, whereas subsequent calls for the same Surface within that frame are cached correctly. On the next frame, the cache no longer holds the Surface, so we're creating Surfaces for each image file every frame.

Resolving this would provide a great performance boost for games with large assets.

I compiled the gradients example on OS X but trying to run it gives:

2013-07-25 21:49:10.425 gradients[33967:707] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1000) creating CGSWindow on line 259'
*** First throw call stack:
(
    0   CoreFoundation                      0x00007fff8fa7ab06 __exceptionPreprocess + 198
    1   libobjc.A.dylib                     0x00007fff94f5b3f0 objc_exception_throw + 43
    2   CoreFoundation                      0x00007fff8fa7a8dc +[NSException raise:format:] + 204
    3   AppKit                              0x00007fff8fd30b49 _NSCreateWindowWithOpaqueShape2 + 655
    4   AppKit                              0x00007fff8fd2f340 -[NSWindow _commonAwake] + 2002
    5   AppKit                              0x00007fff8fcedd82 -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 1763
    6   AppKit                              0x00007fff8fcececf -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1568
    7   AppKit                              0x00007fff8fcec89f -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
    8   libSDL-1.2.0.dylib                  0x0000000108a2fbfa -[SDL_QuartzWindow initWithContentRect:styleMask:backing:defer:] + 279
    9   libSDL-1.2.0.dylib                  0x0000000108a2dacd QZ_SetVideoMode + 2629
    10  libSDL-1.2.0.dylib                  0x0000000108a24907 SDL_SetVideoMode + 886
    11  gradients                           0x0000000108416272 stXU_info + 42
)
libc++abi.dylib: terminate called throwing an exception

Helm currently uses Cairo as a backend, because that was the easiest way for me to quickly prototype a vector graphics game engine. However, Helm would benefit from using OpenGL in the backend instead and writing the vector graphics rendering stack internally. This would require a bit of effort, so I'm leaving it until the API is polished enough. Alternatively, investigate how to get Cairo's OpenGL backend working and see how fast it is.

Potentially there could be some sort of backend interface, allowing the Cairo backend to continue to be maintained alongside the OpenGL backend. This would also ease the effort to port to other platforms in the future.

I would also like to use GLFW-b instead of SDL1.2.

Did you help close this issue? Go claim the $100 bounty on Bountysource.

Cloning and using cabal install gives the following error:

src\FRP\Helm.hs:44:18:
Could not find module `Graphics.UI.SDL'
It is a member of the hidden package `SDL-0.6.5.1@SDL_26jmephxohM5v84vz7MqXX'.
Perhaps you need to add `SDL' to the build-depends in your .cabal file.

I'm confused because I thought the new version depends on sdl2, not SDL. Nevertheless, I added SDL to build-depends and got another error:

[ 3 of 13] Compiling FRP.Helm.Engine  ( src\FRP\Helm\Engine.hs, dist\build\FRP\Helm\Engine.o )

src\FRP\Helm\Engine.hs:7:15:
Not in scope: type constructor or class `SDL.Window'

src\FRP\Helm\Engine.hs:8:15:
Not in scope: type constructor or class `SDL.Renderer'

I just installed helm with cabal install helm.

The package on http://hackage.haskell.org/package/helm is 0.5. Can someone bump this to 0.6?

Thanks