There are C libraries for the NES.  Couldn't somebody just make a hack to the source code of a game like Shovel Knight to work with the NES PPU, and cut out some of the features that just wouldn't work?

Yes, I am aware of how the NES works and how it is different from modern day systems.  You should be able to recycle atleast some code (that doesn't have to do with graphics and audio updates), if your using an NES C compiler.

Unfortunately not. This (awesome) article written by one of the developers explains why: http://www.gamasutra.com/blogs/Da...

Shovel Knight was built to imitate a NES game, not to emulate one. Practically nothing from that game (apart from maybe a few altered sprites) would be transferrable to a cart. You'd have to rebuild it completely.

That's interesting to see the developer spell it out for those that don't understand the majority of the system limitations and why games like MM9 could never work properly on the NES.

I don't mean a pixel perfect port.

If I'm still doing this after I exhaust all my ideas for NES games, I very well may ask Yacht Club games for permission to do just that (a non pixel perfect port to the NES). It'd take years, but I'd love every second of it.

Putting a game on a cart is one thing (and I have no idea about how actually programming NES games works) but I've always wondered if emulation couldn't be an avenue for making NES styled games that far exceed the NES's capabilites ie; a gigantic dragon warrior style rpg that you could never actually put on an NES cart. Maybe I am misunderstanding the limitations of emulation (and I may be way off topic of making C versions of NES games) but it's always seemed to me that emulators were under utilized by homebrewers

I'd love to see MM9, MM10 and Shovel Knight reimagined on the NES. Those would carts I for sure would love to have

What would be the point?

If you make an emulator do stuff that the system can't do... then it is some kind of stand-alone game host engine, not an emulator for the target system.

If you want an NES-like game that violates the NES limitations, you just make a stand-alone PC game like Shovelknight.  No reason to even bother with working in ASM or trying to shoe-horn it into an emulator at that point.

The bottom line is that for ANY retro project to get ported to the NES would require rewriting the entire game in ASM, from scratch, and trimming back every aspect of the game the breaks the system limitations.

And probably cutting the game into multiple episodes to fit within the available memory constraints...
or custom engineering mapper hardware that handles a lot more memory than anything else out there on the system.


It is not a simple compile-time option of picking a different target system and using stock libraries.

One glaring issue I see is the game engine itself. When a game is written in C code, that code is compiled to talk to the Operating System it is running on (Windows, Linux, MAC, etc), then the OS talks to the hardware (Graphics cards, CPU, RAM, etc). When ASM code is assembled, it is made to talk directly to the hardware (PPU, CPU, RAM, etc). I would image this would be impossible to translate, because you must code ASM in a way that follows the NES architecture. Another problem would be controller input. There is a defined process on how the controller interacts with the CPU. Again, however a game is written for C code to handle input (joystick or keyboard) could not be translated to ASM.

Then there are sprite and background tiles. One thing you must remember about NES 6502 ASM language is that it doesn't know what a letter or a number is, only a graphic tile (which is really a collection of 1s and 0s arranged in a way that the PPU interprets it to an image). So, in C code, if you want "Hello" to be write to the screen, the word "Hello" is written in the code. In NES ASM, you must hand draw each letter and number into a graphic tile that is 8x8 pixels and then call that graphic tile to the screen in the code using the graphic tile's Hex value. So, in my game and the way I have my tiles arranged (depends game to game), "Hello" would look like this, "$11, $0E, $15, $15, $18".

I have never used C libraries (heck, I haven't looked at C++ code for 11 years), but from what I understand, C libraries for the NES are built with the understanding of NES hardware and you must code in a way that can be translated to ASM.

I guess the short of what I am trying to explain is, the game would have to be built entirely from scratch and build in the limitations as you go. I would venture to guess that it would be next to impossible (or so labor intensive that it may as well be impossible) to take a game that is solely written on general purpose programming language for another another system and translate it to NES Assembly.

EDIT: HAHA...I called it Linus. Fixed it to say Linux.

Can it be done? Sure. You'd have to start from scratch though. And it doesn't have to be written in asm, though it would benefit greatly from doing so. Isn't there also a stickied thread about this already?

This is the one type of thread I miss 3gengames in.

This made me giggle.

The kid knew a thing or two about homebrew and ASM.

    Where has that lovable sandpaper-wrapped kitten been? He used to help me out all the time with my assembly problems.

Modern developers can't cope with the hardware limitations and quirks of 30 year old hardware. Old Skool devs were really creative about finding ways around limitations and pushing/squeezing everything they could out of old hardware, new devs...not so much.

I think a way to phrase that, which is more fair to current developers, would be to say that if you're interested in making a commercially successful why would you choose to tie your hands behind your back if you don't have to?

Banned.


Oh, I know that, but he knew how to stir up controversy in these kinds of threads.

http://www.nintendoage.com/index....

Only a temp ban. He has chosen not to return.

Uh, no, try again

That's what I meant by hacking the source code.  Getting rid of any I/O functions, and replacing it with NES hardware stuff like oam, vblank, pattern tables etc.

Besides the obvious problems with the games being designed for different resolutions and bitmap graphics, there are lots of other very major issues that make C code for modern platforms not usable on the NES at all. Just a few of them:

- Any remotely modern C code is full of 32-bit int, float and double types, while NES C works effectively only with 8-bit;
- Any remotely modern C code relies to dynamic allocation of huge amounts of RAM, like megabytes for something minor, while NES has 2K (less than 1.5K for C programs);
- Any remotely modern C code relies to huge CPU horse power, using brute force approach in many cases, or just not the most effective implementations in trade for better readability, which is completely fine for modern platforms, but just won't work for NES;
- Any remotely modern C code is actually C++, object oriented. NES only has C compiler.

I'm going to answer the title of the thread, which asks "Why can't homebrew be more like indie games?" The answer for that is simple; NES homebrew games are made by programmers, usually by a single person at a time. Developing an NES game also requires a person who is more tech-savvy, and tech-savvy people usually don't have a taste for design or style; it's because of how opposite the two spectrums are, though there are people like Konjak or Shiru who pull it off reasonably well. Modern machines don't need careful code to render a game that's an NES styled game because they don't need carefully written code.  Just enough so that the game works.  Who cares if you need an i5 to play the game when it could run with no problems on something like a Pentium III?  People don't own Pentium III computers anymore, no need to optimize the code for such an old machine.

Now if it would be possible to, say, hire some guys from NESDev, the guys that designed Shovel Knight, Gashi-Gashi for the pixel art, and Chibi-Tech for the music, to design and make an NES game, yes, that is entirely possible. Only problem would be that it would be expensive to do so, especially more if this targets a niche audience that owns NES consoles. It'd be wise to make two versions of the same game, one for Nintendo's eShop, and one for the NES to maximize profits, but I'm not sure if Nintendo would be okay with that idea. That said, developing games for the NES is more profitable than designing any game for the Wii U, given it's horrid third party attach rate.

Bripro had to take down all his NES related dev stuff to get a Nintendo license, so almost certainly the answer would be no.

Maybe through an alternative game vendor then, such as Steam? Was the reason why he was forced to take down his development documents because it could possibly constitute piracy? I mean the NES is an old console, old enough where anything done to it shouldn't even matter.