Tag: Haxe NME

Haxe inline C++ goodness

Thanks, as seems increasingly usual, to Joshua Granick for writing about another awesome Haxe feature that works so well with NME, but no one seems to know about: Inline C++!

This seems so obvious! It compiles to C so why can’t we throw our own stuff in there? Obviously you sacrifice the niceties of a higher level language like HaXe: Vague compiler errors and manual memory management abound, but it’s worth it sometimes.

For example: My first thought, since I’ve been implementing around it for some time, was to try and implement game saves on my TouchPad. I actually tried to use NME’s extension system to implement this a few weeks ago and got nowhere, so I wasn’t sure what to expect. I wanted to call into the webOS API to get a safe path using PDL_GetDataFilePath(), then write a string out to a file, and in a second function be able to read that string back.

Continue reading “Haxe inline C++ goodness”

Greetings!

I’ve been implementing a second thread of execution in my current game project for the last few days. I had tried to do this in my previous set of code, but either had constant crashes or half the game not working because that second thread wasn’t ticking over. At that time there was almost no instruction online as to how threads worked in NME, but that has changed recently thanks to the (always excellent) Joshua Granick, whose blog post, “Using Threads with NME“, lists out some basic scenarios for communication between threads. There’s also some useful nuggets of information in this forum thread.

Continue reading “Thread synchronization in Haxe NME”

In my new tower defence project I need to know when certain things are touching, or when object A is within range of object B, and other nonsenses like that. It seems perverse now, but the first time I had to implement collision code a few years ago I didn’t know why the computer couldn’t TELL there was a collision: The blue circle is halfway-inside the red square, surely that’s obvious? But implement I did, and it was horrible and rough, but for that project it didn’t matter at all.

In the early days of this project I implemented a collision system again with just two shape types: Rectangle and circle. It worked well enough, but the performance was awful — I had time to knock together a few arrays and an update loop, but more advanced stuff like knowing which objects could be safely ignored to speed the whole process up takes time to write and test. Having experience with it previously, I ran back to Box2D, dropping the source in to my project so I could begin prodding.

Continue reading “Using Box2D as a collision system”

Pong project

Pong was a short project attempting to clean up my code base for Pinball, as well as rectify several nasty and hard-to-catch bugs who were only really present because Pinball was based directly on the first Haxe code I’d written which as you can guess, wasn’t totally solid. Eventually the need to rewrite a lot of my core code is what made me cease development on Pinball, although Pong did help resolve several issues. It was also built while Atari was running it’s Pong Indie Developer Challenge, so I wanted to experiment with some alternate game modes, hence the strange selection of gametypes on offer (multiball is still my favourite).

 


Continue reading “Pong project”

Pinball

Pinball was my first real project with NME, and influenced everything I’m doing with it now. It was very much an experimental project to gain understanding of how it all worked, and in retrospect, I wrote a lot of very heavy, slow code that was unnecessary.

 

lighting_05-02-12

Continue reading “Pinball”