I've developed quite a few SNES-related things for fun, mostly using Go and C++, with some 65816 ASM sprinkled in.
https://github.com/alttpo/alttpo - A Link To The Past Online. Lets multiple players see and interact with one another in the same game world and synchronize their progress through the game. Exclusive to a customized fork of the bsnes emulator which provides a scripting language and PPU-integrated drawing routines to render remote player sprites. In retrospect, I consider this a dead-end architecture; redesigned in o2 project (see below).
https://github.com/alttpo/o2 - Second version of alttpo (see above) but this time targeted at SNES hardware console support (via SD2SNES flash cart USB feature) and does not require a customized emulator nor a scripting language. Trade-off here is a loss of the visual aspect (cannot see remote player sprites) due to tight hardware limitations in the amount of VRAM and limited SNES CPU cycles available. Work is in progress to gain back the remote sprite rendering as an optional add-on via the bsnes-plus WASM module support (see below). This project includes a 65816 machine code emitter library (pure Go) with support for named labels of branch targets. There is also a bare-bones headless SNES emulator library (pure Go) included for unit tests to verify the generated 65816 ASM and ROM patching mechanism.
https://github.com/alttpo/bsnes-plus - A fork of bsnes-plus in development that invokes WebAssembly modules when certain general SNES events occur, e.g. `on_nmi`, `on_power`, `on_reset`, `on_frame_present`. WASM code has access to a draw-list API for drawing into the various PPU layers, e.g. extra sprites, text (with PCF font support), basic shapes. WASM code can also receive arbitrary binary messages from external applications, e.g. to update remote player positions or exchange custom sprite graphics.
Great idea, there are so many games that would actually be played with even a basic co-op support like this. It's okay it's just an overlay with no shared-game state, still really fun!
I developed a modded emulator for Pokemon Red/Blue that allowed multiplayer (as in, multiple people walking around in the world, all interacting with the npcs and being able to battle each other) but unfortunately when I asked around there seemed to be no interest. I still have it on github, maybe some day I'll get back into it.
Oh but there is shared game state! Most of SRAM data is synced for ALTTP and there's even a PvP feature so you can slash at each other with swords and use some of the items to damage each other. Of course you can enable/disable whatever bits of state to sync or not.
Yep, it's aimed mostly at console users though it works with emulator too, just without sprite sync. WIP on sprite sync for emulator to bring that back
I'm more interested in SPC700 development for SNES music. Mesen-SX has a SPC debugger separate from the main debugger, but I'm not sure if it's more or less useful than bsnes-plus (I know the Mesen emulators have a far worse Linux UI when running under Mono, and I haven't tried running the Windows Mesen under Mono or real .NET yet). I don't know enough to judge if the disassembler is better or worse than bsnes-plus though.
A friend of mine from high school is working on a SNES tracker[0]. He’s deep into this space and could probably answer your questions if you catch him on stream[1]. He also authored many of the sections on the SNES development wiki linked by the article (under “bazz”).
The README says "the latest version of SNES Tracker is available exclusively via Patreon a few weeks before it becomes available on github". In https://github.com/bazz1tv/snestracker/releases, v0.2.0 was released in 2020-09-29 and says "the next version, v0.2.1 is already released to Patreon!" In reality, v0.2.1 was released publicly months later on 2021-02-19, with a tasteless notice saying "Note: the next version, v0.2.2 and v0.2.3 is already released to Patreon! This includes a critical bugfix (app hanging)."
The public Github repository you linked hasn't been updated in 11 months (v0.2.2 source and releases last updated in 2021-03-15), and v0.2.2 actually dates back to 2020-11-08 on Patreon. The Patreon (https://www.patreon.com/bazz1) was last updated in 2021-03-14 with v0.2.4, yet continues to take money for the past 11 months of silence. I've heard that he's stopped supplying builds to Patreon subscribers, and only giving them to Twitch subscribers.
This is my first time looking at his Twitch, and wow that's a lot of livestreaming uploads. I don't know if SNES Tracker is still being developed or not, and if Twitch subscribers receive newer builds of the tracker. In any case I'm definitely not subscribing.
I tried cloning the repo to view the current publicly released state. It has over 100 MB of files previously in history but deleted in a more recent commit, polluting non-shallow clones. I couldn't get it to build easily, so I downloaded the prebuilt Windows v0.2.2. The user interface is bare-bones and written in SDL, though I didn't poke around very deeply.
In any case I'll consider checking on his Twitch streams, and see if he can help me, though I prefer interacting with other people who don't behave in ethically dubious ways. I've already figured out how to make the S-DSP output sound. I'm currently working on learning S-SMP/SPC700 programming, writing/picking a hardware driver, (if I write my own driver) picking efficiently-implementable behaviors while remaining musically useful, or (if I pick an existing driver) learning the driver and build system. Eventually I want a characterization of the SNES's analog frequency/phase response (DAC impulse response plus analog filtering) so I can implement it in software. I feel eliminating unneeded audio latency, and implementing aliasing-free hardware-accurate resampling/filtering, are aspects that most emulators (even accurate ones like bsnes/higan) get wildly wrong, which I can improve with effort.
If you decide you really enjoy 65816 development, just a gentle reminder: The Apple IIGS dev community would love to have you and we're seeing new hardware releases at a pace we haven't seen since the 1990s.
And if there are people specifically interested in console-style IIgs game development, I've picked up and significantly enhanced my old graphics engine that was used for the IIgs Super Mario Bros demo.
I really want to make a retro version of my turn based strategy game Proximity[1] (pretty simple game and I've mostly made a version in Pico-8 already, so it should be doable) for NES, GB, SNES, GBA, and/or something similar, but I'd like to do it with the smallest amount of time and effort necessary (because I really don't have a lot of time anymore).
It seems like the new GBDK might be the easiest, especially since I recently ran into the source code[2] for a Wordle clone someone made using it that I could reference, but is there perhaps an even easier way? Most of the low-code software kits assume you're moving sprites around on a screen and don't seem like a good fit for the project.
I can't speak to any of the low code approaches, but I do know it wouldn't be that hard for a GBA implementation once you learned the hardware (and the resources for learning it are pretty good). Each hexagon could be its own sprite (probably even with the text on them already, to make it super trivial), and then you can probably just DMA them into the appropriate place in memory during vblank. So then it's just the game state/logic. All of which is pretty straightforward in C, though there is tooling around other languages as well.
https://github.com/gbadev-org/awesome-gbadev has a buncha resources, though I can personally attest to Tonc as being everything you need for getting up and running (at least it was years ago when I used it, but the GBA hasn't changed since then; just the tooling and environment may have gotten better)
Yes, out of all the old systems, I think the GBA is the easiest to program for. The design is more streamlined/modern overall so that you don't have to worry about things like bank switching and the GPU has a cleaner design than the SNES.
The BIOS, graphics, and audio firmware fit nicely with the 32bit ARM architecture such that all you have to do is poke data into the right address (usually a #define'ed pointer in C) and it DMAs to the hardware.
And unlike later consoles, there's no operating system or significant copy protection to deal with, you link in a crt0.s to put everything at the right address, load the rom into an emulator, and it will start displaying your game. When your ready, you pop a flashcart into your hardware and it will probably work too. It's all very nice.
I wasn't actually asking for anything low-code, I'm fine with coding, just hoping I can mostly stick with a C/C++ style approach without having to dig too deep into understanding the memory and registers and other things on a hardware level.
I've done some reading of materials on the hardware before (NES and GB mostly), and it's interesting, I just don't have the mental bandwidth at the moment to turn that casual understanding into usable code.
Maybe eventually I can get to that point, but for now if I can get by with mostly my game logic and some function calls to various wrappers for the hardware functionality, the better.
That link doesn't work well, just says it's not compatible with my device. There's a link that goes to some seo spam. Name not very googlable. Do u have a link to some screenshots/play video?
I have a video for the sequel when I released it on Xbox 360, although that's not what I linked to at first. The first link is Newgrounds, an old flash animation/game website that I first released the original game on 17 years ago (oh man, it's really been that long?).
I'm also currently working on a new version for desktop and hopefully eventually consoles that uses 3D models, larger maps, 8 team local support, map editor, hopefully either a campaign or challenge mode (eventually, maybe not on first release), and hoping to add support for up to 150-ish stream viewers to join various teams and play on one of the 8 teams (where they vote for moves kind of like in Twitch Plays Pokemon).
Here's a year old video when I was just starting the project, I desperately need to make a newer video (hopefully this weekend finally):
This could probably work with GBA. One issue is the small 240x160 resolution, meaning the design has to be compressed. Also, you probably wont be able to use sprites for everything, it doesnt support that many. But you could probably use 8bit backgrounds. GBA allows multiple tile-based background layers, with mode 0 or mode 1 you could implement a lot of effects when using sprites on top (https://problemkaputt.de/gbatek.htm#gbalcdvideocontroller).
Either use a clever way to map your game board to 8x8 tiles, or use a large number (4/8 bit paletted color) tiles so that you can just draw arbitray images (like a bitmap, but its set up in tiles). Or just give up on trying to exactly match the hardware and just draw the hole thing using a bit map mode (e.g. mode 4, with 256 color palette and double buffering) - but that also means implementing the parallax effect by hand (since theres only one layer).
Get ready to scroll if you do. The first significant chunk of the document was around Nintendo's (in)famous licensing process and instructions. It wasn't surprising, but confirms a lot about what we hear regularly about Nintendo of the 80s and 90s being hard to work with because of licensing and the way they treat third-party developers.
It's awesome. Not many new materials dedicated for good old game console programming. BTW, the book also covers Nintendo, Gameboy, Sega, Atari (!!), etc.
I generally advise against using bass for home-brew development. Bass is not a very well thought out assembler. I've never used it for 65816, but for other architectures like MIPS has some serious design issues that cause invalid code to be silently accepted by default, which is normally a disaster when it gets to debugging.
For MIPS at least, one of the completely wrong design decision has been to map basic register indices to raw numbers. For instance, in bass, this is a valid instruction:
add 2, 4, 5
which means "add register 4 and 5 together and write the result in register 2". Normally, one would write that line with the register aliases:
add v0, a0, a1
The problem comes with the fact that MIPS has also a "addi" (add immediate instruction) that you would use like this:
addi v0, a0, 5
"add the immediate value 5 to a0 and store the result in v0". So I guess the problem is clear: what happens if you instead write:
add v0, a0, 5
There are two possible reasonable outcomes: either the assembler should reject the above line as invalid, or it should silently convert it to "addi" which is what GNU as does for instance. Instead, with bass, the above is a perfectly valid line which gets assembled to the same of "add v0, a0, a1", which basically silently generates wrong code.
I think bass was a quick hack that overgrew its intended goal. I suggest to use something more mature.
Hi. I cannot belive that I actually registered on this page just to write this comment.
But I also got the feeling that there had been alot of mist around of bass, and I hope to lift some of it.
So first thing first: There _is_ and community fork. Url had been spammed allready. Yes we are active. To be honest, bass is more active then it probably ever had been before.
Next days we will also launch a project page (url: www.basm.dev). And yes .. that near passed away was as least a shock for us. But its also the reason why we took it up.
Now about @giovannibajo1 very valid statement:
Yes. Until recently that would had been true. Syntax may, or may not always be optimal. It's too sad that so far no Issue ticket, or Discord Message had reached me about this thoughts. In the end its a community project.
All I can say at this point is that the pure assembly syntax is to 100% fluid. You can mix it your own flavor. To be honest I never did MIPS using bass myself. But I would love to chat about "how a clean syntax should looks like".
I'm sorry if my comment came across as offensive, it wasn't my intent. I wasn't aware that there was a community fork of bass, and bass used to be pretty abandoned, so I've been advising people against it for quite some time. I'm happy if there's a community willing to reprise development on it.
I will open an issue, and I've joined the discord if you want to discuss about this. I'm happy to help though I've not really used it for years now, but I am happy to at least tell you why I stopped using it so that you can ponder this for future developments.
Some alternatives I've come across include macro packs for ca65 to make it assemble for instruction sets it doesn't understand natively, and I hear tass64 has macro packs too.
https://github.com/alttpo/alttpo - A Link To The Past Online. Lets multiple players see and interact with one another in the same game world and synchronize their progress through the game. Exclusive to a customized fork of the bsnes emulator which provides a scripting language and PPU-integrated drawing routines to render remote player sprites. In retrospect, I consider this a dead-end architecture; redesigned in o2 project (see below).
https://github.com/alttpo/o2 - Second version of alttpo (see above) but this time targeted at SNES hardware console support (via SD2SNES flash cart USB feature) and does not require a customized emulator nor a scripting language. Trade-off here is a loss of the visual aspect (cannot see remote player sprites) due to tight hardware limitations in the amount of VRAM and limited SNES CPU cycles available. Work is in progress to gain back the remote sprite rendering as an optional add-on via the bsnes-plus WASM module support (see below). This project includes a 65816 machine code emitter library (pure Go) with support for named labels of branch targets. There is also a bare-bones headless SNES emulator library (pure Go) included for unit tests to verify the generated 65816 ASM and ROM patching mechanism.
https://github.com/alttpo/bsnes-plus - A fork of bsnes-plus in development that invokes WebAssembly modules when certain general SNES events occur, e.g. `on_nmi`, `on_power`, `on_reset`, `on_frame_present`. WASM code has access to a draw-list API for drawing into the various PPU layers, e.g. extra sprites, text (with PCF font support), basic shapes. WASM code can also receive arbitrary binary messages from external applications, e.g. to update remote player positions or exchange custom sprite graphics.