Category: Game Development

MonoPack – A lightweight sprite packer.

Posted by on February 28, 2014

What and why is MonoPack?

MonoPack is a simple, comprehensive, lightweight and portable pipeline oriented sprite / texture packer for web, game and software developers alike.

Right now MonoPack is a console-only application, oriented to streamline game and website development pipelines. It’s nature allows it to be automated via batch and scripting engines very easily. It is, as well, completely free for commercial and non commercial projects (contact me for more details)

It’s “page” oriented, meaning it will iterate through a given directory, including all matching images into the final atlas. It does not take into consideration sequential images (animations) nor grouping yet.

It’s always the same story, either the available tools are too slow, cumbersome or have multiple dependencies, they may be free but not functional or prohibitively expensive… The available commercial tools are fine but they’re on the slow end of the spectrum with features most devs will never need and so many lacking important features on their “free” versions that render them virtually useless.

A quick benchmark:

| MONOPACK REPORT | Contact/Author: |
Directory: ‘warrs/’
Pattern: ‘*.png’
Amount of images: 2194
Atlas Dimensions: [2048, 2048]
Covered Area: 3155592
Total Area: 4194304
Packaging Efficiency: 75.2352%
Time spent: 702ms
Loading: 296ms
Processing: 78ms
Rendering: 265ms
Saving Data: 47ms
Saving Image: 16ms

The resulting atlas (scaled down for display purposes)

The resulting atlas (scaled down for display purposes)

Currently supported atlas formats:

The output is always 32bit with alpha channel (supported if your sprites have them, otherwise it can generate the alpha mask given a color-key, see the configuration file for more information or leave me a message and I’ll try my best to guide you).

Current output formats are:

  • PNG (32Bit)
  • BMP (Bitmap 32bit)
  • JPEG

Planned outputs on future versions: JPEG2000, TGA and RAW.

Planned features:

  • Output separate alpha channel < (being tested)
  • Scaling and Rotation of sprites < (mipmaps pseudo implemented)
  • Sequential grouping for animations
  • Image manipulation functions (contrast, sharpen, etc.)
  • Faster alpha key generator (currently not optimized)
  • Automatic atlas resizing (will be optional) < Done – It’s called AutoSize!
  • Multiple pages per directory (to be implemented)
  • Parameter for output path. < Done – Full parameter support through console.
  • x86 and x64 binaries. < Done

Bugs and (are?) Features

Feature requests and bug reports are welcomed and encouraged. If you would like to support further development of this tool, or if you’ve found it invaluable in your work pipeline, please consider a small donation. You can contact me or click directly on the Donate button.

Why is it called MonoPack?

Originally intended for the Monkey and Monkey-X community, Mono comes from Monkey in Spanish. The rest requires no further explanation! – Needless to say this application is open to all communities and everyone’s suggestions are welcomed.

Obtaining the goodies

If you’ve made it this far, it’s only fair I hand you over the download link:

Please remember: this is a beta version, open to the public for testing. Bugs may be found!

Older versions:


No hard limits imposed on the amount of sprites or alpha channel nonsense.

A Commercial and Freeware GUI is currently being developed.

Thank you for downloading and testing MonoPack!


Free Game Resources – Cloud pack with full alpha channel.

Posted by on February 1, 2014

Sample set of volumetric clouds

It’s been a while since I shared some of my game development related artwork, but here’s a nifty set of volumetric cloud samples I’ve made for one of my projects, the various shapes contained allow to create a vast amount of variations rather easily.




These images contain full alpha channel and are all 512×512.

Download here: gushh_dot_net_cloudpack

Some of the clouds have a dark background (night) — Others are daylight based, however they can be mixed using various rendering and blending methods to obtain rich pseudo dynamic clouds at a low processing cost.

Rendering Tips

An ideal blending method would be to utilize the luminosity of the samples to blend against an existing background, then through the use of layering and clever movement quite interesting cloud representations can be achieved for games and simulators, and why not a screensaver?.

Closing up

These samples are free of use for non commercial projects, however credit must be given.
If you need a complete set, higher resolution renders or other custom work — Feel free to contact me for extra details!.

Also, feel free to send in your suggestions for future freebies, I’m open to a challenge.


Monkey-X / Android – App name, version, orientation and package name.

Posted by on January 30, 2014

Certain games and applications require different screen orientation constraints as well as the obvious name, version and package differences between each other. There are also GPU flags and “MIMEs” we have to setup based on each project’s requirements, Monkey-X simplifies this by reducing the amount of resource / XML editing by allowing us to define constants in code.

The following is pretty much what I use on my main source before I begin to include libraries and the main routine:

#ANDROID_APP_LABEL			= "Your Program Name"
#ANDROID_SCREEN_ORIENTATION 		= "portrait" ' could be landscape or user which may or may not use 'sensor'.
#ANDROID_APP_PACKAGE			= "com.yourbrand.yoursubcat.yourprogramname" ' for instance:


#TEXT_FILES				= "*.txt|*.xml|*.json"
#IMAGE_FILES				= "*.png|*.jpg|*.gif|*.bmp"
#SOUND_FILES				= "*.wav|*.ogg|*.mp3|*.m4a"
#MUSIC_FILES				= "*.wav|*.ogg|*.mp3|*.m4a"
#BINARY_FILES				= "*.bin|*.dat"

By defining these constants we avoid having to edit resource files by hand or utilize extra tools / external code to perform the same action.

If you want to fully customize your Android target I suggest you create a new target to avoid modifying the defaults.

That’s all for now, Cheers!

Monkey and SVN – Auto delete .build and .svn

Posted by on January 24, 2014

Couple useful bats

These are a couple basic yet useful bat files (alright you got me, I mostly develop in Windows… but don’t judge just yet!) to wipe clean build directories and svn directories accordingly.

For wiping out the .build directory on a Monkey project (monkey-x, monkeycoder):

for /d %%x in (*.build) do rd /s /q "%%x"

.svn cleaner: (recursive)

for /r . %%a in (.) do @if exist "%%a\.svn" rd /s /q "%%a\.svn"

That’s it for now, enjoy!

(PB) Timeout Library

Posted by on December 12, 2012


This simple “timeout” library allows you to easily perform timed operations in your games and applications. Thanks to the callbacks you can also perform arbitrary functions within each update cycle.

The library is very simple to use, you must define a maximum timeout period and an update rate when you create an instance of TIMEOUT.

The “maximum” is in milliseconds and corresponds to the timeout period, for example 1000 would be 1 second timeout.

The “update_rate” sets how many updates there will be within 0 and the “maximum” in this case 1000), if we were to use 10 updates then we would experience the callback to be called every 100ms.

Of course both the callback and the user variables are optional, but they’re a handy feature.

Simple use case:

Define.TIMEOUT *timeout = timeout_create( 1000 * 5, 100 ) ; 5 seconds maximum timeout, 100 updates a second.
If *timeout

	Debug "starting"
		timeout_update( *timeout )
		Debug "update"
	Until timeout_expired( *timeout )
	If timeout_expired( *timeout )
		Debug "timed out"
	timeout_destroy( *timeout )

One of the many uses I have for this library includes waiting for a server to respond, sending timed events to clients, etc. I even use it to send notices to every client on the server before the server actually shuts down! (game server)
You can actually select whether the library should perform an actual sleep / delay operation to save cycles ( for example in cases where you have a waiting loop it’s ideal to sleep for a given period of time instead of wasting those cycles ) or you can have it compare old vs new time instead of performing a real delay. On timeout_update() the second parameter defines this behavior.

The library:


Structure TIMEOUT
	delay.i 			; based on how many updates a second are required, this holds the delay value in ms.
	current.i 			; the current timeout value in ms, this is the "counter" and uses the "delay" to increment.
	maximum.i 			; the timeout value in ms
	update_rate.i 			; holds the update speed in times per second
	old_time.i			; the old time in milliseconds
	new_time.i			; the new, current time in milliseconds
	*callback.i			; user callback pointer, we can't cast it as a timeout_callback prototype here for obvious reasons.
	user_variable.i			; a custom user variable, could be a pointer or anything at all, it's accessed through the instance ptr sent to the callback.

Prototype.i timeout_callback( *this.TIMEOUT )

Procedure.i timeout_create( maximum.i, update_rate.i, *callback.timeout_callback = #Null, UserVariable.i = #Null )
	Define.TIMEOUT *this = AllocateMemory( SizeOf(TIMEOUT) )
	; set all the pertinent values to this structure
	If *this
		With *this
			\maximum 	= maximum
			\update_rate 	= update_rate
			\delay		= ( 1000 / update_rate )
			\current	= 0
			\old_time	= 0
			\new_time	= 0
			\callback 	= *callback
			\user_variable 	= UserVariable
		ProcedureReturn *this

Procedure.i timeout_destroy( *this.TIMEOUT )
	; check whether the pointer is not a null and proceed to free the memory.
	If *this
		FreeMemory( *this )

Procedure.i timeout_update( *this.TIMEOUT, Should_Delay.i = #True )
	If *this
		If Should_Delay
			Delay( *this\delay )
			*this\current + *this\delay
			ProcedureReturn *this\current
			*this\new_time = ElapsedMilliseconds() ; obtain the current time
			If *this\new_time > *this\old_time + *this\delay ; compare if the new time is bigger than the old time plus the delay factor
				; if so, update the old time with the new time and increase the current variable by the delay value.
				*this\old_time = *this\new_time
				*this\current + *this\delay
				; is there a callback? if so, call it.
				If *this\callback
					Define.timeout_callback *cb = *this\callback
					*cb( *this )
				; return the current value, in cases where the timeout has an update rate / interval of 1, we'll always get the full amount.
				ProcedureReturn *this\current

Procedure.i timeout_reset( *this.TIMEOUT, WipeUserVal.i = #False )
	If *this
		; Wipe out the changing variables
		With *this
			\current	= 0
			\new_time	= 0
			\old_time	= 0
		; Optionally wipe out the user variable, this defaults to false.
		If WipeUserVal
			*this\user_variable = #Null

Procedure.i timeout_expired( *this.TIMEOUT )
	; Has the timeout expired?, if so return true (1).
	If *this
		If *this\current => *this\maximum
			ProcedureReturn #True


That’s all, enjoy!

If you have any comments, feel free to leave them here!
Any additions to the code will be welcomed.