bananu7 / hate Goto Github PK

This requires abstracting the rendering backing away.

Complicated, but has to be done for WebGL/ES anyway //cc #15

This could possibly solve #3 and would be required for #15 in some form anyway.

GL.get GL.maxTextureMaxAnisotropy >>= ($=) (GL.textureMaxAnisotropy GL.Texture2D)

Relevant is #17.

I know you hate mouse support but I'd love hate mouse support

Sorry for the bad pun.

Perhaps the tagging approach would be enough?

... and this is causing ambiguity between the Lens and that one for some reason.

That would be the FRP way of doing things, but Hate updates work in the world ticks only.

And perhaps some other dumb primitives.

This is also required for fonts.

I feel that there are two kinds that should be supported:

• regularly divided sheets
• sheets with JSON or XML annotations

Could perhaps be a part of Sprite, too.

Only a handful of functions from those are used and they complicate the build.

Is development on this game library still active or planned? I'm considering forking and creating a reboot if such is not the case, yet I would like confirmation that you're still not developing it

Right now it doesn't do any vertex processing, so everything ends up in [(-1;-1);(1;1)]

Sample2, coming from a fresh install, is missing image.png and is therefore failing with:

"image.png: openBinaryFile: does not exist (No such file or directory)"

This answer has a possible way to do that.

Right now, the ones that are similar and I know of them are:

Haskell

• Helm - FRP-style events, stateless purely functional API, backed by Cairo and Pango, with window/context creation via SDL
• free-game - monadic but stateless rendering API, backed by OpenGL (with GLRaw used), context creation via GLFW. Less framework-ish. Doesn't use shaders.

Non-haskell

• Love - written in Lua, with stateful rendering API (mostly for reference as first inspiration)
• Elm

When changing the config to set a window size different than 1024x768, loaded sprites and absolute sprite coordinates get resized to an amount relative to the window size.
Maybe read orthoScreenMat from the config?

Display rates are VSynced anyway.