Menu

Subscribe

Let it snow!

Menu

I'm currently working on an unannounced 3d game & engine targeting desktop platforms using Haxe, flow, snow and foo3d.
For this post i'm going to shed a little light on my technology stack and how it involves flow and snow.

A special snowflake

From the very start I set out to create a gameengine and renderer from scratch. So I went evaluating my options in the Haxe ecosystem. Reinventing the wheel was not really an option for each and every component. I felt a library like GLFW or Lime could easily serve as my groundlayer on which I was going to place my custom blocks. Unfornately nothing really worked out for me for one or another reason. So i either had to revise my requirements - or find another option yet unknown to me. Luckily, I came across snow, which seemed to be a fleshed out version of the original vision and was exactly what I had in mind: thin, transparent and easy.

What snow does for me

snow handles the platform abstraction layer for me, with all necessary bits for accelerated visuals, windowing, audio, input, assets and utilities. It also uses flow as buildsystem which is a little miracle in itself. In any case, I highly advise you to take a look at flow. It comes with a whole set of features tailored to be as much useful as possible for your Haxe projects.

flow and snow are also tightly integrated with sublime text, including project management and proper code-completion!

So, thanks to flow and snow i can completely ignore all the nasty details of a thorough crossplatform abstraction. I even get a lot of features and utilities that help my runtime and workflow in many ways. Let's have a look at some of these:

Windowing and 3d context management

Everybody knows, in order to play with those fancy 3d effects you have start low-level and get a window + a 3d context from the platform you are running on. The context then enables you to access and use the rendering api. This is pretty important. snow takes care of all of this for you.foo3d.developium.net

Even better, this is the place where my foo3D library plugs in and allows me to expose lower level, more advanced opengl features, and wrap those in object-oriented primitives and renderstate-management - on top of the standard opengl api.

File-Events

snow allows the user to monitor basically any folder on your disk. While these might end up only being a development feature, it has probably the highest impact on how I work with assets in my engine. For every change on disk you'll receive an event on which you can react to. So in case of a changed file, you could trigger a reload of that resource in your engine. That allows running the game, tweaking a shader in sublime and see it live-reload instantly in the game.
This works for every asset that I load in the engine. This results in a very quick turnaround since I can develop, fix and tweak things as I go without having to restart the whole thing over and over again.

Typed Bytearrays

Let's face it: Working with gpu accelerated content and gamedata in general involves moving a lot of bytes around. While Haxe's std library supplies the user with all the necessary tools, working with bytes results in converting data from typed arrays to bytes back and forth. This is very tedious and error prone.
snow comes with a load of typed utilities for this job. So you need a bytearray full of floats? Use the Float32Array class. Ushorts? Use the UInt16Array class.

These are not homegrown but instead follow the official khronos spec for Javascript Typed Arrays very closely. And chances are you are already familiar with the concept if you have messed with WebGL before. This makes accessing, modifying and submitting data to the GPU straight forward!

More snow

This is just a glimpse on what I am using snow for, and i'm definitely posting a lot more about it here.
You got any questions? Be sure to drop them here or hit me up on twitter(@dazKind)!