Impressive demo!! It runs smoothly on the HW too
Looking good, controls seem a little fast for me though
From a gfx point of view, is the renderer capable of a little dithering to hide the banding a little?
Without meaning to turn this into a debate,
if you have the RAM to spare then you could theoretically store the levels on SD card and thus have more than 10 levels.
(That’s the sort of thing I always intended to do, but I never managed to get the SD API working,
and then I never found the time to write anything before getting distracted by something else.)
Yes, you can see it enabled in the SDL version – I turned it off for Pokitto for now but I’ll see, performance tuning will come much later.
Of course, my approach here is the same as with the book reader – I don’t want permanent storage to be required and I don’t want to add that extra complexity of reading files and a dependency on file handling library. My plan is to e.g. have game saves only as an optional feature depending on platform, and each platform can implement it differently (e.g. saving to files vs eeprom etc.).
The game would be a base for potential forks that could add this. People could e.g. add multiplayer and similar things.
Although I can see that point of view, I would prefer my projects to be a single .bin file, but considering that 99.9% of pokitto users will be using an SD card, if a gameI was working on needed a little more space, I wouldn’t hesitate to throw a folder full of data on the SD card.
I really want to avoid files at any cost and I think it is very possible. At very worst I can split the game into two parts, or create a smaller version with fewer levels or fewer textures or something, but I have a lot of ideas on where to save space. It’s not just the portability and simplicity that I aim for, but I also want to see and show what’s possible within these limits.
You may have noticed there are only robots as enemies – this is because I not only want the game to be compatible with different devices, but also people, i.e. children, people who hate blood etc. It is also further aligned with my pacifist nature, though I don’t mind violence in video games at all. Here are the enemy and weapon sprites I have so far:
All images in the game, i.e. sprites, textures, backgrounds etc., are 32x32 pixels. One compression trick I use for images is that even though the game uses a 256 color palette (which I’ve also made), each image only uses its own 16 color subpalette of this main palette (as e.g. old Pokémon games did), so each pixel only takes 4 bits instead of 1 byte and thus only takes about 50% of space. I also try to use as few sprites as possible, e.g. my explosion animation is actually only one frame and the explosion sprite simply grows bigger to look like animated, and this explosion sprite is also reused in weapon fire animation etc. Also robots with wheels don’t really need a walk animation frame etc.
Whatever how you do it, I am sure it’s will be for the best! Can’t wait to see the progress.
Here it is with the dithering, left is 2x subsampled (as it is now), right is no subsampling (runs a bit slowly):
One thing I would really like to see in a raycast game , especially on the Pokitto, is rotated sprites. Sure it would mean a lot more art, but having the sprites rotatable to match the viewing angle would be out of this world!
Even if the effect was only used for collectable objects or background sprites, enemies would usually be facing you anyway
If you mean rotating around y-axis that would mean having a lot of sprite bitmaps from different angles. Unless there is something like sprite stacks,
but that would need a lot of bitmaps too (and a lot of cpu cycles).
Edit: Actually, sprite stacks would fit better to isometric games
I was thinking more of just having a sprite sheet for the image from all angles of rotation and selecting the correct frame from the angle of view.
That’s possible and easy to do of course, I’ve even managed to place real 3D objects rendered with my other lib:
The issue is the limited space, so I’d only do it if there is space left at the end.
Things I still don’t have figured out include:
- name of the game
- the ultimate weapon and what it should do
Ultimate Weapon: Tiny Pokitto, making monsters love each other and explode for good
Have returned to developing this again after a while.
-g1 have any impact on the bin size? It seems like not, but on PC it does.
On its own, I’m not sure… but you’ll probably use that in conjunction with
-Og, which certainly will have an impact.
Edit: the debugging information added by
-g1 probably stays in the elf and doesn’t get copied into the bin, which would explain your observation. GCC’s documentation is rather vague about how this flag works.
I thought so, thank you
I now have all enemies and textures, am at about 92 kb.
Coming up with a name is extremely difficult, I’ve spent a few days on it – especially if you want to avoid possible trademark violations etc.
I’m now thinking CorpoDearm (a wordplay on carpe diem):
What do you think?
I like the logo.
What does it mean?