Bytes 8 and 9, the Unit ID, can be read and written by a program using available library functions. It’s intended to uniquely identify units linked in some way for multi-player games. I don’t think there are currently any games using this but could in the future.
Bytes 10-15, the Unit Name, will generally be displayed during the boot sequence, if set. Like the Unit ID, library functions are available to read and write it. It could be used by a program to pre-fill an ID, such as in a high score table or the name of the player in a text adventure. Also, like the Unit ID, I don’t think any programs are currently using it.
To be clear, at the moment I haven’t actually made any alterations to the game code other than renaming the .ino to main.cpp and commenting out all the sound-related code (basically all of the uses of the sound variable and the definition of the sound variable itself).
Apart from that it’s basically the same as the code from my local branch of the original (the one I made the PR with).
The real voodoo is my Arduboy2 port (which is still unfinished unfortunately).
Will try the new bin tonight! Maybe you should share the repo
My biggest issue with the port is the resolution. A 128x64 game need to fit into a 110x88 canvas.
Horizontally it’s tempting to cut 16 pixels horizontally (and leave 1 pixel on both side) which would work for ‘normal levels’. The problem is boss rooms as they would not fit and the game will scroll a bit which will look strange. The boss rooms could be redesigned to accomodate the new screen size though.
Vertically it’s not much an issue as some area could be simply left empty, or the UI could be displayed higher than in the original version. This could be good because UI was sometime hidding the player on the Arduboy version.
@Pharap : never mind the graphics resolution. Have you considered how limited the gameplay mechanics are, given that there is 4x more screen space on Pokitto than Arduboy. The screen of canyon or some other feature that barely fits on Arduboy will be sparse on Pokitto.
IDK if you understand what I mean. Let’s say movement across a given screen is 8 times right and a jump. We will have to do big graphics on Pokitto to compensate for the lack of resolution in the gameplay mechanics OR we will have to redesign the levels.
Yes I understand about the fact that 110x88 is half resolution. But that’s kind of my point. If you want to port CastleBoy mostly “as is” to Pokitto you have two choices:
Use full Pokitto resolution and display the full Arduboy game. This is what is currently made using Arduboy display mode. But the issue is that the game frame is very small. We want to play full screen!
Use the resolution that is the closest to the original game -> Pokitto half resolution, and make the game fit within it. This way you can play full screen!
@jonne I understand what you say. If you want to fully use Pokitto’s hi-res, then you would have to make a completly new CastleBoy (CastleBoy 2?) game with new graphics, new physic and new mechanics. The scope of this project is completely different.
Personally I think the current approach of having a 128x64 block in the middle of a 220x176 screen is alright for now.
I don’t hold up much hope for being able to scale it up to full resolution without the graphics looking stretched or distorted,
and I refuse to use 110x88 and cut off 18 pixels, because those pixels are important for a lot of games.
Also there needs to be at least some space around the gameplay area so there’s room to fit the LED indicator sprite that I’m planning to add.
Not sure. I mean at best Arduboy2-Pokitto can take the game as is, with the same resolution, and display it in a bigger frame. Cropping the width of the game to make it fit Pokitto’s half resolution needs redesign of the game.
The mockup you posted is exactly what I meant. Slightly increasing the map height, adding 2 extra tiles at the bottom of all stages. Editing the maps to add the extra tiles at the bottom. I think it would be the best way to have a proper CastleBoy port on Pokitto.
Speaking of coding actually I think the best would be to replace all Arduboy calls by Pokitto calls. From there it would be possible to do anything such as adding colored sprites, changing resolution, etc…
Oops. Don’t hesitate to make a pull request for this improvement. I’m not sure why I didn’t used sprintf though. It seems so obvious…
For people who can’t be bothered to read the whole article, here’s the short version.
The Schlemiel the painter joke is as thus:
Shlemiel gets a job as a street painter, painting the dotted lines down the middle of the road. On the first day he takes a can of paint out to the road and finishes 300 yards of the road. “That’s pretty good!” says his boss, “you’re a fast worker!” and pays him a kopeck.
The next day Shlemiel only gets 150 yards done. “Well, that’s not nearly as good as yesterday, but you’re still a fast worker. 150 yards is respectable,” and pays him a kopeck.
The next day Shlemiel paints 30 yards of the road. “Only 30!” shouts his boss. “That’s unacceptable! On the first day you did ten times that much work! What’s going on?”
“I can’t help it,” says Shlemiel. “Every day I get farther and farther away from the paint can!”
Most sensible programmers will agree that Schlemiel is being very naive.
Some of those same programmers will write code like this:
std::strcat(buffer, "Some text.");
std::strcat(buffer, " Some more text.");
// ad nauseum
But what those programmers don’t realise is that std::strcat actually returns a value.
That value happens to be a pointer to the place in the buffer just after where the new text has been copied.
Congratulations ‘sensible’ programmers, you’re all Schlemiels. :P
Instead, what they should have written was this:
char * output = &buffer;
output = std::strcat(output, "Some text.");
output = std::strcat(output, " Some more text.");
// ad nauseum
Now, instead of doing an O(n) scan to find the end of the string, the function starts at the end.
Just think of how much processing power that saves.
(Of course, the really bright sparks out there would actually be yelling "no, don’t use std::strcat, use std::strncat", but that’s an entirely different story.)
Yeah but then there is also the context. I mean when writing code for Pokitto/Arduboy this matters. At my work, we do soft real-time system among other stuffs. We have a huge (but I really mean huuuuuge) codebase and rather quick turnover of coders so we always favor code simplicity over optimization. Then in practice if we see an issue and track it down to a performance problem, we start optimizing. But only when needed. This is critical to reduce the cost of code maintenance. But again, context…
This isn’t really a question of simplicity, both examples are quite simple.
This is more a question of knowing and understanding one’s tools,
and understanding algorithms and computational complexity.
If someone was holding a hammer upside down then you’d tell them.
It might look harmless enough on this scale, but if the text being operated on is especially large then this is a serious problem - the kind of thing that at best will cause a few seconds of lag and at worst will lock up the program.
And yes, that would come up when the code was profiled,
but it wouldn’t come up at all if the code was written correctly the first time around.
At any rate, if you were writing for desktop then you’d probably be using std::string or std::stringstream so this probably wouldn’t come up anyway,
and if you were using char arrays, you’d possibly be better off using std::copy anyway.
(All of which are simpler to use might I add.)
Also, to be clear, the ‘schlemiel the painter’ thing wasn’t a jab at what you’d ended up doing by accident, it just reminded me of that story because of the use of the str-family.
When it comes to code, I’m a firm believe in always asking “is there a better way of doing this?”.