The secret has started leaking from discord into the forum, so might as well spill the beans:
FemtoIDE is an IDE I’ve been working on for Pokitto game development.

—> Get it here! <—

It is still in beta, so expect some rough edges. If you find bugs or have suggestions, please file an issue. Pull-requests are welcome too: it is opensource, released under the MIT license.



  • Fully offline. Doesn’t use the internet at all.
  • Zero installation. Just extract the zip and you’re ready.
  • Batteries included. Comes with GCC, PokittoEmu and the PokittoLib.
  • Debugger integration. Supports both PokittoEmu and Segger J-Link hardware debuggers.
  • Fully customizable keyboard shortcuts
  • Built-in image editor
  • Built-in image conversion to code as a build step.
  • Support for C++ and Java projects (Python support pending)
  • Windows and Linux support (MacOS support pending)
  • Built-in git support for quick operations like seeing file status and committing.

Planned features

  • Automatic PokittoLib and IDE updates
  • GUI for editing project.json

C++ projects

All of a project’s settings are in project.json. So, if you want to compile with -Os instead of -O3, for example, that’s the file you’re going to make that change in.

As another example, if you want to change the palette used by the built-in image converter, you’d do that by changing this file path:

	"PNGFlags": {
		"ALL": [

Java projects

FemtoIDE comes with a FemtoJava compiler that is still in development. This converts Java source code into Pokitto-compatible C++. Since the code is translated, it is fast. It does not have the performance penalty of a VM. It features a mark-sweep garbage collector, so you don’t have to worry about memory management.

The debugger also supports Java projects. You can place breakpoints and step through your Java code.

Since the Pokitto does not have hardware floating-point support, FemtoJava uses @Pharap’s Fixed Points library for the float type. If this is not precise enough for your needs, use double instead, which is mapped to a 32-bit float.

Also included is FemtoLib, FemtoJava’s equivalent of upygame or the PokittoLib. For further information, see the example project and the documentation wiki.

For Java projects, the converter also supports animations in the form of spritesheets accompanied by their respective jsons. If you have “Dog.png” and “Dog.json”, it will create a class Dog extends Sprite. Each animation then becomes a method:

import animals.Dog;
Dog pug = new Dog();
pug.run(); // starts the "run" animation

In the file list you can add interface classes to sprites, allowing you to manipulate different sprites:

public interface IAnimal {
  void run();

Dog odie = new Dog();
Cat garfield = new Cat();
IAnimal[] animals = new IAnimal[]{ odie, garfield };
for( IAnimals animal : animals ){

Asset Conversion

Both for C++ and Java projects (and in the future, Python), FemtoIDE aims to automate the process of converting assets for use in games. The idea is to reduce iteration time so that you can edit a sprite and immediately see the result in-game. This also allows you to do things like changing the palette and not having to manually reconvert all of your images.
In Java, you can import either PNG images or JSON spritesheets. Also supported are TXT and XML files.

In C++ you can #include PNG images, but there is no support for spritesheets.

Support for audio and tilemaps are planned.


A big thank-you to those who have been supporting this project by testing and providing feedback and bug reports on Discord: @andrea_i, @bl_ackrain, @Hanski, @torbuntu

In particular a very big thank-you to @HomineLudens who’s written a lot of test cases for me to do TDD on, contributed to the Wiki and reported countless bugs.

[Game]Matti's Nightmare

This looks really slick and well made! While I already have a setup without an IDE for C/C++ code, I’ll use this if I try to do Java on the Pokitto.


I totally get that, especially since I use Emacs for everything. Eventually we’ll be able to build a FemtoIDE project from the command-line, without having to open the IDE itself. That way we can use any other editor and still have things like automatic asset conversion.


even without any info, I was able to start coding on the pokitto emulator instantly, this is just great.
Sorry for the spoiler though, didn’t know it was under wraps.

And I’m also looking forward for this to be a command line tool.

My only feature wish would be to have an array of pre and post compile commands defined as strings in the json file.
This way I could include my python script that generates map files before compilation begins.

If the compiler and the emulator were also just commands piled in that list, femto could be used for the arduboy and the gamebuyino straight away :smile_cat:


This has pretty much come from nowhere from my point of view.
(Though I do vaguely remember the repo being created a few months back.)

I’m glad (but surprised) that my Fixed Points library has found yet another use.
(Which reminds me, I still have a load of outstanding issues I need to handle at some point.)

The idea of using Java on the Pokitto slightly horrifies me.
Java’s bytecode is far from the best bytecode format going, and the idea of a garbage collector on an embedded device also concerns me.

That said, the Sin Cos example on the wiki is slightly closer in terms of API to what I hope the Pokitto API will eventually evolve into.
(Particularly with the user allocating their own screen.)
It also makes me hope that some day Lua might find its way onto the Pokitto.

I decided to make a few minor Wiki contributions since I was there anyway.


All Java is translated to c++ and then compiled. No Java at all in final bin.

Yup the Femto api is really a step forward.


I’m really glad to hear this. One of my top priorities was to make it easy to get in to for newcomers.
As for the spoiler, it’s alright, you weren’t the only one and it was about time anyway. :laughing:

There’s an array of compilation steps:

		"Pokitto": [

These are internal function calls, not shell commands, though. If your map converter was in javascript instead of python, it would be really easy to make a plugin and add it to the steps. It would be really good to have “tmx-to-c” built-in.

How about adding support for shell commands by using a prefix? If the string starts with “#”, it would call the shell instead.

Also in the json is this:
"target": "Pokitto",
You can have different settings / compiler flags / build steps depending on the target platform.
In theory, you could add Arduboy|Gamebuino[Meta] targets, just as there is a (totally broken) Desktop target. The priority was getting things working well for the Pokitto first. Then will come the Desktop (Simulator). Then Emscripten, probably.

Since there were breaking changes from one release to the next, we did “closed” beta testing on Discord. Quotes around “closed” because the repo was open all this time and we weren’t really making a serious effort of keeping it secret. :stuck_out_tongue:

Since it’s built-in, all Pokitto Java games will be using it even if they’re unaware. :stuck_out_tongue:
(Which reminds me, @bl_ackrain has pointed out that it’s missing a modulo operator.)

That’s the primary reason why I didn’t simply port a JVM to the Pokitto. Not only is the format inconvenient, the official compiler doesn’t do much optimizing (not even constant folding, iirc) and leaves all the work to the VM.
There is no bytecode involved here: this is a Java source code to C++ compiler (“transpiler”).

The GC was something I was wary of at first, too. In testing, even if it were to kick in once per frame, it does not impact the framerate.

One thing I want to try, mostly just for laughs, is making an Arduboy target for the compiler.
“Java on Arduboy” would be hilarious.

For a better feel of the API, you might want to have a look at Hello Java.

I saw an eLua vs MicroPython comparison and the conclusion was that bytecode-compiled MicroPython (as is the case of PyInSky) leaves far more RAM available. Since RAM is our primary constraint, I decided that the best would be something that didn’t need a VM.
Since I couldn’t find any compilers that would be easy to work with (had a quick look at rust, wasn’t going to be trivial) I ended up writing my own. Java is a simple language and static-typing is good for performance, so that’s what I went with.


It would be really handy, until a tile editor will be embedded on the Ide :stuck_out_tongue_winking_eye:


The idea of using a GC with C++ code is very alien to me.

I know they exist and there has been talk of adding some GC support features into the C++ standard library (just supporting features, not an actual GC),
but it’s still a very unusual thing because it almost goes against the C++ philosophy/ethos.

But it’s a better solution than producing JVM bytecode at least.

If there’s dynamic allocation involved then chances are it would fall apart for anything even remotely complicated.

That’s partly because float doesn’t have a modulo operator and I was trying to make it a stand in for float.
(The standard library adds std::fmod, but I can honestly say I’ve never used it.)

I’m not even sure what the best way to implement it would be offhand.
I don’t know if it would work if I implemented it the same way as divide is implemented.
Apparently something like this might work:

return (dividend - truncFixed(dividend / divisor) * divisor);

But that seems quite expensive.

I also didn’t add sqrt or the trigonometric functions (though I did investigate them all, and have actually implemented sin and cos in a separate project, but for brads rather than radians).

I suspect it is possible to compile Lua to machine code.
For a long time there was a JIT-compiled implementation for Java (creatively named ‘LuaJIT’) until its sole maintainer (Mike Pall) abandoned it two years ago.

I can sort of understand why Lua might be a bit RAM hungry - it uses hashtables rather than classes and objects.
But it’s a very easy language with a long history of being used for video game scripting, so if it were possible to get it decently usable on Pokitto then it would be a good skill to be teaching beginners.

I’m not surprised there.
Rust is a functional language, and they tend to be a bit quirky.
All the ones I’m aware of use a GC of some description.

Did you consider D at all?
Apparently there’s a GCC frontend for it, and it’s known to work for ARM Cortex-M.
I’ve never used D but it’s one of the languages I’ve been meaning to try because it was influenced by C++ (and C#, though less so).

Both true, but Java has some not so good points too.
Type erasure is one of the big reasons I stopped using it.


True. I didn’t say it would be practical, all I know is I’d find it funny.

I found an implementation and tweaked it for the 23.8 format.

I considered brads for sin and cos but it wouldn’t follow the standard and would make porting harder.

Regarding Lua and D vs Java:

Python is great for people starting off, learning how to code. Once their projects get bigger, however, it becomes too restrictive.
The only alternative was jumping to C++, and that’s a big jump.

Lua would’ve been a sideways jump from Python, so it doesn’t help in this regard. It does help in porting, but that has its own set of problems.

D would’ve been a sideways jump from C++. Still a big jump from Python. While I don’t know the language, I imagine anyone comfortable with D could probably move sideways to C++ easily.

Java is easier than C++ and is widely known, even if it has its flaws and is not very trendy. Going from Python to Java has a much easier learning curve, while providing resources to make much bigger games.


I was sceptic about Java at begin too, but I find ti fitting well with the API. Again, I believe a good Library is more important than the language. A good candidate could have been C# (instead of java).


Having worked with both Java and C# professionally, I’d have to say java has a much better overall ecosystem.


It would be funny, but only if it managed to last more than a few seconds before it crashed. :P

Can you remember what the original implementation was?
Partly because I think it would be a good idea to link to it from the code to give credit to the original author, and partly because if it’s decent then I might try to incorporate it into the actual library at some point.

While I was looking, I think your implementation of round and ceil are probably cheaper than the current implementation of roundFixed and ceilFixed (+, & and a presumably inlined ~ versus ==, ?:, >>, + and <<), but your implementation of floor is probably more expensive than floorFixed (>>, & and << versus & and a presumably inlined ~).

Also, cos and atan2 appear to be missing function bodies.

didn’t know Java implemented ! to mean ‘is null’.
I don’t think I’ve ever seen Java code do that.

Fair enough. Porting is quite important.

I actually think it would have been a step down in some ways.
It’s a much simpler language than Python.
There are no classes, just a hybrid array-hashtable type that can be used to build complex types.

Hrm, I think that’s a tough call.

It’s certainly comparable in syntax and the number of features,
but (skimming a tutorial) it looks like it’s probably more beginner friendly.

It appears that associative arrays (i.e. hashtables) and tuples are first class types, like they are in Python.
(C++ has tuple syntax in either 17 or 20, can’t remember which exactly, but std::map and std::tuple are both standard library types, not first class types.)

I’d say it’s actually more like C# given that it’s garbage collected and the syntax is overall much more high level.
The syntax seems to have inherited from both C# (ref rather than &, ref and out parameters, interface, package akin to C#'s internal, delegate, reflection capability) and C++ (const, size_t, ptrdiff_t, inferred return type).
(And some other languages, e.g. contracts, optional round brackets, pure, immutable, array slicing, lazy.)

It’s kind of a shame though, D’s immutable keyword would be perfect for indicating that data should be placed in ROM.

Reading the feature list, I think a D programmer might actually struggle a bit with C++.
Primarily because moving from any GC’ed language to a non-GC’ed language is a big leap,
but also because it appears to have a number of features that C++ doesn’t.

Java was trendy once upon a time.
Trendy isn’t necessarily a good thing though.

There are many languages I dislike more than Java,
but having actually written a game in it before,
it’s not something I enjoy using.
I actually like it more than C though, so it could be worse.

I wholeheartedly agree with this, though I suspect it would have been more difficult.

Unfortunately people associate C# with Microsoft and don’t realise that the language itself is actually an open standard,
so there aren’t many alternate implementations of it.

But in terms of features it’s definitely a much better language.
It fixes many of Java’s shortcomings, e.g:

  • Having reified generics instead of type erasure
  • Functions being first class types.
    • (Java does have lambdas, but because they came late in the language they were bolted on top of the existing ecosystem and thus map to interfaces instead.)
  • struct` enables proper value semantics
  • Operator overloading
    • (Seriously, even Python and Lua can do operator overloading. Java’s missing out here.)
  • Allows more than one class per file
  • Doesn’t have checked exceptions
    • (I think this comment pretty much sums up why I don’t like them. And perhaps this too.)
    • (Note: I think the intent of Java’s checked exceptions are overall good, but I think they’re the wrong solutiont to the problem they try to solve. A better solution would be something akin to Haskell’s Monad and fail or MonadError. But mainstream languages are only just beginning to see the value of tagged unions/sum types, so it’s not surprising.)

I didn’t intend to start a language debate,
but language design is naturally an interesting topic.


Actually in the gaming world, c# is known for mono and unity : )
And it’s one of the most diffused languages, followed by c++ (unreal engine) and lua which was historically used by many engines to orchestrate levels data.
Too bad unity’s IL2CPP is not open source : /

Stepping out of the lang thing for a second, I think femto will be great for pokitto to not scare away newcomers that want to make a complex game (so, no python) but don’t want to get stuck with complex compiler setups.

Back to the language thing, egoistically, I fear a custom java to c++ transcompiler might be a time sink for FManga, and given the limited ram, a garbage collector will make any newcomer hit a wall (or a bug in the transcompiler) before making any game worth noting.
Maybe swift or haxe could have been an easier battle to pick?

Also, lets not forget that c++ can be tough to newcomers without pointers or classes.
I’d personally see a c++ function based high level sdk without pointers, as a better way to get people on board with a sigle unified language from the start.
Something that replicates pico8 or tic80’s functions.

P.S. I hate c++ : ) my heart is with c#, but I don’t see any other way to deliver interesting games on pokitto than c++, with the restrictions it has.
The arduboy community is doing great games with just that : )


Coming from Mini2Dx and LibGDx I actually am extremely grateful for the ability to use java on the pokitto.


I’m not sure, I think it was just a common algorithm implementation that you’d find copy-pasted all over and not attributed to anyone in particular.

It’s been a while, so I’d have to recheck why I did it that way. There is so much of the standard library to implement that I didn’t stop to look at disassemblies and count cycles yet.

About the rounding, I’m betting on GCC turning &~0xFF into lsrs rx, 8; lsls rx 8, for two cycles in total. If it were to actually use the ands opcode it would need to allocate a temporary register and spill something else out.

The bodies are over here. Classes that implement __stub__ can have platform-specific implementations in C++.

It doesn’t, that’s a JavaScript / C++ habit of mine. The compiler still doesn’t do all the static type checking, so that works while it’s not supposed to. It wasn’t a high priority since having to use only booleans in ifs is just so annoying. :stuck_out_tongue:

Agreed on both. As a more expressive language, it would be far more work.

It’s a good debate. If feasible suggestions show up, there’s no reason they can’t still be pursued. Especially if suggestions come in the form of pull requests. XD

Also, ever since I’ve started work on this, people have been asking me:
Why Java? Did you look at Lua?

Personally I’d prefer to have JavaScript instead, but that has the same problems as Python.

Java seems to have lost its attraction over the years but, as a language, it’s the closest balance I could find for getting the most performance out of the Pokitto, being easy to use and learn, and not take years to get working.

It also has the advantage of not being Lua. There are already a lot of popular options for people who want to make games with Lua.
Those who like Java (and there’s still a lot of them), are not very attracted to Lua-based fantasy consoles. It could become an interesting unique selling point if the Pokitto is the microcontroller-based handheld that can run Java.

Definitely a time sink, but most of it has been fun.

Not sure why you guys think a GC is a limitation. Unnecessary objects get collected. The difference is that without the GC you have to do the collection manually.

On the other hand, the transpiler approach allows me to do certain optimizations that would be a pain to do in C++. As an example, an array of 10 objects in C++ takes 40 bytes of RAM. In Java, it takes 30: arrays store 16-bit short pointers instead of 32-bit. Another example is the use of fixed-point math by default.
Then there’s the advantage of getting all of GCC’s optimizations for free.

I don’t know about swift, but haxe… possibly. It has a C++ backend, but it’s all coded in OCaml. The only experience I have with OCaml is in trying to fix a bug in the haxe compiler 10 years ago. :stuck_out_tongue:


This is exactly why I started making my own fc that uses Groovy.


Sorry for the text wall…

Hopefully, but it wouldn’t be the first time GCC hasn’t done a seemingly obvious optimisation.

I distinctly remember expecting GCC to optimise >> 8 to just using mov on a byte and it didn’t.
(If you remember your 3D pod racing game on the Arduboy.)

Quite an odd way for that to happen.
I would have expected it to be done with attributes.

Java wins another point back for making the sane choice in this case. :P

What you call annoying I call “semantically correct”.

I just updated my copy of the ECMA-334 standard because I realised my current version was from 2006 (outdated before I even downloaded it :P).

It’s 513 pages.
Not as bad as C++'s standard (over 9000 1000 pages), but still pretty dense.
Surprisingly Java SE 12’s standard is 772 pages.

If I get chance to make any PRs, they’ll probably be either style changes or minor implementation changes.
More likely it’ll be documentation.

Come to think of it, have you thought about using Javadoc or something similar?
Not quite as easy to update as the Wiki, but the output would be more structured and thus more useful.

Lua specifically?

If people have been asking about it then hopefully I’ve given at least one or two people the Lua bug. :P

I’m afraid I’ll never understand why people like JavaScript.
Automatic semicolon insertion was always a terrible idea.

Lua got around that by making the language designed to not have semicolons and then making all semicolons act as explicit statement separators so people who are used to them can still use them, which is a nice middleground.
Unlike Python’s ‘no semicolons at the end of a line’, which is really hard to get used to.

I don’t disagree with that. It ticks those boxes.

Java isn’t actually an inherantly bad language,
it’s just that it could have been so much better.
Java’s excuse for enums still perplexes me to this day,
they’re effectively just classes by a different name.

I seem to recall that being one of the supposed advantages of having Python support. :P

It has an overhead.
Also I have concerns about whether it allocates dynamically or in pools.

And how it’s doing collection without a second thread.
I’m used to GCs that ‘stop the world’, sweep all the dead objects up, move some pointers around and then ‘resume’ the world.

If it’s mostly just pools and reference counting then that’s not too bad.
(Though obviously reference counting has the dreaded circular reference problem.)

I think there’s something missing from this equation.
Are the C++ objects actually pointers?

Java arrays store references to the actual objects (wherever they’re allocated, I’m presuming on a ‘heap’ of some sort),
whereas C++ arrays store the actual objects in-place within the array.
(There’s a good talk by Bjarne Stroustrup discussing this but I can’t remember which one. Probably the 2012 Keynote.)

Perhaps, but people can choose to do that in C++.

The main reasons they don’t is because not enough people know about my library and I haven’t got round to making it work on Pokitto ‘out of the box’.

Oh god, really? Who uses OCaml in this day and age!?
(Well, obviously the Haxe team, but you get the point.)

OCaml is one of those weird languages like Object Pascal where you’re aware it exists but there’s only about 2-3 well known programs written in it.

I wasn’t even programming 10 years ago. :P

(I tried to cut this down a bit to avoid my reply getting too long.)

Mono is good.

XNA was a great thing, Microsoft were fools to stop supporting it.
The people who founded Monogame did a great thing by ensuring XNA lived on.

I’ve never got round to trying Monogame though.
I got the impression there was a fair bit of installation involved and I don’t like installers.


Python option already has a GC,
and would presumably mean even more limited RAM than the Java-to-C++ option,
so on the current scale of things that’s not much of an issue.

From what little I’ve seen of it I quite like Haxe.

Swift I’m not so much of a fan of.
I’ll admit that’s partly because it was designed by Apple,
and I don’t really associate Apple with good code.
Though I’ll admit Swift is an improvement on their previous language: Objective-C (which was just plain ugly).

One of the things people regularly misunderstand about C++ is the need for pointers.

In most cases beginners shouldn’t need to understand pointers.
In fact the majority of C++ code shouldn’t need pointers.

Pointers are only needed when references aren’t suitable,
or when working with low-level details like hardware ports.

Part of the reason this myth persists is because C is the one that relies heavily on pointers (it doesn’t have references) and a lot of people conflate C with C++ despite the two being distinct (albeit somewhat closely related) languages.

In C++ pointers generally aren’t needed.
(I could find a few examples if need be.)

As for classes, those aren’t C++ specific. They’re also in Python and Java.
But really they aren’t actually that hard to use.

A lot of people make the mistake of equating ‘classes’ to more complex things like inheritance and virtuality.
At its heart, a class is just a means of grouping data with functions (and sometimes a class doesn’t even need functions).

Not using classes in the API would be severely limiting (assuming that’s what you mean by ‘function based’).
(I’d like to point out that structs are effectively classes in case anyone reading this isn’t aware.)

It wouldn’t be possible to implement without pointers in the internals because the Pokitto needs to manipulate IO ports,
but it might be possible to not have almost no pointers on the interface with good use of references.
(You couldn’t escape const char * though, those are needed for string literals.)

As I said before, most C++ doesn’t actually need pointers.
80% of the time you don’t want to be using a pointer, you want to be using a reference.
References are the natural way of doing things.

Pointers are for when the value has to be nullable or when something is low level enough that a reference wouldn’t be a valid option.
(It’s usually possible to coerce a hardware address into a reference, but I’m not sure how wise it is.)

Unfortunately tutorials tend to explain pointers before they explain references, or neglect to explain references entirely,
so people often get the wrong end of the stick.

Pico8 uses Lua (or a variant of Lua) as a language.
Just wanted to point that out. :P

Wasn’t expecting to see @HomineLudens and @trelemar’s names there.
(Also, Moonscript looks neat.)

Why? What specific aspects of it do you not like?

Only certain languages give fine enough control of low level details to overcome the restrictions.

The reason C++ is the most commonly used choice (aside from the number of people who know it) is that it can provide both high level and low level features,
and the vast majority of the high level features come at almost no extra cost.

It’s certainly less painful than C or pure assembly at any rate.


The reason I’m counting on it this time is I’ve seen it using shifts for masking when outputting thumb2.

Support for attributes came much later, so at first the only way available was interfaces.

If you define false and true as zero and non-zero, isn’t it semantically correct either way?

Is that just the language, or does it go into the standard library?

At one point the thought “I should use Javadoc” crossed my mind. Never got round to it. :stuck_out_tongue:

Yes. I guess people like the idea of having the Pico-8 library available on the Pokitto, but it’s not just a matter of having the language available on the platform.

In all my time using it, the semicolon thing was never an actual issue. I’ve seen code bases that used semicolons always and others that outright banned them. It makes no difference at all.

It’s just a GC, it does not allocate. Allocating an object is done by new, which calls malloc. The malloc implementation is wrapped so that if it fails (ran out of RAM) it calls the GC and tries again.

It does stop the world. It’s a variation of the Mark-and-Sweep algorithm. It has no problem with circular references and is not a naïve implementation so it won’t die if it finds a linked list. When you run out of RAM it visits all the objects, marks the ones that are referenced and deletes the ones that aren’t. With only 32kb worth of RAM, and a large chunk of that going to the framebuffer, this process is quick enough that it isn’t noticeable when it kicks in on a game running at over 60fps.

If the Pokitto had 32mb of RAM, then it would be a problem.

Well, for an apples-to-apples comparison, that should probably be an array of smart pointers in C++.
Though you’re right, C++ gives you the option of putting the objects in place. It is the more powerful language, after all. I’m not saying Java would let you do something you can’t in C++, but by making a transpiler I can make optimizations that users can benefit from without them having to think about it.

Obviously, you need to pick the right tool for the job and there are going to be cases where being able to decide where your objects are located is important. Then Java isn’t the right tool and C++ is the way to go. Either that or you use static classes and do away with objects and write C-style Java. :stuck_out_tongue:


Don’t want to start a c++ bash thread, so I’ll keep it short : D
It was created back when nobody knew what was the best way to go about managing memory. Now things have changed, best practices are in place, and c++ does not enforce anything, so each company using it just writes a huge wiki with rules to work with it.
If you end up in the wrong company, good luck maintaining some ultra-templated c++ with hundreds of arbitrarily enforced conventions on variables lifetime just to try and keep everyone sane.

Rust, D, swift, c#, are all valid replacements, they all compile down to the same llvm instructions, each of these languages is just a set of rules for a standard way to handle memory, with the nice option to write unmanaged code where needed.

EDIT: but for pokitto, c++ is the way, lets make games and nice tools, not compilers : p ; )