Next Jam coming up soon!

As i am the gamer here and not the programmer, i don’t vote. But as i pointed out before, i am always interested in games that are being made in spite of limitations and restrictions as i extremely admire the ideas and talent of people finding workarounds and solutions like that.


I haven’t had a look at tas mode yet, so consider these questions as a complete outsider.
I assume it supports scrolling, but wouldn’t a good way to do a HUD or general text area to allow an area to not scroll and just use tiles for the text?

It supports scrolling for the tiles. Text is either drawn as sprites or directly to the LCD, so it’s not affected by scrolling.

I haven’t looked at the documentation of this mode (yet) but if it’s nicely documented then the restriction seems fine to me.


I might be interested in taking part in the compo. But I feel PokittoLib is a bit underpowered and bloated and TAS mode has got limited functionality. I have never used them and I won’t be using any of them, tbh.

Could I take part in the compo with my own TAS? Thanks in advance!


I have nothing in principle against that, but:

open source has been a requirement for entries. The point of the jam is to let others learn.

As you haven’t shared the source of your demos, what’s your plan this time?

Making your own TAS library, and a game entry, while not showing at all how it is done is, in my view, slightly against the ethos of jamming.


Good point. I wasn’t aware of that basic requirement, but it seems fair to me.

I’m not releasing any source code, so I’m not taking part in the compo.


@SkyBerron I love your posts about all this kind of classic demos and showcases.
Are you just exploring the device and have fun or plan to build something in particular?


There are basically 2 options. SOC or MCU. In MCU’s, increasing internal RAM increases cost dramatically. If for example I had gone with an M4 cortex at the time, the chip cost would have been 3-4x higher.

SOC would have required external RAM and I didn’t have the skills required yet of designing such a system with high bandwith busses etc. Plus, adding I/O to a SOC is easier said than done, whereas an MCU will do many things out of the box.

If Pokitto had been 79-89€ I think many of us would not be here.

LPC11U68 was chosen because of its built-in USB flashing system. Almost all other chips require a secondary USB chip to be used. In a way the USBISP of LPC11U68 is very robust - there is no software way to break it.

Simplicity: I wanted a chip that was so simple that it was possible to understand completely. ARM Cortex-M0+ is the simplest new ARM chip, the instruction set is 1/4th of that of the bigger M4/M7


Its no secret that I resisted coming to the Pokitto platform for a long time as I thought it had too much memory - both flash and RAM. I actually see it as a challenge to create something play-worthy in such a small environment (the Arduboy).

This is the main advantage of smaller or restricted environments. You have to think small which means you actually finish projects!


For what its worth, origins of Pokitto (my blog 2015)


Edit: I didn’t even remember that I built the first LPC11U68 on an adapter board like that!


First of all, I must apologize because I recon my ramblings are a bit harsh and maybe way out of place.
I agree with all of you in your arguments.
I suppose my weird way of thinking needs more explanation. The first computer my father bought in the 80s had got a 3,5MHz Z80 8-bit CPU not capable of doing integer multiplication in a single instruction (let alone 1-cycle 32-bit muls) and came with 48kb RAM and 16 kb ROM and no custom graphic chips. Many wonderful games were made with that machine (ZX Spectrum 48k). The evolution of that machine was adding more RAM, propper sound chips, better keyboard and better storage in some models. Many many years later I get to see a 32-bit MCU much faster than anything seen in the home computers from the 80s, coupled with a screen capable of 220x176 @16bit color, but only having 36kb RAM (less than what the poor humble speccy had).
At first, you would assume you need to fit a framebuffer in RAM and try to get on with what is left free, supposing many simple games doesn’t need much RAM as long as the heavy static data is kept in flash. From the start, I thought this approach was plain wrong: if you really wanted to take the platform to its real limits, you don’t need to waste precious RAM in a framebuffer and you have to get the most of the native framebuffer the screen has already built in (no need to race the beam as there is no beam). Of course, you may need your own image buffers, but they are optional and only needed for some features: for instance, I am experimenting with 1-bpp image buffers for particle systems and persistence between frames, but you can skip them all together if you don’t need these features.
The Arduboy is a different curious setup: the screen is monochrome and its resolution is very low. Anyway, I’m still amazed about what ppl can do with such a limited platform (congrats, @filmote and @Vampirics, your work is amazing). Anyway, this platform is not appealing to me, maybe because it lacks colours and the need for reflashing to swap games.



I am not graphically minded so it is not a deal-breaker for me. Anyhow, I have teamed up with one of the best, @Vampirics for graphics.


A match made under auspicious stars with the blessings of heaven, I might add!


@SkyBerron No I think your ramblings were on point.

Take a look at the microcontroller section in a place like You will see that inside a microcontroller, RAM is very expensive.

SOC (system on chip) is typically an ARM core with integrated GPU etc as used in tablets. They got oodles of power - but guess what - you can not have the information on the internals. Raspberry Pi is not open. Only the top layers.

1 Like

I should add that I love coding directly to hw without intermediate API or HALs. I think nowadays they call it bare metal programming. That’s why I usually dislike graphic libraries and most current computer systems.