This is a thread where you can come ask all technical programming questions, without fear of people mocking you.  No matter how ridiculous the question, ask it here.  We will check it often.



The power of the NGD-riding unicorn wards off all mean-spirited people.  Feel safe here.

Ok I've got a few questions. I only just started seriously collecting and also only just found out about these homebrew carts and repros and such. So i hope my questiosn are relevant... maybe not lol.

1. I noticed someone offering really nice repros but only with certain donor carts. Why wont just any cart work?
2. How does one actually put a new game onto an old one? for example, placing Final Fantasy V onto an SNES sports game.
3. How do people make these super awesome personalized carts and labels such as with Battle kid?
4. What kind of programs and or equipment would be required should I study up more and decide i want to make my own games on carts? Where does one even begin?
5. Is this something someone could persue who has no prior knowledge of such activities?

lmao I never thought I'd see that pic again...

Anywho, cool thread. I will probably pop in here from time to time.

As this thread is supposed to be solely for homebrew related programming questions, these types of questions are sort of off-topic, but I'll answer them the best I can, since the unicorn compels me.

1. I noticed someone offering really nice repros but only with certain donor carts. Why wont just any cart work?

Certain games require certain mappers.  They won't work with any other mapper.  If you don't know what a mapper is, hit up the google!

2. How does one actually put a new game onto an old one? for example, placing Final Fantasy V onto an SNES sports game.

Assuming the mapper is correct, you would an eprom burner to do these sorts of things.  As I have no idea how this stuff works, since it isn't programming related, I'll tell you to again, hit up the google.

3. How do people make these super awesome personalized carts and labels such as with Battle kid?

I assume they are designing the labels in Photoshop/Illustrator and then printing them.  The colored cartridges are available from retrousb.com.

4. What kind of programs and or equipment would be required should I study up more and decide i want to make my own games on carts? Where does one even begin?

Again, this isn't programming related, so you'd need an eprom burner and god-knows what else.  I don't know anything about this, so you'll have to ask a Repro person.

5. Is this something someone could persue who has no prior knowledge of such activities?

I assume people aren't born with this innate knowledge, so I would imagine it is teachable.

What does a "program" look like, before you "assemble" it?

What would an average length (in lines) be for a full (NES) game program?

Do all (NES) programs have structural similarities? How is a program structured?

Do (NES) programs have to be optimized and tweaked in order to display properly on a real NES, (avoid slowdown and graphics glitches)? Is there a big disparity between emulation and the real rom/cart/console?

Is DMG Gameboy somehow impossible to program for?

Can you answer these questions in a way that some one who has never programmed anything before can understand?

Program before assembling is a text (source code), usually there are many text files with the code, along with files with various binary data, such as graphics sets, music, etc.

Average length is difficult to say, and it depends from programming language, and data storage approach - sometimes part of it is stored as binary, sometimes it is encoded in the source code, various amounts. Anyway, no less than thousand(s), even a simple one-screen logic game could be like 5000 lines of assembly code or 1500-2000 lines of C code.

Some structure is suggested by the hardware design, i.e. there is main loop and NMI handler. Any access to the VRAM needs to be done during vertical blanking, so it is usually put into the NMI handler. Other than this, structure could be different. Say, you sure that you game won't run longer than a TV frame per in-game frame, so you can put it into the NMI handler entirely. Or you put part of the code (v-blank related, music player) into the NMI handler, but the rest of the code into the main loop. Or, you can do slow calculations in the main loop, while user interaction is done in the NMI handler - this could be useful in logic games, where the game code needs quite some time, but user could move the cursor around any time he wants.

There are imperfections in the NES emulators, so yes, you can make a game that runs in an emulator, but not on the hardware, or vice versa. Speed-wise, normally there is no difference. So testing the program on the real hardware is a good idea, although with certain experience it is possible to make programs that will work on the hardware having no hardware, using knowledge of possible pitfalls and many emulators to testing.

Gameboy is not different from any other computing platform, you can program it as well. The hardware is different from the NES, though.

1. Not just any cart works because of hardware differences. Carts have a certain memory mapping chip depending on the amount of memory the ROM needs to be written on. Without this 'mapper', the NES wouldn't be able to properly find instructions and data from the big amount of memory inside the cart.
2. You can't just put new games on an old cartridge most of the time. The old memory chips are removed from the board and replaced by compatible rewritable memory.
3. That's an entirely different ballpark altogether. Printing quality labels is dependant on the printer, the paper you use, the method you use of adhering it to the cartridge. Some use a clear film over the label, others don't. There are a lot of ways to do labels. As for personalized cartridges, retrousb.com sells translucent NES carts, you could however also opt to make your own molds and cast these cartridge shells by hand, but it's a ridiculously pricy process
4. First of all, stick to developing roms that work in an emulator. Once you're ready to go the cart route, you'd need an (E)EPROM programmer with appropriate software and some software to split up your game ROM into a PRG and a CHR rom.
5. It is always worth pursueing something you're interested in, it is entirely possible to do so. The journey is one filled with knowledge.

Any program, no matter whether it's for a NES, PC, GameBoy or <insert system name here>, starts out as flat text. This text is then interpreted by specialized software to build binary files.
An average length for a full game, that's a tricky one. It depends on the algorithms you want to use and how efficiently you can implement them.

All games have at least some structural similarities. It is common to structure a game as follows:

• Initialize key variables
• Start a main game loop (loops are important, otherwise execution would halt)
• Poll controller(s) for input
• Change variables based on controller input (think sprite placement or something entirely different)
• Make extra checks, i.e. collision detection, valid input, etc.

There are more things you could add. What is important is that the NES/PC/Whatever gets the time to render the screen at some point. Video timing is critical.

As for optimization and tweaks to work properly on a real NES? It depends on the emulator you're using. No emulator works the same, so what is valid in one emulator could go wrong in the other. What works on an emulator could also fail to work on real hardware.
There are certainly emulators out there that do a really good job of mimicking the real hardware. Chances are, if it runs in that emulator, it'll work on the hardware.

Gameboys aren't impossible to program for. They use different hardware, among which a different CPU. So it's a different instruction set, different architecture, etc.
The Gameboy and Gameboy Colour use a modified Zilog Z80, so reading up on Z80 assembler could work for that. Otherwise, there are also probably C compilers available.


I've tried to explain these concepts to the best of my ability, if there are certain things that aren't clear, just send me a PM or let me know here.

Here's a great one

Can some vets post the tools and programs they use to get started, and links to where to download them etc.

1. In games like Super Mario Bros. (side scrolling) in a nutshell, is a game like this contain way more code then a game that is not side scrolling?
2. To make your sprite on screen move to the direction of the D pad being pushed, is this a simple code to enter that will connect it, to the D pad? or does it consist of tons of codes just to make it possible to have control of a character.
3. When a character jumps on screen, Is it contained in the programming of how fast/smooth/high/far it can jump? Never understood this in games like adventure island where you can sorta feel your jump by how long you hold down the jump button etc. for small jumps.

I dunno know im sure i have a million more, but just the simplest of things confuse me before even getting started lol

1. I'd say that one-way scrollers like SMB1 probably don't have much more code than a single screen game. The reason is that the persistence of enemies and destructible blocks only needs to last as long as they are onscreen. For a two-way scroller, suddenly you have to decide how long things are allowed to live off screen. Most games solve this with re-spawning, but re-spawning itself introduces the problem of how many instances of an enemy are allowed to be created. It's really when you get to two way scrollers that things begin to get hairy.

2. Moving a character with the d-pad doesn't involve much code, even when it is done with more advanced techniques.

3. A jump works by adding a velocity value onto a height value. And then, on every frame, an acceleration value is added to the velocity. Typically, the velocity will start out negative, making your character rise (going downwards is actually positive Y instead of upwards as is traditional on graph paper).  Eventually the velocity will go zero and then start to make your character go downwards again (because acceleration keeps getting added to it, the velocity might change from -5 to -4 to -3 to -2 to -1 to 0 to 1 to 2 to 3 to 4 to 5.....uuuup.......dooowwwn..... make sense?). This simple setup produces a smooth jump arc.   The jump can be stopped at any time by detecting that the jump button was released.

....that might be a great topic for a video....kinda hard to explain in a little paragraph! Maybe some others can help clarify this.

I am by no means a veteran, nor have I written any sort of game for the NES, however, I am a programmer. So let's start this off. All of the tools most people use can be found at http://nesdev.com/#PC
I'll try to answer the rest of your questions to the best of my ability.

1. I wouldn't say it has substantially more code. It all depends on how you define your levels. Scrolling is quite tricky to implement (to be honest, I don't have any idea where to start to do scrolling). The amount of code is greatly dependant upon your algorithm.
2. To make a character sprite move isn't as straightforward as 'connecting' a button to the sprite. You read in the state of all the buttons (the entire NES pad) and then check to see if a certain bit is a logic 1. You then write code that tells the NES to increment or decrement a certain variable based on the status of these bits coming from the NES pad.
3. All of a character's movements are contained in the programming. See my #2 answer, it is a simple matter of incrementing or decrementing variables based on external variables, say time.

WOW thanks man, starting to make a little more sense!

As a first project i would like to do a side scrolling platformer style game. Kinda like adventure island.

1. Is this dreaming too big for a first project? It dont have to play as good or look as good as AI, but something where the concept would be. a.) character moves left to right throwing stuff at enemies. 

Thats pretty much it lol. dont sound like much but probably pretty tough to code.

Gradual Games

Just watched the demo for the first time of Owlia, and man i have to say it is extremely impressive! If i could learn to design something just a tenth as good as that i would be over the moon lol. How long have you been going at nes programming?

Thats really impressive man!

Parpunk,

If you haven't programmed before, I would recommend starting smaller than a scrolling platformer, say with an arcade clone of sorts (but as your FIRST experiments, even smaller than that---just moving something around, playing a sound, just getting your feet wet with the basics!) I think most of us started small in some way or another. I had been programming for quite a while before I started on the NES. At nes programming specifically, I've been at it since november of '08. *edit* note, I think the NES can be your first system, just be prepared to take it slow. Or, spend some time with something like python/pygame, then come back. Everyone's path will be different; there's no wrong way to start. I started in QBasic, in the 90's.

Here's a wild question

Have any of the vet homebrewers (gradual games, sivak, bunnyboy and others) ever considered getting together and starting a combined company and start pumping out new games every couple of months??? LOL. Start the next capcom lol

I know it sounds crazy, but all you guys are so talented i bet it would really generate a rebirth in new NES games and production would be so much faster.

Im sure there would be alot of hurdles, legally, financially, timewise, schedule wise,
But just sounded like a pretty wild idea.

That's a neat idea, but let's keep this thread on topic. You could start a new thread with that idea perhaps. I think if I ever tried to recruit a team, it'd be for a SNES rpg or something in the future, we'll see. I might be done after Owlia, I'm not sure. I'll have to see how I feel!

let's try to keep all questions on topic.

and the topic is Programming questions.

No questions about how to make repro, setting up homebrew companies, none of that.

Just programming questions.

Thanks, Paul.

I intended this thread to be for people who are trying to program to come in and say "Hey, I'm trying to get this sprite to move across the screen.  Here's my code.  What's wrong with it?"

Or "I really want my sprite to collide with the background and stop.  What's the best way to go about this?"

The more generic questions are fine.  I just don't want this thread to get so far off of what I intended that it fails to serve its purpose in the future.

My bad, just so many questions all over the place. Did not mean to derail.

I've been one to usually use Tile Layer Pro for graphics. I used to use Tepples' nametable maker called 8name, but it likes to crash for me on Windows 8, so I switched to Shiru's newer program called NES Screen Tool: 

http://forums.nesdev.com/viewtopi...

I use ca65 as my assembler which has given me VERY little problems when building (I can only think of one confusing instance that happened lately). Google should find this rather quickly. There are other, more NES geared assemblers like ASM6 out there, but I just got used to ca65. It does require setting up a config file (I think the really good programmers call them linker files???), but once you have a basic one set up, you don't have to worry about it anymore. If anyone chooses to go the route of ca65, I can give a bare-bones config file that should get you going.

Of course some sort of text editor, whatever someone is comfortable with using. I guess that is the basics of what I use. I can't think of anything else that springs to mind.

Awesome thanks a lot Roth!

In general could you describe what each of the tools you mention do, and what order you go in when programming? Or the general consensus of what you need to use each program for? I have looked around in nerdy nights, but the very first lesson just starts out with Codes slapped in the thread, with no explaining of what the objective is in sight with the codes?? I dont know if i am supposed to already know what to do, but i literaly have no idea and have not found anywhere explaining how to get off the ground. 

Even though an one-way scrolling engine could contain not that much more code compared to a single screen game, that does not mean it is 'not than much' more complex than a single screen game. It is non-linear relation, scrolling introduces a number of problems to solve, making code considerable more complex. Like, world space in 16-bit coordinates (at least) with 'virtual camera'; unpacking level data row by row, as unpacked scrolling levels take a lot of room; updating video memory when needed; keeping status bar static via screen split or something; sprites that could go offscreen - a range of subproblems, as you can't now process all enemies on a level like in a single screen game, you have to keep amount of simultaneously processed enemies reasonable in some way. Also, while you can easily code a level for a single screen game without extra tools, you'll sure will need a custom map editor or a converter from some general map format - something that'll allow to edit large levels and pack them into your custom format. So you may need skills of PC programming as well.

Bottom line: there is a reason why so many homebrew games are single screen ones, and the reason is because it is noticeably easier. So don't start with a scrolling game like SMB right away.

I don't see camera space to screen space adding that much more code, just a loop that subtracts the camera's X and Y from each metasprite's X and Y.

Unpacking level data is a problem for a large single screen game, too.  Battle Kid had around 500 rooms I believe. If you string them out end to end, that's actually longer (in terms of sheer screen real-estate) than Nomolos. I'd be shocked if Sivak did that all in a text editor. So you could still need that skill (programming an editor for use on a PC) for a single screen game.

Actually updating the nametables for scrolling is definitely a challenge, but in my opinion does not introduce much complexity until you allow backtracking. Nomolos was originally single scrolling----and the number of problems I had to solve really exploded when I decided to rewrite the scrolling engine to allow backtracking. *edit* I suppose it is also possible I am taking for granted the step up from single screen since I've never made a single screen game! (on the NES...made lots in QBasic years ago)

I do agree though that starting with scrolling for one's first project, especially with not much experience prior, would not be wise. I'm just standing by my feeling that single-scrolling isn't a huge step up in complexity from single-screen. It's definitely a step up, but its just not...huge. haha.  Taking the step up to 8 way scrolling though would be project suicide for someone starting out. It took me several months to get Owlia's 8 way scrolling engine working correctly (compare that to...about an afternoon for Nomolos's scrolling engine..*edit* that's just scrolling though, that does not include all the problems I later had to solve as a result....). The hardest problem to solve there is updating the attribute table, and then updating both a row and column inside vblank without going past the end of vblank and mucking up the ppu with garbage. (*edit* I forgot also hiding update glitches....there are quite a few details here to cover)

I forgot about status bars---but that's because I don't like them and never use them

Sorry to flood your thread with super general noob questions KHAN games. It was a new thread with a sticky on it and it said "no matter how ridiculous" and "without fear of mocking", so...

Sniglet actually asked a question or two for which your answers were very illuminating for me, (I looked up "mappers", which is not something that relates to the Vectrex assembly programming I have been trying to learn about).

... I think if I had a very specific question with a project of my own, I would probably start my own thread, rather than getting lost in another one. Wouldn't specific questions about one's own active project warrant that???

So the answers to my own super general questions here were very welcome, and I am glad you made this thread!

... I did subsequently view the "Nerdy Nights" weekly tutorials, which are also linked from a sticky thread, though. Probably that is the most appropriate place for people to start. It looks like a very well organized introduction.

Stickied.

I hate to ask something like this, because I feel like it's asking too much. But I'm working on a puzzle game. I can make a level of it, but then I get stuck. Is there anyone willing to write out a code to show me, that would do something like this, just so I can see how it is done?

Just load a background screen and then when a certain button is pressed it loads the next background?

I've gotten stuck here a few times. Or if there's a NN that covers this that I missed, could you point me in that direction?