nesdev.org

From my very limited exposure to fighting games (which I suck at)... - Please no more than three attack buttons. You have fighters where you have separate buttons for your left and right limbs. Don't do that. You also have fighters where you have five or six buttons of varying attack strengths, when...

By writing to the registers mid-frame, I didn't mean that I wanted sprite changes to take effect mid-frame. dougeff's post implied that you could upload OAM whenever, but be able to control when the newly uploaded OAM table is applied, so you'd only upload the 32-byte high table in the NMI routine a...

For a second I thought I could gain 512 bytes of DMA headroom by just writing to the OAM transfer registers mid-frame. Heh, guess that's not the case.

I suggest studying the OAM layout - you can find it here: https://wiki.superfamicom.org/snes/show/Sprites In short, you should have a section of RAM that represents what you want the contents of OAM to be, and then during NMI/Vblank (or force blank, where the display is turned off) you upload that R...

The source seems to indicate that this is mostly a result of the score counter calculation and fadeout transition occurring simultaneously (at least in the vanilla game?). Shaped fades seem to lag a lot of games simply on the basis of having to calculate hundreds of values per frame. This is actuall...

What's hilarious about smwcentral is how much they are afraid of slowdown when none of the stuff they do is CPU intense in the first place. It really depends on how much work you're already doing each frame. I was told once that the score counter can lag the game because it's updated every frame ev...

I personally used bazz's tutorial which you can find here: https://wiki.superfamicom.org/snes/show ... nvironment

I quite like the graphics myself. I don't suspect it would take a lot of effort to add one or two more shades. I think they're at a pretty good starting point.

I'm starting to sound like a broken record at this point, but this is what I mean when I say we need more engines and tools for homebrew dev. In any case, don't sweat it too much. If you keep your code separate from the underlying SMW base you should be able to more easily port your game over to an ...

Early systems like the NES drew the screen repeatedly one scanline at a time. This is why you have stuff like only 8 sprites per scanline - each row of pixels is processed individually and there's only so much processing time that can be spent on any given row. Framebuffer-based graphics processors ...

My engine already does everything Espozo's first paragraph mentions except for dynamic sprite and CGRAM allocation. I am actually halfway to the former, because I have updated my sprite placement function so that objects can override the tile and attribute bytes of OAM and therefore offset themselve...

But i was under the impression the snes actually supported different grades of transparency No, transparency is just half transparency. Multiple grades of transparency can be simulated by using additive color math and fading the palette to black. Example: the Great Fairy in LTTP (you'll notice ther...

I feel like everyone is forgetting that the SNES has a 15-bit RGB (as in non-indexed) colorspace and that this whole colorspace is used for color math. So you can't really apply color indexing optimizations here unless you want really big lookup tables (For any single CGRAM state, theoretically up t...

Also is there any difficulty difference between coding for HiROM or LoROM? HiROM is more complex, but it lets you store a consecutive run of 64kB of data (which, to my knowledge, can't really be done in LoROM). Note however that even if you're using HiROM, you can still do LoROM style accesses by u...

Both WLA and ca65 have a smart feature. But ca65 has generally been a lot more reliable for me, with less surprises in the form of detecting the wrong register size without warning about it. Only thing I had to do for ca65 was put rep #$30 at the top of source files so it knows that 16-bit is intend...