Pokitto is on the way, what games should I make?


I don’t know, I’ll check this.


@jonne I charged the battery and it’s still there. It behaves like normal sound (changes with volume and goes away completely when sound is turned off), so I think it’s got to be something with the library rather than HW? I dunno, I have no clue how sound works here.


I was bored so I speedmodelled Pokitto in Blender. If anyone wants the model, here it is:

pokitto.blend (785.5 KB)

You can make fun animations:


Try out new color combinations and stuff.


More Pokittos for everyone :smile:


Alright, back to work.


Doom would be awesome… Kind of… Everything would be appriciated!


Someone could potentially look at chocolate Doom + FreeDoom.


Chocolate Doom aims for maximal portability.

Very nicely commented and already uses fixed point math. Uses SDL for IO. But hell lotta code and files, don’t know if I’d want to spend nights digging through that :sweat_smile:


Could it be possible to run it on pokitto? Hardwarewise… Of course minimalistic I think but it would be so cool


No one knows until someone tries :smiley: It would be the greatest thing anyone has done on Pokitto for sure, but I’ve been pleasantly surprised what this little thing can do. I’d bet it could run somehow, but the important thing is how much work it would require to port. I’ll take a look a look at that engine when I’m bored again.


I would be totally happy with a simple wolfenstein like clone… Nothing fancy just fully functioning like Jonnes demo… But fully working :smiley:


Portability comes at a cost. :P

(If you’ve never seen SDL’s internals, the reason it works on so many platforms is because there’s a metric ton of #ifdef-ing for every supported platform.)

I had a peek and it seems they ended up defining their own event system on top of SDL’s,
presumably in the name of portability.


Another interesting game: Abuse. 1995 MS-DOS game released into public domain (excluding sound).


Not sure it will work fine on Pokitto with cross control.
I remember it use a combination of cursor and mouse to play nicely.


I think this was recompiled for the Amiga…


Some additional ideas:

  • 3D Earth Viewer. Not a flat map, but an actual sphere, plus geo data.
  • Why not a whole Solar System? It would only render spheres in 3D, which is easy (and points as stars). But it has a catch: perspective deforms spheres into ellipses (not circles).


You know what? All these little ideas are really nice, but what I’m really thinking about is what I wanted to make from the start – a general 3D engine – the ultimate thing as far as graphics goes. That’s what my thoughts have been gravitating towards all the time, and I won’t have peace until I see how real this could become. It would be the same style as raycastlib – extremely portable, integer only, pure C – you could even combine the two libraries. And run it on a toaster.

I’ve quickly put together Bresenham’s line algorithm in SDL and am going to use it for triangle rasterization. Then make some fast interpolation algorithm with optional perspective correction, to fill the triangles with pixels. Then fast vertex transformation from world to camera and screen space, and visibility determination. Then some format to store 3D data in and a tool (Python) for conversion from obj, and that’s it, I can make a demo. Let’s see.


Since you want it to be extremely portable,
you’re going to forgo the fixed width types like uint8_t and write it in C89, right?


You can make things a little more portable by using “best for the desired purpose” width types like uint_least8_t and uint_fast8_t.


I’ll most likely use some C99 features, it isn’t that difficult to strip them. I just don’t want to build it from the ground up on C++ features and OOP because the nature of this library (as well as raycastlib) is such that it wouldn’t benefit from these too much – it’s just a bunch of pretty straightforward functions and the whole project is kinda small (the effort goes mostly to debugging, testing, fine tuning and making things smaller, not adding more stuff), and once it’s OOP from the start, it’s usually almost impossible to un-OOP it, let alone in an automatized way. Basically I’d see this as an “OpenGL” for (not only) Pokitto that “draws triangles”, upon which someone can build a nice high level OOP frontend/wrapper (like for example OpenSceneGraph). Such is my reasoning.


Sounds great! Debugging those algorithms can be really tedious, but I believe that is your special area. The big reason why I started to program for Pokitto was because programming is simple and there are no complex frameworks. Thought, in Pokitto GP, I had to play with 3D transformations again, which has once again proved laborious :frowning:

Anyway, with that kind of 3D engine you can make beautiful things on Pokitto :slight_smile:


You still have to be very careful to avoid overflow and underflow and to be aware of integer promotion,
so you’re pretty much in the same boat as when using the fundamental types.

The main advantages of the fixed width integer types are better expression of intent and specifying whether speed or size is the more important factor.

C++ != OOP

You don’t have to use classes.
Even the simple things like constexpr, enum classes and template functions are an improvement over C.

That’s not strictly true.

In most cases all you have to do is change all the member functions to free functions.

As I’ve said before, you don’t have to use inheritance and virtual functions to make use of classes.
Member functions alone are a big improvement over the struct + free function approach, and at no extra cost.