Thanks for checking. The music was created especially for Canyon Racer to go along with it’s graphics and effects, so my preference would be that it’s not used in other games and demos.
bbbbbr
Creator of
Recent community posts
Cool to read the writeup and some of the things you encountered. Here's a couple tips that might be useful for using the GBDK toolchain:
> never render empty sprites and use up a vital sprite slot
Yes, png2asset operating in "metasprite" mode (the default, i.e. without "-map") will accomplish that. It treats tile regions with no pixels set as empty space and skips over them, so that when the metasprite frame is loaded into the OAM no sprite slots will be used for empty tiles. It is typically used with *_metasprite_*() functions which will update all the needed sprite entries at once.
> loading a whole new set of data + rewriting the bg map every animation frame
For multiple background images (or sprites) that share a common tileset the -source_tileset option for png2asset might be useful. It allows generating tilemaps that don't require reloading the tile if the shared tile data is already in place (or only reloading the tiledata that is unique and not shared).
There is also the gb\hblank_copy demo which demonstrates a way to load vram data faster for background animations that don't have tearing. It can be for tilemaps or tile data.
Hope these help if you work on a GBDK project again.
Gave it a full play through on the campaign + a couple levels on endless. Everything felt balanced and worked well, esp after getting into the flow of it. It gets busy, but in a way that was manageable and added to the action.
Haven't seen any bugs or issues.
Did notice the blue text on black background for mana can be a little hard to read. Something lighter might make that easier.
Unfortunately to my knowledge that patcher only works for games that have had patches hand-made for each game, so it's not able to patch games that aren't on it's list.
The fact that it covers more than a thousand games is due, among other contributors, to how absurdly prolific JoseJX was at making patches (~1184).
Cool!
If it's useful at all, here is an example from Canyon Racer, there are other ways to do it though.
https://github.com/bbbbbr/canyon-racer/blob/main/src/cart_mbc5/cartsave.c
https://github.com/bbbbbr/canyon-racer/blob/main/src/stats.c
A usual practice is to have a signature byte pattern and/or a checksum of the data to verify it's integrity and that it's not random data.
Glad you were able to fix it and that we were able to help! The banked memory model takes a while to get used to and even then still requires some caution.
I saw a new build is up so I downloaded it and gave a try. Played through the first two bosses in the campaign. It's looking, sounding and playing well! It'll be fun to give it a longer play when I have some time.
That does prompt on question- looks like it might not save progress right now? It would be convenient to be able to play a bit, save and then pick back up progress through a campaign. No worries if that isn't part of the plan, but thought I'd float it just in case. For the time being I just made a save state :)
Anyhow, congrats!
Thanks! Glad you enjoyed it.
I don't have a switch and am not sure what would be required to make it available on that platform, so that may not happen. In general it seems like the switch is somewhat locked down and prevents running homebrew software, however if there is a GBC emulator that can run ROMs for the switch then it should be able to run on something like that with no problem.
The cpu and embedded peripherals of the MegaDuck are a clone of the Game Boy which have been modified in small ways to make them incompatible. So patching would typically be disassembling the GB ROM to assembly and modifying the places where it uses changed registers and values. In practice it can be a little more complicated for things like the music driver.
The technical info for the process is available here:
https://megaduck.dev/#summary-of-hardware-changes-versus-the-game-boy
You're the first person I've heard mention trying it out. Cool to hear about it.
Into the idea of an easter egg link instead. If any ideas come to you, feel free to share and maybe I can integrate them. Some of these might be plausible alternates perhaps:
- Pandocs (technical reference for programming Game Boy hardware)
- GBDK or GBStudio homepages or help documentation
- The ROM's itch.io page (this page)
The rumble version means that it can produce rumble vibrations when run on MBC5 cartridges that have that feature. It's not very common (inside gadgets has one). I think only a few emulators support it (not sure which).
Otherwise canyon_racer_0.7.7_mbc5.gb is suitable for GB DMG and whatever other devices or emulators run GB Roms.
That's such a classy Gameboy and screen color. Looks great. :)
Yes, that seems reasonable to "auto-resume" some time after power-on and idle (if there is an existing save state). Should be easy, I can look into it soon.
When you turn it off, do you pause or return to the menu first? It used to auto-save once a minute, but that was adding a lot of overhead due to the amount of data saved. So I changed it to only save under these conditions:
- The game board will be saved when starting, stopping or pausing
It is tough! I made it hard so games would be short and give people's eyes a break and keep them from getting too much of the after-image motion effect.
Despite that, these people at RetroAchievements are impressive with how well they play the game. Better than I can for some of the challenges. https://retroachievements.org/game/24082
Can't remember why I thought it would be a good idea to even try, but I got stuck in here and couldn't get out. Seems like it shouldn't be possible to get in if you can't get out. :)
Anyhow, enjoyed the game, it was a lot of fun and well made. Didn't know about the SELECT thing until now, as some other peopled have mentioned. (That, or I quickly forgot, which is just as likely)