It's a lot of work. I've managed to get data from Tiled into my ROM image, and I'm working on figuring out an architecture for scrolling and displaying a status bar.
Implementing scrolling and a status bar sounds simple but is actually a total pain. You only have two screens of tiles to work with, which can be arranged horizontally or vertically, and anything more complicated than scrolling in a single direction (including status bars) requires adjusting the scrolling registers between scanlines, and making sure that your status bar is in a different part of the tilemap (called "name tables") than your world.
A common way to accomplish this is to lay out your graphics memory so a certain address line turns on and off once every scanline, and then putting a chip (called a "mapper") on the game cartridge which wires that address line to a counter, which drives a CPU interrupt line. Simpler games like Super Mario Bros. don't need this extra chip, but you only get a single status bar + scrolling in one direction only. Games with scrolling in both directions often display graphical glitches on the edge of the screen, like Super Mario Bros. 3 (look at the right edge of the screen).
This is unnecessary on newer consoles, and less painful even on the Sega Master System.
> Nothing brings out creativity better than a limiting environment.
This is so true as a life principle!
I once read a book about the development of laser guided bombs [1], and in it it talked about how Texas Instruments made the first viable prototype [2] on a shoe-string budget even though they were competing against a large government contractor with a huge budget.
Because of the budgetary constraints, TI couldn't afford multi-million dollar wind tunnels for testing, so they built scale models of the bomb and dropped them into swimming pools, performing mathematics transforms on the results using the drag coefficients of water vs air. They came up with a bunch of other innovations as well, such as the shuttlecock seeker head and made a superior product that vastly outperformed the high-budget contractor.
My crypto professor made a point that stuck with me: There are many many problems that are, from an engineering standpoint, really cool and fun to solve, but can only really be used to harm or kill people. Building MIRVs or cluster bombs probably scratches the itches of a lot of aerospace engineers, but you're still using your design chops to build things that end lives.
Well, the alternative to PGMs is a lot more collateral damage. Want to take out that bridge? Carpet bomb or dive bomb and hope too many civilians/pilots don't die. Want to take out that factory? Carpet bomb or dive bomb and hope too many civilians/pilots don't die.
With PGMs you can take out a bridge with pinpoint accuracy in the middle of the night and nobody dies at all (directly, at least).
Just as easy maybe, but fundamentally incorrect. Its mechanism of action is killing people -- choosing to believe the claim that killing those people will save lives alters neither the purpose nor MO of the tool.
The goal of the mechanism is to kill fewer people than other available methods.
Tools are, simply put, devices that increase a user's leverage.
We live in a world full of tools capable of leveraging against life. We also live in a world with individuals and groups who - for whatever reasons - choose to use that leverage.
We can't get rid of tools like this. They are very straightforward inventions, especially as technical knowledge increases. The simplest nuclear fission reactor is a bomb. That does not make nuclear fission fundamentally worthless, and whether you agree that knowledge about it is a "good" or not, that knowledge is not going to simply disappear.
> choosing to believe the claim that killing those people will save lives alters neither the purpose nor MO of the tool.
How a tool is used does not change what it is or what it does. It does, however, define the purpose. If the purpose of killing someone is to prevent that individual from taking another life - or several other lives - then the purpose of the tool used is to save lives. The goal for perfecting a tool that is to be used for that purpose is to minimize the amount of lives taken, and damage done. That means a "better" bomb takes fewer lives, saving more.
If you choose to believe that an individual taking action against the life of another has not forfeit his/her own right to live, then you might consider this tool to have no legitimate purpose. Frankly, I disagree, and hope you will reconsider.
Honestly, I found after growing up programming with lots of restrictions, I developed lots of bad habits. I slowly developed a closed mind for "newfangled libraries," IDEs, and similar. I didn't learn to value computationally expensive things like internal consistency checks or logging. Eventually, and in part thanks to reading HN, I stepped out of that mindset of scarcity. Instead of trying to do things with limited resources, I now find it more worthwhile to find what resources exist and leverage them.
Also, maybe creativity isn't the same as being a good programmer. Creativity may get you out of a bind or into a new area, but I think being a good programmer is founded on many mundane characteristics, such as consistency and ability to conform to others.
The goal of an artist is to push boundaries, overcome restrictions. Absence of limitations is the goal of pretty much everything. That's what would be called perfection. Setting artificial restrictions is a way to learn by reduction of a problem by simplification, and setting boundaries requires creativity, too, but in principle, freedom is not the enemy.
In another reading, absence of limitations would be limiting, still, which would be paradox.
I liked this video explanation of NES scrolling ("The Nintendo Entertainment System's Loading Seam" by Retro Game Mechanics Explained) https://www.youtube.com/watch?v=wfrNnwJrujw
Wow! I just watched his video on the PacMan kill screen, and it finally made sense. I’ve read multiple posts about it before, but having it all presented in a video format with animations made it all make sense.
It's a lot of work. I've managed to get data from Tiled into my ROM image, and I'm working on figuring out an architecture for scrolling and displaying a status bar.
Implementing scrolling and a status bar sounds simple but is actually a total pain. You only have two screens of tiles to work with, which can be arranged horizontally or vertically, and anything more complicated than scrolling in a single direction (including status bars) requires adjusting the scrolling registers between scanlines, and making sure that your status bar is in a different part of the tilemap (called "name tables") than your world.
A common way to accomplish this is to lay out your graphics memory so a certain address line turns on and off once every scanline, and then putting a chip (called a "mapper") on the game cartridge which wires that address line to a counter, which drives a CPU interrupt line. Simpler games like Super Mario Bros. don't need this extra chip, but you only get a single status bar + scrolling in one direction only. Games with scrolling in both directions often display graphical glitches on the edge of the screen, like Super Mario Bros. 3 (look at the right edge of the screen).
This is unnecessary on newer consoles, and less painful even on the Sega Master System.