Picante: Render Buffer Go Bye-Bye

What's gone wrong

My initial approach to rendering in a timely manner involved native/C code to 'blit' bitmaps to an 8bpp render buffer.  Every frame, that render buffer is expanded into 16bpp stripes for transfer to the display.  At about 18-19fps, this was pretty tidy.

The next step I wanted to take was to render tilemaps to the background, so I found a tileset online and converted into bytes() objects in a .py file for import...and promptly ran out of RAM.

The New Proposed Approach

So then I started looking at a 4bpp (16 colour) render buffer with colour palette, and I didn't like the amount of pixel operations involved in drawing to it, let alone expanding it out to the stripe for display.

So my intention now is to store a list of render commands for each stripe of the display.  These commands could be partial 'blits' of a bitmap, or straight colour-fill, or whatever else.  The key thing is that they are only actually executed once all render commands have been given and everything's ready for the transfer.

This would mean individual bitmaps could be 4bpp 16-colour with palette, but they could choose from the whole RGB565 colour space of the display.  It would also mean that the blitting and display transfer could be done on the second core fairly easily.

First Step Hits Brick Wall: Shocker

I decided my first step was to move the SPI/Display code into the native/C module to simplify the whole structure and require fewer .py files to be uploaded to the Pico...but I couldn't figure out how to include files from the Pico SDK from the native module.

Then I properly read this page, which says the mpy module is linked against a firmware symbol table that can change with different versions of the firmware.  This means that my native mpy module is only guaranteed to work with the exact version of the firmware that I compile it against.  When other people deployed the .mpy module to their Pico, there's no guarantee it would work.

Two Ways Forward

That leaves me only two ways forward that I can see:

  1. Build custom firmware which contains the picante module so it can access internal functions easily
  2. Keep any hardware access in Python code and only do generic functions in C to improve any bottlenecks.

I don't want to be re-flashing the firmware every time I change something about the module, so for now I'm going to go with option 2.  If hardware access through micropython turns out to be a bottleneck, I can port any python code to C and directly include the generic stuff I've already written.

So What Now?

So now I dust myself off and write a split-language module with a main picante.py module which imports a native picante_c.mpy module.  Hopefully that structure will work and I can get down to the render system changes I was targeting in the beginning. :/

Comments

Post a Comment

Popular posts from this blog

Micro:Bit and SPI display

I want to explore the full potential of the BBC Micro:bits my school has. Making rock-paper-scissors games and the like is all well and good, and the students love it (for the most part), but it always feels a little bit gimmicky.  But when students really get engaged and suggest ideas for them (e.g. games, compass display), it all gets a little bit cramped and feels like it could  kinda  work, but not really . Then I found out that all the tiny strips on the edge are actually GPIO pins, not just the fat 0, 1 and 2 ones.  Since then, I've wanted to explore what I can do with it. Hence, over the last few days I have been trying to get the microbit to control a TFT display. I first went for this 2.4" display with a touchscreen.  The SPI interface is just for the microSD, not for the screen but I didn't think that would be a problem because the micro:bit has so many pins.  After much frustration, I discovered that there are many of the pins you can't reliably use extern
Read more

DCS World with TrackIR under Ubuntu

This is a record of my experience of setting this up.  It's meant more as a record for my future self than a tutorial, but maybe somebody will find it useful. 1 - Install DCS First step, install DCS World via the Steam client as normal.  2 - Install LinuxTrack Linuxtrack Download here: https://github.com/uglyDwarf/linuxtrack/wiki/Downloads   Instructions here: https://github.com/uglyDwarf/linuxtrack/wiki/universal-Linuxtrack-package   Using the gui (ltr_gui) requires qt4 libraries, which I could not find in my standard Ubuntu repositories, so I had to use the ppa instructions here: https://ubuntuhandbook.org/index.php/2020/07/install-qt4-ubuntu-20-04 Run ltr_gui from linuxtrack's bin directory to check everything works so far before moving on to get it running under Proton.  3 - Install LinuxTrack into the DCS World prefix NOTE: Attempting to install for Wine games WON'T WORK e.g. here https://github-wiki-see.page/m/uglyDwarf/linuxtrack/wiki/Wine-Games   This is because Ste
Read more

Cardboard Mock-up of USB Joystick

Image
For years now (literally years ), I have been playing around with the idea of making a USB joystick.  You may have seen my previous experiment in building a throttle control . I wanted to use a similar idea to the throttle, taking the angular motion of the handle and magnify it when applying it to the potentiometer.  e.g. move the handle through 45 degrees and the potentiometer gets moved through 90 degrees. I also wanted it anchored at the rear, so I can build a mount to attach it to my computer chair. In the video you can see a cardboard mock-up I made today.  I'm amazed it worked at all, but it even provides a solid foundation for designing the proper plywood one. The process of making a cardboard mock-up was really useful.  There were three fatal flaws in my sketch design which I would not have found out until I tried to make it: Pushing the joystick left/right when it was already pulled full back makes it catch on the rear support. The internal supports in the
Read more