I hope to get back to working on this if the interest is still there.
Today I implemented itoa, utoa, ltoa and ultoa.
They’re written in a way that’s portable and doesn’t have the bugs that pokItoa, pokUtoa and pokLtoa have (although they might not be as small/fast).
I think there might be interests in thus. But what’s killing it is the fact that the 128*64 res makes it that not many will want to play them that small on the Pokitto…
I keep hearing this argument, but if you look at them side by side you realise it’s not actually that much of a difference:
(Sorry these are poor quality, my camera doesn’t like artificial light.)
(Also getting the timers 10 ticks apart was completely unintentional.)
The Pokitto’s screen is actually significantly larger than the Arduboy’s screen,
but the individual pixels aren’t that much smaller.
At most, the Pokitto’s pixels are 2/3 of the Arduboy’s.
In the future it might be possible to scale it up slightly,
but ultimately it’ll come down to the quality of scaling algorithm that can be developed.
Scaling algorithms aren’t easy at the best of times, but most are designed for scales of x2, x3 or x4 and what we’d be looking at here is more like x1.5 or x1.6 (1.75 would be too big unless you’re happy to have some pixels chopped off and the LED indicator to be above or below the gameplay area).
If the Pokitto has enough processing power then scaling up 3x and then scaling down x0.5 might be an option, but I’ll cross that bridge when I come to it.
For now I want to focus on other things, like getting an on-screen LED indicator.
I didn’t mean to say it in a bad way. I know it’s not that much smaller then on the actual Arduboy. But we have to take into account to that since the Pokitto screen is quite bigger, that makes it ‘look’ even smaller.
I just think that some might skip the Arduboy ports because for them, it doesn’t take advantage of the Pokitto.
I am all for Arduboy ports, mainly because it could port most of the game I made with Filmote on the pokitto, but knowing that a minority will really try them makes me want to maybe think twice about it before doing anything.
Now, if someone find a voodoo magic way to scale it well on the Pokitto or make the library adjustable in some ways to help make hybrids pokitto/Arduboy games…
I have a solution for that, but I haven’t got to that part yet.
You don’t really have to do much.
As long as an Arduboy game obeys the rules of standard C++ then all you have to do is rename the .ino to .cpp and hook up the library and everything works automatically.
It took me a mere 8 commits (of which 1 was initialising the repo and 1 was uploading the original files) to get CastleBoy into a playable state, and half of that was commenting out stuff I haven’t got round to implementing.
If the library had been in a fully working state then I would have only had to make only one change:
renaming CastleBoy.ino to CastleBoy.cpp.
That’s what this library is going to be capable of when it’s finished.
The point of this library isn’t to make porting Arduboy2 games to the Pokitto easier,
it’s to make Arduboy2 games work for the Pokitto practically out of the box, no extra effort involved.
Unfortunately there will be cases where this won’t work because people have depended too much on the Arduino environment
(i.e. -fpermissive, the behaviour of Arduino’s .ino file processing and GCC’s compiler extensions),
but apart from those cases this library should make direct porting of Arduboy games take practically zero effort.
Like I said, that’s going to be difficult because scaling algorithms aren’t easy.
Scaling algorithms are the kind of thing computer science professors sit around writing really boring mathematical papers about.
Like I said earlier,
I think the best hope for scaling will be to use a x3 scaling algorithm and then downscale to x0.5,
but I’m not even going to think about that until I’ve fixed more of the unimplemented stuff.
If I fixed it tomorrow the games would look better,
but you’d still be left with no LED, no ‘flashlight mode’, no sound,
so you’d still have people saying they don’t want to play it.
That is equal than scaling to x1.5 like this( e.g. b/w horizontal pattern):
10101010 ==> 100100100100
I do not think it will look good.
If we do filtered scaling it will decay contrast and eat cpu.
It depends which scaling algorithm is used.
I haven’t specified anything.
It could be nearest neighbour, it could be linear, it could be bilinear…
But again, I’m not even thinking about that right now,
scaling is not even close to being the first thing on my todo list.
I’ve got all these functions to implement first:
And that’s not even counting the sound functions.
Don’t forget we have grayscale on Pokitto. Or we can do the interlacing I experimented with in the other thread.
My guess is the 3/2 scale can be done in one step and pretty quickly. I might try to do this once the code is open. I like experimenting with this kind of things.
Things like these could be a compile time option. I’m also thinking about additional options like different colors, or something like a “CRT” look – maybe the bright pixels could have a small “glow” around them. I’ll try to make some mockups when I come home.
Nice postprocessing can do miracles. Old games were made with the CRT look in mind, take a look at that difference:
From this very nice article.
I’ve done the “dumb 1.5x scaling” versions on Pokitto (every second pixel 2 pixels wide).
I don’t think it looks half bad.
But thats just me
If you can do that fast enough for the full screen, that would be very nice indeed!
Technically 2/3rds is already open source* (I haven’t got round to adding avr-libc’s licence because for that one I’ve been working from the documentation, not the actual source code),
but I probably won’t be accepting any PRs until I’m done because later on I’m going to split the repo into three parts so we end up with an avr-libc implementation, an Arduino implementation and an Arduboy2 implementation.
* I didn’t exactly get a say in the matter, I modified the original source code so I have to obey the already existing licences, LGPL for Arduino and MIT for Arduboy2.
Like I say though, I’m not even thinking about the scaling until I’ve got the other stuff out of the way.
Core functionality before anything flashy.
The core libs are LGPL, no? That means you can license your code what you want if it only uses the library. The modified library is still copyleft.
Sure, I don’t want to push it, I would just try it myself and leave the code somewhere as usual. Unfortunately I’ve discovered a new game and am spending most time playing it now, not doing much coding :[
Double-checked, it is LGPL. Their explanation of what uses what isn’t particularly clear.
You’ve got other projects to be working on, don’t add any more to the pile. :P
I want to be doing that, but my backlog is too big.
Yeah I’ve got too many ideas and only a limited number of brains 
But fortunately there are other brains around as well.
I’m hoping to get back to working on this more now that I’ve taken a scarily long break from it (I think the last time I touched this was January).
Today I’ve spent a bit of time cleaning up Sprites and getting Sprites::drawPlusMask working.
I have actually got some more advanced stuff working on my local copy,
but I want to make sure I get the API right the first time, or things could get messy.
I won’t give away what the feature is, but I’ll give one clue:
I had to ask @Vampirics for help with it.
Animation related ? 
Can’t wait for this to be fully done. This will make the Pokitto library so much larger and the new ‘features’ are quite nice too. 
I don’t know what sort of animation you’re expecting.
Arduboy games can already be fully animated.
All the drawing functions already work perfectly (as far as I’m aware… I’m half expecting something to sneak up on me).
It is something graphical though.
Maybe upscaling of the arduboy graphics so that the entire pokitto screen can be used?
That’s almost certainly going to look somewhat ugly,
and I’m not sure there’s enough processing power anyway.
Repainting the whole screen in 220x176(x4) mode is expensive.
Some examples…
Unscaled:
Scaled by 1.5:
Scaled to fill the screen width:
Scaled x2 (purely for comparison):
(Admittedly different algorithms give different results,
but hopefully this demonstrates that there will always be ugly artifacts.
Especially around dithered patterns.)
