I'm using the MMC1 mapper. I would like to have a small status bar at the top of the screen, with the rest of the screen scrolling independently in any direction. I plan on using the sprite-0 hit detection to set the $2006, $2005 scroll regs.
What I'm trying to figure out is the best way to make use of my name tables. So far I have my main screen at $2000 and the status bar at $2400 with vertical mirroring.
I haven't actually coded the "scrolling the screen" part yet, but I assume how it will be done: if scrolling left or right, clobber a column of tiles in the main name table. if scrolling up or down, put the new data in a row of tiles. then adjust the PPU scroll regs as appropriate before end of VBLANK.
What seems wrong to me is what will happen if the screen scrolls down a few lines and then left or right. I'll clobber my status bar.
I guess part of me is trying to avoid writing code that will be wrong and get tossed... I try to plan out my code before writing it and I'm kinda stumped at the moment.
Any suggestions (that don't involve dropping my constraints of MMC1) ?
Oh, I really know how it is when you want to plan things out before you start writing. I've done the opposite, and trust me, it does end up where you throw it all away if you're not careful.
This might be really really hard to do. Because like you said, you'll clobber your status bar if you're not careful. I'd try working with only the space below the status bar on both nametables (even the one without the status bar). Try code it so that you're not working with a 32x30 name table, but like a 32x22 name table (If your status bar is 8 tiles tall). But this way, you'd have to adjust the Y-Scroll whenever it starts incorrectly rendering the status bar on bottom (due to mirroring) by however tall your bar is. This could be very tricky, but it's a thought.
Doesn't MMC1 have a single screen mirroring mode? You could use one nametable for a status bar, then use the other for gameplay. Of course, then you have garbage at the sides of the screen when scrolling horizontally, but then again, so did SMB3.
I never understood what "single screen mirroring" meant, but by what you just said that sounds like what I need. It should be fairly easy to test. Thanks!
[back from testing]
Yes, that looks like my solution. Thank you very much Dwedit.
The problem with using single screen mirroring for 8-way scroll is that you get garbage at the top and bottom as well as the sides. Using vertical mirroring for 8-way scroll (like SMB3 and Crystalis) removes the top/bottom garbage and still allows you to have a status bar.
I know that I'll get garbage; I'll live with it for now.
Crystalis in MMC3 and uses IRQs to handle flipping name tables and some really funky code to splice the two name tables together on the fly.
I'm trying to stay with MMC1 (for now) in case I want to fab a cart or two. We can purchase blank MMC1 boards (w/ MMC1 CPLD chip) from
www.retrousb.com. A member on this forum makes them.
ps- Crystalis is my favorite game
I spent a few months back in 2002 reverse engieering it (mostly how it stores map data).
CartCollector wrote:
The problem with using single screen mirroring for 8-way scroll is that you get garbage at the top and bottom as well as the sides.
Simply by having the status bar he already got rid of the top/bottom glitches. Think about it: there is a full name table dedicated to scrolling, but several lines of it are not displayed because the status bar is, leaving enough room to use as a buffer, avoiding any vertical glitches.
The horizontal glitches can be partially hidden by having the PPU mask the leftmost 8-pixel column. Unless you do something as drastic as Alfred Chicken, which fills the rightmost 8-pixel column with sprites (for a total of 16 hidden pixels), you'll still get some horizontal glitches.
Oh, SMB3 seems to have a height limit because of the status bar, that's never good. Crystalis gets rid of the limitation with IRQs, but that's just too much trouble, and requires at least an MMC3. If you're gonna have horizontal glitches anyway, better go with one-screen because there will be no height limit for the levels.
Ok, I've got the status bar working using sprite-0 hit detection. Thanks for your help guys and gals.
The playfield doesn't scroll yet, and I've made not attempt to hide "sprite-0". (plus I only have three meta-tiles defined, so the map looks very rough).
Anyway, feedback would be appreciated. It would be extremely awesome if someone with a dev cart would test it! I would like to know if my experiment so far works on real hardware (I don't have a dev cart).
It works in fceultra (latest win32 binary) and Nintendulator, but does not work in "80five.exe".
http://www.ecoligames.com/~djenkins/nes-game.nes (if that doesn't work then try
http://unwg.no-ip.com/~djenkins/nes-game.nes).
Just load it up and press "start" any time during the title screen animation. "select" will reboot the game. If you let the title screen finish, you can move around a few sprites in test mode (hero stolen from Faria - to be replaced once I learn to do pixel art and the other monster is my first attempt at pixel art).
Thanks for all of the feedback (so far and in the future).
[edit] about the horizontal line... that is when I'm done using the CPU and when I begin waiting for VBLANK (thanks to tepples for the suggestion).
I used the first link and it worked just fine in Firefox...
I had downloaded the earlier version, so naturally, Firefox opens the older version instead of the newest downloaded version.
i checked out your rom in my powerpak. everything worked as described. the initial intro screen scrolled in, with instructions listed. both sprites moved in tandem with one another; pressing 'a' caused them to scroll quickly. there was a blinking horizontal bar at the top of the screen (is this your cpu meter?).
once i pressed start, i was taken to a world map. there was a counter at the top, as well as x/y coordinates, but the screen wouldn't scroll.
nice work so far! getting anything running is an achievement in itself. would you ever be interested in sharing source code, so those of us who are beginners can learn alongside you?
Thank you for the testing on real hardware!
I have considered sharing code. I don't mind sharing the "engine", but I kinda want the game content itself (story, art work, text, etc...) to be 'secret' for a while (that stuff isn't even coded yet).
I will share this though: much of my "data" in the game isn't raw asm code. For example, I am developing a perl utility to convert a 24-bit BMP into my compressed maps. I wrote a utility in 'c' that translates a human-readable file all of my tile patterns. The actual syntax of the file is similar to the syntax one would find in "bind" (the DNS server software) config files. These tools are in a state of flux and I'm a bit embarrassed about their quality.
So my debate is over cleaning it up and sharing it. I'll probably just share it
. I keep my code in my own subversion server, so it shouldn't take much work to allow anonymous read-only access to it. I'll post if I open it up (I'll probably do it shortly).
Again, thanks for testing!
[edit] I just thought of something... I can set per-directory ACLs in SVN... so I can create (when the time comes) a "./src/story" or whatever and just deny read access to that folder.
I need to review my apache config and stuff before I open this up.
I'd love a utility that would convert a bitmap to a compressed map! I don't yet have the knowledge of other programming languages to create something like this. I'll most likely go for Visual Basic though; it has very nice drag and drop program creating capabilities.
Funny you made a map encoder like that, I did the same thing. At first I thought I'd code an interactive editor, but there is just so much to worry about in interactive programs that it'd take me a while to make it, so I opted for the bitmap conversion instead.
The encoder needs a bitmap with a graphical representation of all metatiles, so that it knows what to look for in the other files. The other files are just screen maps drawn with the metatiles from the first file. This handles the most complex part of my map compression, but I still have to manually create the metatiles (before encoding the screens) and manually arrange the screens (after they've been encoded).
I may or may not code other programs to simplify what I still have to do manually, depending on how boring designing the levels will feel.
Celius, I honestly think that the bitmap conversion is easier to implement than an interactive program with an UI. You could very well make it in VB, just look into bitmap manipulation, I'm sure there are classes for this.
clueless wrote:
Thank you for the testing on real hardware!
No problem. Anytime you need something tested, let me know. It's pretty simple to drop the ROM on my pak and test away. I'm looking forward to see how you progress with your project.
And yeah, I totally understand why you'd want to keep your game under wraps. I'm just interested in seeing as many beginner examples as I can. They're hard to come by, so example code is always appreciated. I've dabbled with the NES for over a year now, with nothing substantial to show. Nonetheless, it's fascinating to me and I'll work up enough initiative to program something one of these days.
On the intro screen you can see the tiles being loaded in at the top. You should mask it with a "status bar" of blank tiles, but in most cases it won't be noticeable on an NTSC TV. It will definitely show on a PAL TV, though.
I have three NES related projects in my subversion repository open for browsing. I'm trying to install "trac" so that you can get the full benefit of a web interface into subversion. I'll post URLs once I unscrew it.