A new version of Editroid has been released with some bug fixes (namely a bug that prevented certain screen-load code from running). Grab it from the RHDN Editroid page. Everything should work the same as Editroid 3.5, except fewer bugs.
Category Archives: Programming
This is an outline for the MaruMari homebrew project I’m working on for NES. As of posting this outline, the game is very incomplete. Things are subject to change, and suggestions are welcome.
Since it seems like this project is never going to get finished, I’m going to release what I have so far. Maybe input from others will help me focus and get things done. Worst case, if I never finish the project, at least I’ll have released something. So, here’s a quick guide to Suite-NES.
Just in case anybody else ever needs to know the format for FCEUX’s debugger’s config files (.deb), here it is, based on the source code for version 2.1.5 (found in \src\drivers\win\pref.cpp) and the contents of actual .deb files.
I’ve decided to share my simple Wavy-Ice hack. It allows the player to combine the wave beam and ice beam in Metroid. Note that this only works on a ROM expanded by Editroid 2.1.
Below is the source for the Zelda Automap hack (0.2). You can also download the source with the needed GFX file. The code should be assembled with snarfblASM. The resulting IPS file should be applied to the PRG0 version of the ROM (PRG1 appears to work as well, but the hack was created and tested […]
One of the tricky parts of working with NES ROMs in .NET is drawing game graphics. There are several approaches that could be tried, but many have problems or simply don’t suit NES graphics. GDI+ is much too slow with tile based graphics, especially indexed (paletted) graphics. GDI is a better fit, but it is […]
As “Romulus,” my NES Level Editor Framework, nears a usable state, I’ve decided it would be a good idea to give a summary of what it actually does. Romulus will be available as a .NET DLL, and will be usable from any .NET language. There is a thread for discussing Romulus on RHDN. Romulus actually […]
There’s a school of thought that tells us that all structs (i.e. value types) should be immutable. Immutable structs let us pretend that values and objects are the same thing. Ultimately, this is a discussion about what we want our code to look like. I’m not opposed to the idea of immutable structs, but this doesn’t need to be a hard-and-fast rule.