Skip to content

Releases: 32blit/32blit-sdk

Test: Do Not Eat!

25 Oct 11:53
@Gadgetoid Gadgetoid
TEST-DO-NOT-EAT
e8b4568
Compare
Choose a tag to compare
Test: Do Not Eat! 
CI: Switch to action-gh-release.

Switch from the long deprecated upload-release-asset to action-gh-release
and attempt to replicate the same behaviour.

Avoids nodejs and set-output deprecation warnings:
- https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/
- https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
Assets 10
Loading

Version 0.3.2

16 Aug 15:17
@Daft-Freak Daft-Freak
v0.3.2
264b70c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
Version 0.3.2 Latest
Latest

Less is More

This release is all about removing things, but in a good way.

delete[] examples

The examples now live over at https://github.com/32blit/32blit-examples. However if you still want to build them with the SDK , you can clone that repo to [sdk root]/examples like it was before.

duplication--

Some code is now shared between 32blit-stm32 and 32blit-pico as part of the ongoing quest of adding more features to -pico.

broken = false

Finally, this release is less broken due to being built with the latest tools. There's also fixes for building with pico-sdk 2.0.

What's Changed

Full Changelog: v0.3.1...v0.3.2

Contributors

Gadgetoid and Daft-Freak
Assets 12
Loading

v0.3.1

17 Jun 11:36
@Daft-Freak Daft-Freak
v0.3.1
b43a2e3
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.3.1

A Pico... Vision?

Realising that it's been ages since the last release, changes have piled up and I can make releases now... Here's a release!

New Hardware

The biggest change in this release is support for the PicoVision, which includes USB HID input and SD card storage (also available on the VGA board). Most code should port over easily with the exception that you can't directly access screen.data. It's possible to blit a Surface in the same format as a partial workaround though.

static uint16_t temp_framebuffer[160 * 120];
static blit::Surface temp_screen((uint8_t *)temp_framebuffer, blit::PixelFormat::BGR555, {160, 120});
...
screen.blit(&temp_screen, {0, 0, 160, 120}, {0, 0});

The "pico" port also has a lot more configuration, making it a easier to support new devices with st7789 displays and buttons wired to GPIO pins. An example of this is the Tufty2040, which is now supported as much as it can be with only five buttons.

Other Additions

  • blit_executable(name INTERNAL_FLASH src.cpp) can be used to build a "firmware" executable for the 32blit. This was previously done with blit_executable_int_flash, which was internal to the SDK.
  • Surface::get_pixel allows reading back data from Surfaces, without needing to access data or know the format. It also works in the PicoVision port.
  • set_screen_mode now takes an optional resolution, currently only used for the PicoVision.
  • The launcher is a bit more helpful about incompatible blit files instead of just going "Oops".
  • The usual bug fixes all over.

Compatibility

As usual, old .blit files should continue to work. This version does contain a minor API bump though, so new .blit files will not run on older firmware.

Aditionally, some loooong-deprecated wrappers have been removed. (SpriteSheet -> Surface, a few blit variants and 32blit.cmake)

What's Changed

Full Changelog: v0.3.0...v0.3.1

Contributors

ali1234, Gadgetoid, and Daft-Freak
Assets 12
Loading

Version 0.3.0

21 Feb 17:45
@Gadgetoid Gadgetoid
v0.3.0
9adbf2e
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
Version 0.3.0

Community Handover

Version 0.3.0 marks a major milestone in the 32blit project; its transfer into the capable hands of the most invested community members.

Why? There wont be another production run of the STM32-based 32blit handheld, and there may never be another handheld from Pimoroni bearing the 32blit moniker. We cannot sensibly afford to pour time into maintaining the 32blit tooling, but I think it's valuable enough that it deserves to live on.

The 32blit SDK has outlasted its namesake and now exists as a set of tools for building games targeting microcontrollers, with additional support for SDL to target Windows, Mac and Linux, and Emscripten for the web. We have hardware ports for the O.G. 32blit and many new RP2040/Raspberry Pi Pico based boards including PicoSystem.

The 32blit SDK is permissively licensed and we've handed the reins over to some community members so that they can continue to improve and build upon it while we might be busy elsewhere.

Thank You

You - the community - really took 32blit and ran, achieving something truly incredible and beyond our wildest expectations or imagination. Thank you!

I remain personally invested in the 32blit SDK and tooling, and will remain as a maintainer here. I will, however, take a back seat and let the community contributors guide the project. Where it goes from here is up to you.

But... I hope we'll see a full rebirth of the 32blit firmware/launcher on a PicoSystem someday.

What's Changed

Full Changelog: v0.2.3...v0.3.0

Contributors

Gadgetoid, Daft-Freak, and ThePythonator
Assets 10
Loading

Version 0.2.3

10 Mar 16:17
@Gadgetoid Gadgetoid
v0.2.3
8a4f36a
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
Version 0.2.3

Some Light Maintenance

Swept up some bugfixes and improvements made by @Daft-Freak into a release for your viewing pleasure.

Should also fix some of the examples for Pico/RP2040 which previously suffered from an uninitiated screen!

What's Changed

Full Changelog: v0.2.2...v0.2.3

Contributors

Daft-Freak
Assets 10
Loading

Version 0.2.2

27 Jan 15:43
@Gadgetoid Gadgetoid
v0.2.2
8eded36
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
Version 0.2.2

sudo Make My Code Faster

@Daft-Freak still seems to be finding things to tweak and fix, is code... ever done? This release includes lots of overdue cleanup, tidying and rejiggling of some untouched dark corners of the SDK plus some juicy new features to boot.

Perhaps the most notable is the availability of 30k of user ITCM RAM for 32blit hardware users.

ITCM RAM

ITCM stands for "Instruction Tightly Coupled Memory." This is super fast instruction RAM that's directly accessible to the ARM Cortex core on the STM32H750 in 32blit (This doesn't apply to PicoSystem, sorry!). That means it acts sort-of like an instruction cache, avoiding the actual instruction cache and making larger, time critical functions always fast without trampling the regular instruction cache (that sits between the CPU and QSPI flash to make it not utterly painful to use.)

Since QSPI accesses are - by comparison - low, putting some time critical code in ITCM can make an enormous difference to performance. Note this works best on chunks of code where you're negotiating a lot of instructions- Lua's bytecode interpreter is a good example -and wont have such a big impact to code that's bottlenecked by heavy computation or blocking on some other IO.

This change introduces blit_fast_code and blit_no_inline_fast_code which are convenience wrappers around the attributes that bump code into the .itcm section. Decorate up to 30K of your most sprawling, critical-path functions to turbo-boost your games.

See #737 for more information.

Screen Mode API Enhancements

The Screen Mode API has been changed to decouple resolution from colour depth bringing support for palette mode to both low/high resolution modes. There are six supported modes - two resolutions, and three pixel formats (RGB, RGB565, P) with different tradeoffs, the most memory efficient is - unsurprisingly - lores/paletted.

See #730

Let's Get Ready to Rumble

Thanks to @LordEidi we now have controller rumble support available in SDL builds. This makes testing rumble a little easier and means your rumble-enabled games can be shipped to regular ol' computer users without sacrificing your carefully crafted bzzt.

You don't need to change your code to take advantage of this. Just recompile against the latest SDK and your controllers should emit a little bzzzt when detected to let you know it's working.

See #729

Another World, another time?

The Another World game engine has been migrated to its own GitHub repository, complete with instructions for getting it up and running.

It hasn't worked properly for a long, long time now (ever?) and hopefully this should make it easier for an enterprising user to pop up and tinker with the code. Fancy a challenge? It lives here now: https://github.com/32blit/32blit-another-world

Save-b-Gone

Thanks to @Blackhawk-TA you can now remove savegames. Pooof. Gone. Self-destructing roguelike, anyone?

See #750

All The Things

New Contributors

Full Changelog: v0.2.1...v0.2.2

Contributors

mslinklater, Gadgetoid, and 3 other contributors
Assets 10
Loading

Version 0.2.1

29 Oct 13:58
@Gadgetoid Gadgetoid
v0.2.1
5487da2
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
Version 0.2.1

Pico Fixes

It's been a little over a month since we released @Daft-Freak's Pico SDK support as part of the 32blit SDK.

In the interim various rough edges have been bashed off and things tweaked. Nothing groundbreaking, but the ebb and flow of fixes that characterise a - I suppose - mature SDK.

PicoSystem users have been badgering away making games with the 32blit SDK, the PicoSystem C++ SDK and the PicoSystem MicroPython SDK. The 32blit SDK remains the best choice for games you want to ship on Itch.io and build cross-platform.

Moar Volts

Most notably we've raised the core voltage for RP2040 from 1.10v to 1.20v to help maintain a stable 250MHz clock on some marginal RP2040 chips. I think we've replaced most marginal PicoSystems (after figuring out that overclock was the issue) but this shouldd hopefully fix them once and for all. Note: I've run happily with 1.25v and 1.30v overclocks, and pushing the envelope is not uncommon with RP2040- this should have no noticable affect on battery or device lifespan.

Salient Changes

Special thanks to @ali1234 for fixing the Pico SDK cmake build, and adding a pico.toolchain.

@Daft-Freak has found and fixed an issue with GCC 10 which has been plaguing Arch users and Linux trailblazers for a while.

I've swapped us over to the new DFU tool built into the 32blit tools- and thus the minimum tools version is now 0.7.1. Don't forget to python3 -m pip install 32blit --upgrade.

That's it! That's the release.

All The Things

Full Changelog: v0.2.0...v0.2.1

Contributors

ali1234, Gadgetoid, and Daft-Freak
Assets 10
Loading
0 Join discussion

Version 0.2.0

13 Sep 14:42
@Gadgetoid Gadgetoid
v0.2.0
3789c78
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
Version 0.2.0

RC-omg-it-supports-Pico-now?

We originally planned for the PicoSystem to be a simple, PCB-based, RP2040 handheld that we cast out into the world to see what people would make of it.

Due to a few design tweaks here and there, it turned out nicer than expected. As a consequence we felt it deserved a bit more fanfare and support.

Cue @Daft-Freak who had (is anyone surprised?) quietly ported the 32blit SDK to Pico/RP2040.

The community has made the Pico SDK and tools indespensible for working on embedded games, indeed it was painful trying to port a game without the 32blit SDK. It made sense to bring PicoSystem under the same umbrella.

A few PicoSystem specific tweaks to @Daft-Freak's port later, we could build many 32blit examples and games for PicoSystem. A little effort to support the screen resolutions (120x120 and 240x240) made many of them very playable.

It all sort of fell into place.

I'm hoping this will be a win/win situation between PicoSystem and 32blit, injecting a little gusto into the thriving (but admittedly small) 32blit community while also giving PicoSystem users a running start.

Targeting PicoSystem has already brought some minor improvements back to the 32blit SDK, and some significant improvements and performance tweaks to some games.

Porting Games

The PicoSystem is a subset of the 32blit, with fewer buttons, no analog stick, less grunt, less memory and less screen real estate. Here's a comparison:

32blit PicoSystem
CPU 480MHz 250MHz †
RAM 611K § 151K to 207K (lores only ¶)
FPU Yes No
Buttons 6 + reset 4 + power
Joystick Yes No
Tilt Yes No
Sound 8CH mini speaker 1CH piezo booper ‡
Storage 32MB XiP QSPI + 128K Flash 12MB XiP QSPI
SD card for data 4MB QSPI for data (FAT)
Screen 320x240 (160x120 lores) 240x240 (120x120 lores)
Firmware Yes No
Launcher Browse + Launch Games No
  • † - technically 2 cores overclocked from 133MHz to 250MHz but the 32Blit SDK uses only one
  • ‡ - makes a best-effort attempt to play any SQUARE waveforms (single-channel)
  • § - 362K main RAM, 64K D3 RAM, 127K DTCMRAM, 58K ITCMRAM
  • ¶ - setting ALLOW_HIRES=0 allocates a doubled buffered 120x120 16bit framebuffer (56.25k) and disables the hires screen mode.

The key differences between the RP2040 in the PicoSystem and STM32H750 in the 32blit are the slower CPU (32blit SDK doesn't use the second core), lack of FPU (floating point acellerator) and the single, small RAM region (the 32blit's main RAM is bigger than the PicoSystem's entire RAM!).

When porting games of any complexity you'll have to pay special attention to RAM usage and your use of floating point calculations. Simpler games will generally port over easily, with a little consideration for the smaller screen resolution.

Finally, the PicoSystem doesn't have a beefy speaker like 32blit. Audio is limited to a simple piezo sounder that can play a single channel at a time. PicoSystem will run the audio subsystem and make a best effort attempt output any channel configured with a SQUARE wave using the specified frequency and duty-cycle. Noise/sine/triangle waveforms, mp3s and wave audio are not compatible.

Example: Rainbow Ascent

Here's the complete diff for the Rainbow Ascent port: f35eab3

  • Some text strings were changed in consideration of the 120x120 screen resolution.
  • A simple camera transform was added to keep the player in focus as they move left/right in the 160px (16 tile) wide level on a 120px wide screen.
  • Collision was fixed to check against the game bounds, since the level is - on PicoSystem at least - larger than the screen.
  • The jump sound just works on PicoSystem, but the swooshing waves noise does not.

The port also required @Daft-Freak's performance optimisation: 0e88007

New Stuff

  • PicoSystem/RP2040 support
  • (limited) RGB565 Surface and bitmap support
  • Optimisations for PicoSystem which apply to 32blit, too!
  • Emscripten-based ports now have "image-rendering" set on the canvas to avoid blurry upscaling on hi-dpi screens
  • Bugfix to menu clip rectangle to avoid crashes when drawing out-of-bounds
  • Tweaks & fixes to SDL port video capture
  • Fixed final 99% bug for installing games using 32blit tools
  • Geometry is now a playable game
  • Faster scrolly-tile (Rainbow Ascent) rendering
  • Bugfix to the envelope generator that prevents audio from sticking on

Final 99% bug

This deserves a special mention, since it might be the last holdout 99% bug that plagued the game flashing process on 32blit.

@Daft-Freak finally found a .blit that would reliably fail at 99% and traced the cause of the bug. Flashing games should now be 100% reliable!

See 5368ff3 for more information.

Sticky Audio Bug

There was a bug that would result in an envelope generator never decaying fully to 0. The ADSR now clamps to the sustain volume when proceeding to the sustain phase. If sustain is 0, the ADSR will turn off.

Geometry

In part motivated by the PicoSystem, and by using it as an excuse to sink some time into the 32blit examples I've finally managed to turn Geometry from a tech demo into a loosely playable game.

Split the asteroids, collect them to score, and keep an eye on your energy levels.

Version bump to 0.2.0

Since the PicoSystem/RP2040 support is a big deal, I've bumped the minor version number from 1, to 2. Bold. I know.

This is to make it easier to disambiguate pre and post PicoSystem SDK versions at a glance, but doesn't mean anything much otherwise.

Summary

For the full list of changes see: v0.1.14...v0.2.0

Contributors

Daft-Freak
Assets 10
Loading

Version 0.1.14 RC5

09 Aug 13:42
@Gadgetoid Gadgetoid
v0.1.14
e6dc0db
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
Version 0.1.14 RC5

RC5

We're still finding things to fix, including updating the FatFS library and making many, many little optimizations and quality of life improvements.

Timers

Prompted by me trying to shoe-horn "userdata" into Timers/Tweens so that I could the Lua state for 32blit-Lua, @Daft-Freak has made some fixes/tweaks to them both:

  • The blit::Timer callback is now a std::function giving timer callbacks access to the scope of your application
  • Loop count is now reset upon restarting a timer
  • Timers can now be paused. Inspired by commits from @Loxrie - https://github.com/Loxrie/32blit-beta/tree/feature/pause
  • Timers can be initialized through their constructor which now accepts callback, duration and loop. init is kept for backwards compatibility
  • The same applies to Tweens

File Metadata

Non .blit files can now have associated metadata by placing a <filename>.blmeta file alongside them. This is useful for identifying files such as game ROMs so they look shiny in the launcher.

FatFS & Filesystem

The FatFS library underpinning filesystem access to the SD card has been updated from R0.12C to R0.14b. This includes a number of fixes mostly for ExFAT (which we don't officially use) but for our purposes specifically fixes paths that include a tailing slash so that dir and dir/ are equivalent.

See the FatFS changelog for a complete list of fixes: http://www.elm-chan.org/fsw/ff/updates.txt

@Daft-Freak has added tracking of open files and ensured files are closed when switching game.

General Fixes & Tweaks

  • CMake will now check to see if the 32Blit tools fail and throw a fatal error rather than breaking
  • Emscripten version has been bumped from 2.0.4 to 2.0.18 fixing reliability issues downloading libjpeg. (This is forced to -O2 for faster CI builds)
  • transparent_index is now used by Palette to Palette blending operations
  • Rect.size is now const
  • Closing the system menu now avoids a huge timeskip in the game and Timers/Tweens are corrected
  • System name for 32Blit is now explicitly "32BLIT_HW" rather than "Generic"
  • Optimized hsv_to_rgba
  • Fixed SDL get_metadata description
  • Fix corner case off-by-one in RLE sprite unpacking
  • Fixes & tweaks to the battery I2C comms and status
  • Assorted preparations to bring 32blit-sdk support to PicoSystem

Raycaster

Working Bug spray! Plus lots of small tweaks and fixes.

All The Things

Once again, all of the changes in this release can be browsed in detail here: v0.1.13...v0.1.14

Contributors

Loxrie and Daft-Freak
Assets 8
Loading

Version 0.1.13

26 May 14:59
@Gadgetoid Gadgetoid
v0.1.13
dc79a90
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
Version 0.1.13

RC4

Wow. It's been a while.

More of you have got hold of your 32Blits and started experimenting, running into some of the remaining rough edges. @Daft-Freak, @ahnlak and @davidskeck have stepped in with edge case bugfixes, quality of life improvements, documentation tweaks and typo fixes.

There's nothing too groundbreaking here, save for general improvements.

USB Serial

USB serial has been run through the ringer by those of you experimenting with web USB. Installing games to 32Blit is now more robust than it's ever been and I regularly get away with running for f in examples/*/*.blit; do 32blit install $f; done without error. Thanks to @Daft-Freak for getting suck in this seemingly never ending chasm of issues.

Android!?

Someone asked about building on Android... so of course @Daft-Freak took that as a challenge accepted moment and made some tweaks to the SDK. I've always wanted to see how far the 32Blit SDK could go in terms of third-party devices, so this is really cool. Right now we don't have official support for Android in the continuous-integration or releases, but at least we know it's not outside the realm of possibility.

Sleep

While the 32Blit doesn't really have a real sleep mode yet, it pretends to be off if left idle by dimming the screen. Some miscellaneous changes have improved this behaviour and given better idle battery life.

Additionally the system will really sleep between updates, albeit in practise the continuous audio interrupt makes a mockery of this.

Tiled/TMX Tweaks

Loading a TMX-style map from a Tiled asset is less breaky and flags have been added to denote 16-bit data and indicate if transform data is included. You will need to update the 32Blit Tools for your map data to build/load correcty.

All The Changes

Find the complete list of changes here: v0.1.12...v0.1.13

Assets 8
Loading