nesdev.org

Posted: **Wed Sep 01, 2010 12:23 am**

(paraphrased from something I posted on another forum)
I actually am interested in SNES homebrew; I would reach the skill level where I could not only hack SMW, but make a completely new game as well. (I even have some ideas for a game...heck, I've even started RAM and ROM maps for it.) I'm not sure where to begin, though...I can probably design most of the game startup routine based off SMW's and the one somewhere on wikibooks.com, but there are plenty of things that I definitely wouldn't know how to do. I do have the SNES Development manual, but it is, well, kind of the opposite of a "For Dummies" book. (I will still be using it for some things, but...) Are there any basic homebrew tutorials anywhere, documents and stuff that would be good for that purpose? I've looked around and found some stuff (although pretty much all of it was designed for assemblers that I've never even heard of), but the one homebrew tutorial I found was very incomplete. Does anyone have any advice, suggestions, or anything?

Posted: **Wed Sep 01, 2010 12:56 am**

You can just cross-post, you don't need to use a quote tag if you're quoting yourself from another forum.

Posted: **Wed Sep 01, 2010 9:23 am**

haha what a lazzy guy XD

Posted: **Wed Sep 01, 2010 10:33 am**

Hacking and programming a game are different things. And copying a ton of code from SMW isn't going to help you much. Plus wouldn't that sort of be cheating? Plus if it's copied 1:1 it may be illegal.

If you want to develop homebrew for SNES that's wonderful. But you need to understand 65816 programming. Then you need to learn about how things on the SNES work. Then you need to start practicing by trying to do things probably in small steps. You have to build up. There is no hold your hand tutorial. The SNES Development Manuals are intended for serious developers. That's why they don't hold your hand. There is good information in them but they make the assumption that you are a seasoned or atleast very serious developer.

So there is no "for dummies" material for SNES that I know of. You'll have to actually put in serious time into figuring it out. It's really not all that hard. I'd say the hardest part of the SNES would be dealing with the SPC sound system. But then again in general I find having to write an audio engine and tools to be something I don't want to have to do. But the good news for SNES is that atleast 2 public engines exist for playing ModTracker type music on SNES with sound effects. XMSNES and another that I can't recall the name of at the moment.

Posted: **Wed Sep 01, 2010 1:16 pm**

Blanking off the top and bottom 16 pixels helps a lot.

Posted: **Wed Sep 01, 2010 3:32 pm**

The NES is very similar, the PPU is simpler to configure (only 8 registers), and there is a lot more source code available. There are many, many 6502 assembly programming books for beginners (it was the first low-cost CPU, after all). Old books from the late 70's and early 80s, but it's easy to find old books online, though. It's 100% applicable to the 65816, but I'm sure there must be some books for the 65816 specifically, not as many though.

Hacking code and writing code is different, in that hacking you can only see what the code is doing, but can't easily see why the code is doing it a certain way. It's a great way to learn about data formats though. You definitely will want your own data format for stuff unique to your game and will have to code it, so it sounds like you've got a good idea of how to start.

You'll find you can get a lot of really specific help around here, so if you have any questions, research and ask.

Posted: **Wed Sep 01, 2010 6:16 pm**

Hacking and programming a game are different things. And copying a ton of code from SMW isn't going to help you much. Plus wouldn't that sort of be cheating? Plus if it's copied 1:1 it may be illegal.

Well, I wasn't planning on copying a ton of code from SMW, partly because it's known for being a fairly inefficient game and partly because I'd like to do things my own way. But that's about the only game whose source code I've studied much.

If you want to develop homebrew for SNES that's wonderful. But you need to understand 65816 programming.

I'm pretty familiar with the 65816 opcode list and formats, if that's what you mean.

Then you need to learn about how things on the SNES work. Then you need to start practicing by trying to do things probably in small steps.

By "things on the SNES" you mean stuff like hardware registers, DMA, uploading data to VRAM, initializing the SPC-700, etc? As for practicing, well...so far, I'd pretty much figured I'd start at the beginning (literally), work my way through the reset routine, see what subroutines I'd need after that, and then just let things trickle down.

You have to build up. There is no hold your hand tutorial. The SNES Development Manuals are intended for serious developers. That's why they don't hold your hand. There is good information in them but they make the assumption that you are a seasoned or atleast very serious developer.

Eh...trial and error usually doesn't get me very far. (I know from experience.) If I don't know what I'm doing, how will I know where the problems lie?

So there is no "for dummies" material for SNES that I know of. You'll have to actually put in serious time into figuring it out. It's really not all that hard.

I don't know...if past experience (not just in programming, either) is anything to go by, if I try to figure out something mostly on my own, not just what something is, but how to do something, then it WILL be hard.

I'd say the hardest part of the SNES would be dealing with the SPC sound system. But then again in general I find having to write an audio engine and tools to be something I don't want to have to do.

Yeah, I've heard it's a pain. I have found a couple of SPC documents around, though, and the actual programming really doesn't sound much harder than plain old 65816 assembly. I'll just have to see...I have some ideas for how to work out my SPC engine, too.

But the good news for SNES is that atleast 2 public engines exist for playing ModTracker type music on SNES with sound effects. XMSNES and another that I can't recall the name of at the moment.

Huh?

It's 100% applicable to the 65816, but I'm sure there must be some books for the 65816 specifically, not as many though.

Like this?

Hacking code and writing code is different, in that hacking you can only see what the code is doing, but can't easily see why the code is doing it a certain way.It's a great way to learn about data formats though. You definitely will want your own data format for stuff unique to your game and will have to code it, so it sounds like you've got a good idea of how to start.

Very true. I plan to try to make everything fairly organized; I have a good idea how a lot of things will work.

Posted: **Wed Sep 01, 2010 8:49 pm**

You can try being very organized in learning things. If that's what works best for you, go for it. Personally I find it's better to learn things as you need them, so you understand why you need them. Opposed to learning about something and not really using it, forgetting it, and then having to revisit it. But it depends on how you learn.

You say you are familiar with 65816 opcodes, so I think you shouldn't have too much trouble. I'm not sure if you have done much 65816 programming but atleast you have a bit of experience. It really shouldn't be that hard and there is enough documentation out there. It just isn't wrapped up in a neat package. No "For Dummies" type resources. However you can probably ask here if you have a problem and hopefully someone will be able to help you.

As Memblers said, NES and SNES have alot in common and if SNES is too much for you, NES would be a great place to start. If you get good at using the NES then stepping up to the SNES should be no problem. But it's up to you. Do whatever suits you best.

Posted: **Wed Sep 01, 2010 9:29 pm**

imamelia wrote:Well, I wasn't planning on copying a ton of code from SMW, partly because it's known for being a fairly inefficient game and partly because I'd like to do things my own way. But that's about the only game whose source code I've studied much.

You can get a few ideas from how they laid things out, but I'd be very skeptical about the actual code since a lot of things in that game are flat out bizarre and don't really make any sense. As long as you don't plan on copy-pasting slabs of code it should be fine.

Since you would be familiar with xkas for patches, you can use that to make a really simple demo ROM to get started.

Code: Select all

lorom

Reset:
*cpu setup,not that different from what you see SMW doing*

NMI:
*any video updates if you enabled NMI somewhere*
rti

org $FFFC
    dw Reset    ;reset vector
org $FFEA
    dw NMI        ;NMI vector

Simple interactive demos like changing a color on screen with the controller or moving a sprite around I think are decent places to start. They require very little code and you'll already know a bunch of things from SMW hacking. ca65 is a very powerful assembler that can be used too, but requires more work for setup and isn't as suited for simple starter stuff like xkas is.

MotZilla wrote:Personally I find it's better to learn things as you need them, so you understand why you need them. Opposed to learning about something and not really using it, forgetting it, and then having to revisit it. But it depends on how you learn.

And if you hit a wall somewhere, just post a thread detailing what you tried and what went wrong and someone will definitely help. You won't stay stuck for long since we have plenty of SNES devers here to help.

Posted: **Thu Sep 02, 2010 9:42 am**

I find it hard to beleive that SMW hacking is so popular, when it has the reputation of being limited and sloppy.

Few things I've learned.

-Use height and legnth defined metasprites. Don't use a LUT for the offsets and attributes for each sprite in a metasprite. It takes forever doing it that method.

-If animating the game characters at 30 fps, a good trick is to force every object to be spawned, killed, and animated on even frames. Take 2 frames to load the character cels on a backbuffer, switch buffers on odd frames, and delay the oam one frame to match the sprite cels.

-If planing for multijointed sprites in your game, use center based coordinates instead of top left coordinates.

-Using 16x16 pixel tile background mode can make background manipulation easier.

-Don't be afraid to blank off the top and bottom of the screen when you need extra v-blank time. Even if you can fit everything you need within v-blank in the beginning, it makes it harder to add more enemy types and object types without constantly changing half your code.

-If you do use extra v-blank time, max it out. Make it up with sprite usage, animation, speed and tight controls.

Posted: **Thu Sep 02, 2010 10:18 am**

And in this world of widescreen TVs, don't be afraid to take the visible area all the way down to 168 lines (NTSC) or 200 lines (PAL). Players will push "zoom" on the TV's remote and see the game fill the screen with nothing cut off. New Super Mario Bros. Wii does something like this if the console is set to 4:3 mode.

Posted: **Thu Sep 02, 2010 11:30 am**

That's a good point Tepples.

I think what is perceived as acceptable for an oldschool 2D platformer has changed a lot since it's heyday. Pixelized graphics and low color count were frowned upon back then, but now they are perfectly accepted for oldschool 2D fans, however choppy animation was perfectly acceptable back then, but not by today's standards.

Posted: **Thu Sep 02, 2010 4:23 pm**

psychopathicteen wrote:I find it hard to beleive that SMW hacking is so popular, when it has the reputation of being limited and sloppy.

That's one of the reasons it is so popular. It's rewarding replacing the sloppy and limited parts of the original game with faster/more flexible. The are many patches which either add flexibility to the game or speed up the original code which also help Lunar Magic be as powerful as it is.

tepples wrote:And in this world of widescreen TVs, don't be afraid to take the visible area all the way down to 168 lines (NTSC) or 200 lines (PAL) Players will push "zoom" on the TV's remote and see the game fill the screen with nothing cut off.

I like this, although losing a significant amount of resolution on an already low res system may look kind of icky depending on how many lines you chop off. Still, I'd take that over 'PAL only' games if I absolutely needed more VBL time and I couldn't just chop up one large transfer into smaller chunks with acceptable results. If I were to make a 2D fighter with big sprites it'd be pretty much mandatory I guess.

Posted: **Fri Sep 03, 2010 7:09 am**

smkd wrote:
tepples wrote:And in this world of widescreen TVs, don't be afraid to take the visible area all the way down to 168 lines
I like this, although losing a significant amount of resolution on an already low res system may look kind of icky depending on how many lines you chop off.

Go down to 240x160 and you're no worse than the Game Boy Advance. Try this demo on your NES to see how bad it'd look. With more and more films and TV series being produced in HD and presented in letterbox, it won't be that bad. True, SDTV is interlaced, but you can do that on a Super NES too.

If I were to make a 2D fighter with big sprites it'd be pretty much mandatory I guess.

Super Street Fighter II (U) has a bit of letterbox, albeit not this much.

Posted: **Fri Sep 03, 2010 8:31 am**

I think Street Fighter 2's engine had fast sprite loading that didn't get maxed out due to having a small frame count. It probably could've been animated at 60fps if it had more ROM space, but didn't because it didn't have enough unique frames to fill an entire second.

nesdev.org

Advice for an aspiring homebrewer?

Advice for an aspiring homebrewer?