In the past they’ve said the tag is an engagement hack. :)
I think it’s straight GBDK, at least according to gbtoolsid: https://bbbbbr.github.io/gbtoolsid_web/
In the past they’ve said the tag is an engagement hack. :)
I think it’s straight GBDK, at least according to gbtoolsid: https://bbbbbr.github.io/gbtoolsid_web/
Posted a reply on github and adding a copy here in case you may not have gotten notification:
Thanks for opening this.
There are several different changes combined together in this PR and I’d like to know which specific ones were necessary to resolve the problem and which ones are precautionary but not essential.
In addition, while there is some free WRAM I am reserving that for other uses, so using a substantial amount of that for the ~2.3K tile cache isn’t the right approach right now. I’ll think about how else I’d like to approach that and may do a different implementation to achieve that.
Thanks! The flood fill is an implementation of the “span filling” algorithm described in the wikipedia link below. I made a naive flood fill first that used more memory and was noticeably slower, but this one runs pretty well.
It’s kind of fun just to make spirals/mazes and then watch it flood fill them. :)
https://en.wikipedia.org/wiki/Flood_fill#Span_filling
Most of the drawing tools are built on top of the GBDK drawing.h api, which saved a lot of time vs writing them all entirely from scratch.
Looks like you’re using GBDK (based on rom info).
If that’s the case then it could be as simple as builds flags ( -msm83:ap ).
If you are using one of the GBDK cross-platform Makefiles then even easier, just adding “pocket” to the TARGETS= line.
There’s some additional info here: https://gbdk.org/docs/api/docs_supported_consoles.html#autotoc_md144
And here: https://gbdk.org/docs/api/docs_supported_consoles.html#autotoc_md161
The Emulicious emulator supports the .pocket format if you want to test without a Analogue device.
(Really nicely put together game!)
Cool!
Since you seem all in on fitting in 32K, if music gets hard to fit there is a non-maintained fork of hugeDriver/Tracker that supports compression. I’ve used it in a few of my 32k games to squeeze more in.
It was originally documented here: https://github.com/SuperDisk/hUGETracker/issues/105
But now is kept around in my MegaDuck fork (still supports Game Boy): https://github.com/bbbbbr/hUGEDriver/releases/tag/megaduck_compression_v1.1
A ZIP file with all the ROMs can already be found at https://github.com/gbdev/gbcompo25 Direct link: https://github.com/gbdev/gbcompo25/archive/refs/heads/main.zip
Sources for the open-source entries are archived as individual repos here: https://github.com/gbcompo25/
Have a couple games that have been up for 5-6 years now. It would be nice to see their trends on a longer time scale than 1 year.
The current charts are great for recent data, but the limited range (1 year) and narrow aggregation (day or week) make it harder to see how the game is doing over a long time span.
If the aggregation range could be increased to Months and potentially Years, and the range increased to at least 5 years that would be helpful.
Alternately an easy way to export the entire download data to csv format.
Loving this a lot (gameplay and mechanics, difficulty progression, music, aesthetic).
A couple questions after playing it a bunch:
Can’t tell for sure, but it seems like when two different sizes of blocks will be formed after landing a piece, whether they break a 3x sequence depends on the order in which they’re created on the board.
On some of my d-pads that are a little more squirrely (analogue pocket) I occasionally get unwanted direction changes in worm mode (such as UP when pressing RIGHT). Some of this is surely my error, but it doesn’t happen much on better d-pads (clicky gba sp).
(What feels like input buffering seems to work well btw)
Found a small bug in tile editing mode:
Enter Tile Edit mode -> START -> B -> some times the location cursor sprites are no longer visible.
I think they are still getting moved in the OAM, but their tile is set to one which is all clear. Mainly happens for the first 3.
Edit: The tile select mode copy/paste instructions look like they might be reversed? START seems to paste and SELECT seems to copy.
And, a lil drawing:

Have played quite a bit of this now. Looking forward to reaching the 2k crash while it’s still an option. :)

It could be that making it randomly fair (as opposed to designed levels) might be algorithmically challenging, but perhaps there are ways to do that reliably. And/or ways for the game to ease back under certain conditions (such as halting lava climb while there aren’t enough landed blocks above the high water mark).
I guess it shouldn’t be surprising, but with more practice it’s become easier to get out of jams and jump around some edges. Fun to feel some progression.