nesdev.org

Has this come across anybody's mind before? Making an entire SNES game using 2bpp sprites and tiles because it makes graphics easier to draw and you have more flexibility with animation frames since it takes half the time to update the same number of sprite cells.

And what would you gain from doing this instead of a NES game ?
Better music quality ?
After all why not, the idea is interesting. You could get 4 NES-style backgrounds using mode 0 by the way.

And doing software rotation/scaling effects on sprites will be faster if there is 2 layers than if there is 4 (again you could so something inbetween and use 3 layers, I'm pretty sure many early SNES games used 3 layer graphics for some areas to gain ROM space).

Yes I've thought about it before. It's not a bad idea. It could turn out very interesting. Give it a shot if you want.

Bregalad wrote:And what would you gain from doing this instead of a NES game ?

Retraux on Super NES would have at least these advantages over an NES game:

• MMC5/GBC features like a reliable scanline counter, memory-mapped * and /, palette per tile, more than 256 tiles in one BG, tile priority, and tile flipping.
• Virtual 12-pixel-wide-tiles by overlaying two BGs. This is used by Puyo Pop and Luminesweeper for GBA to allow for specific playfield sizes.
• More general DMA allowing the flexibility of VRAM at nearly the speed of MMC3 bank switching.
• More VRAM for multiple planes of vertical-mirrored backgrounds with no border artifacts.
• A more flexible window than just cutting off the left 8 pixels in case you still want to use 1-screen.
• Virtually no sprite flicker (100% overdraw instead of 25%).
• Faster sprite "mazing" with 16x16 pixel sprites, and clean motion off the left side of the screen.
• Four more buttons or a mouse without having to solder.
• RAM. Lots of RAM.

Why the hell are we still coding for the NES then? Let's all move on to the SNES!!!

tokumaru wrote:Why the hell are we still coding for the NES then?

Is there an SPC700 assembler as good as asm6 or ca65?

tepples wrote:Is there an SPC700 assembler as good as asm6 or ca65?

Seriously? You're stuck with the NES just because you can't compile/assemble a sound driver for the SNES?

Particularly, I like the simplicity of the NES (and other 8-bit machines). The idea of doing more with less is what fascinates me.

Is there a SNES debugger featuring both 65816 and SPC700 debugging as good as FCEU for the NES ?

The answer is NO. There is NOT ANY debugger for the SNES. If you're writing SNES code it will have bugs one day, and it will be a nightmare tracing them. Yes there is an old modified version of SNES9x with debugging features, but it is somewhat glitchy and lacking.

So Bregalad also programs for the NES because of the lack of tools for SNES development, is that right? I don't get you guys... If that's really the case, there are plenty of more modern platforms where you could be making games, I can't possibly believe it's just the lack of tools.

That, and I got motivated for NES before SNES or Genesis because there was a PowerPak before there was SNES PowerPak or EverDrive.

The difficulties with sound are what make NES more appealing to me than SNES. With NES it seems more likely I could pull together a sound engine from what is available. I'm not so sure about SNES.

The answer is NO. There is NOT ANY debugger for the SNES

You don't count bsnes-debugger ?

As for SPC assemblers, there's WLA-DX. I know some people don't like it, but I don't see what the big problem is. If you need example code you could look here for example.

BSNES debugger still isn't finished (unless it has been finished and that nobody told me).

I used WLA to code for the SPC700, however the SPC700 part of WLA is full of bugs, it occured freuquently that it didn't assemble what I told it to ! Also I lost the source of that sound engine I made which is sad.

BSNES debugger still isn't finished (unless it has been finished and that nobody told me).

Maybe your expectations are too high then. Of course there are additional features that I'd like to have too, but it's still useable. You can set breakpoints, step through the code, and you've got a memory viewer, plus some other stuff.

I used WLA to code for the SPC700, however the SPC700 part of WLA is full of bugs, it occured freuquently that it didn't assemble what I told it to !

I haven't had any problems with that (I'm using v9.4). Besides some strange syntax in a few cases - like the space in bbs/bbc instructions - I think it works just fine.

> BSNES debugger still isn't finished (unless it has been finished and that nobody told me).

You have to compile it yourself, but there's been a debugger in every build for the last 2-3 years. It isn't super fantastic because there's just me, and I have to do all the emulation and GUI work as well, but it's easily the best debugger in the SNES realm.

The last Qt debugger is in v073, and runs anywhere. The phoenix debugger in v070+ is Linux-only, but v076 will also work on Windows. I had to make a subclassed hex editor widget for it first.

The debugger not only steps and traces, but it also has a disassembler that goes forward and backward. I record read/write/exec and for the CPU, E/M/X bits for every executed opcode, and this data can also be written to disk and updated across multiple emulator runs.

> I used WLA to code for the SPC700, however the SPC700 part of WLA is full of bugs, it occured freuquently that it didn't assemble what I told it to !

You could try spcas for now, xkas will support it sometime between now and hell freezing over ...