Accept fill texture embed (ByteString)

[cies]

Okay, this one is more tricky. I made a FillTextureFile which does what FillTexture used to do. Now FillTexture is taking a ByteString.

I can not judge well if the ByteString apporach is a good one. I can also imagine its great to have FillTexture take a DynamicImage or even a GLuint (pointing to the texture in GL'istan).

Currently it compiles the example, for what that's worth. :)

This changes the API, so a version bump of -gl and -core is probably/officially needed.

[schell]

Thanks for the additions. I like the extra options. One question though - doesn't embedding fonts and images in the binary increase the size of the memory footprint? Like - won't it eat up more RAM? It's good as an option one way or another I just want to make sure I understand the consequences.

Now that I'm working on my demo game I'm thinking of making UV mapping more explicit. It means diverging from the original paper I set out to implement but I think it will be more useful.

gelatin isn't on hackage yet so I'm okay breaking the API. It's only you and me using it.

[schell]

I take that back - I guess I have pushed a very old version of gelatin to hackage, before I separated the repos.

[cies]

It's through Hackage that I found gelatin. As a rev dep of the gl package.

Btw why did you pick gl over OpenGL?
On Feb 26, 2016 02:47, "Schell Carl Scivally" notifications@github.com
wrote:

I take that back - I guess I have pushed a very old version of gelatin to
hackage, before I separated the repos.

—
Reply to this email directly or view it on GitHub
#8 (comment).

[cies]

I tried to test if the embeds are loaded into memory, but I did not find meaningful results (Linux memory measuring is not as straightfwd as it might seem). I tried testing it with a big jpg so see if a memory size increase as obvious: well it wasn't.

I opened an issue over at the file-embed repo asking for a bit of help on this one.

[schell]

The OpenGL package has a very light layer over the raw bindings that provide a "Haskell way of doing things" including StateVar and some other features. That made it harder to follow any OpenGL tutorials (like the NeHe articles) because you constantly have to map idiomatic OpenGL to Haskell OpenGL - and then debug, which was difficult. This was the sentiment behind gl in general. The #haskell-game group needed a 1 to 1 mapping of OpenGL so we could follow along with existing OpenGL resources. So I switched as soon as it came out. It made writing the gelatin renderer much, much easier.

Thanks for digging into the file-embed situation!

[cies]

To my best understanding file-embeds are in mem. So better not embed them in real life apps.