nesdev.org

Sik wrote:Given that until then all consoles [other than Vectrex] either used registers or framebuffers (SG-1000 would use tilemaps and sprites, but it was launched the same day as the Famicom), it's not that surprising that the NES hardware has oddities like that.

The TI-99/4 computer (1979-06), CreatiVision console (early 1981), and ColecoVision console (1982-08) predated the Famicom and SG-1000 (1983-07-15) and used the same tile-based TI TMS9918 series VDC as the SG-1000. The ColecoVision port of Donkey Kong is believed to be the direct inspiration for the Famicom, as 6502freak suggested in another topic.

The one drawback of CHR RAM for a beginner is that it's a bit harder to get Hello World up on the screen, but that's about it. And then UNROM, BNROM, or AOROM should satisfy you until you get up to needing save RAM.

So Zelda switches between mirroring modes (horizontal -> vertical -> horizontal) when panning screens. Is this possible with NROM? If not, would one have to go the Metal Storm route (fade to solid colour, move character)?
Zelda also has the advantage of SRAM. Would this need a password system? Presumably, formatted in a bit per dungeon completed and item found?

I've also started work on a sound engine. It won't get in the way and will be as short as possible.

tokumaru wrote:

Alp wrote:

Great job with the perspective! A lot of people fail miserably at representing perspective in a system that absolutely can't do accurate perspective, but this is very pleasing to the eye.

If you make copies of that house, won't they all have their own vanishing point?

Nameguy wrote:Is this possible with NROM?

No.

If not, would one have to go the Metal Storm route (fade to solid colour, move character)?

No, there's several ways to achieve continuous scrolling. For example, instead you could accept color artifacts at the left/right edge of the screen, as in SMB3 or Kirby's Dreamland.

Zelda also has the advantage of SRAM. Would this need a password system? Presumably, formatted in a bit per dungeon completed and item found?

Yeah, that would be a way to achieve it.

Nameguy wrote:So Zelda switches between mirroring modes (horizontal -> vertical -> horizontal) when panning screens. Is this possible with NROM?

No, NROM and the simple discrete logic mappers can't change mirroring. But using that for screen transitions is overkill, since it's possible to get even 8-way scrolling with plain old NROM without artifacts. You just have to figure out the best way to set up the name tables, considering the screen layout (status bar? top or bottom?) and the type of scrolling (vertical? horizontal? diagonal?).

Both the original Zelda and Cat Quest have a status bar at the top of the screen. The cleanest setup in this case would be to use vertical mirroring (i.e. name tables side by side), for complete freedom of horizontal movement. The status bar should be kept in one of the nametable only, freeing up some space at the top of the other one, which could be used for scrolling vertically.

If not, would one have to go the Metal Storm route (fade to solid colour, move character)?

In most cases there's no need to sacrifice scrolling. There's a lot you can do with plain old horizontal/vertical mirroring without even having to switch between them.

Zelda also has the advantage of SRAM. Would this need a password system? Presumably, formatted in a bit per dungeon completed and item found?

Long games surely need either battery backed RAM (some games are know to battery back the CHR-RAM! It's a cheaper way to get a few bytes of save data at the cost of a few tiles) or passwords. For passwords, in addition to the data being "saved", some space has to be spent on error detection. Tepples has done some work on passwords, he can probably help with that.

If you make copies of that house, won't they all have their own vanishing point?

Which is precisely why I said the NES can't do accurate perspective: You'd waste all your tileset (if one is even enough!), and all the houses would have to change when the screen scrolled. So, given the limitations of the system, he pulled off a pretty interesting effect, and as long as houses are reasonable spaced, the conflicting vanishing points won't be so obvious.

A question for a larger game:
Is it possible to create a larger CHR file, for canvassing purposes in yy-chr?

I stripped out the sample file, and have a 32KB chr, but I'm not sure what size is optimal for a UxROM game. I would normally post a chr file, but this one is rather... adult. heh.

Alp wrote:what size is optimal for a UxROM game

The entire point of using RAM is that there isn't a real threshold for where the memory allocation becomes "unreasonable".

As a vague rule of thumb, I'd probably say "not more than half of the entire game data for CHR", but if you're planning on making hardware, all of 128, 256, and 512 KiB PROMs are approximately the same cost nowadays ($1 to $1.50), and there's no real disadvantage to filling as much as you have use for.

lidnariq wrote:The entire point of using RAM is that there isn't a real threshold for where the memory allocation becomes "unreasonable".

As a vague rule of thumb, I'd probably say "not more than half of the entire game data for CHR", but if you're planning on making hardware, all of 128, 256, and 512 KiB PROMs are approximately the same cost nowadays ($1 to $1.50), and there's no real disadvantage to filling as much as you have use for.

I'm aware of the point of RAM, I'm just not too sure about graphics space.
Not more than half? Okay, that's a good approximation. Thanks!

I'm still not sure about CHR files. YY-CHR saves 8KB CHR by default, but I'm not sure how to increase the size.

It's true it's 8KB by default, but if you create a file of a power of two size YY-CHR is usually able to edit it. The file that my YY-CHR program came with that is loaded by default is a 24 KB .CHR file.

If you'd like blank files of X size, I can post them.

Kasumi wrote:If you'd like blank files of X size, I can post them.

If you could, that would be very helpful!
I had 48KB, or 64KB in mind for CHR. Depending on how much room the sprites take up.

EDIT: Oh yeah, the 32KB file I have, is from the newer YY-CHR.NET. I opened it in the old version, ignored the language? errors, emptied the tiles, and saved out a blank file.

Level tiles are super-efficient as in Cat Quest. Though the sprites are fairly large. 24x32 on average. You know what? It's easier to post a picture. Here's a SFW mock-up of the larger project. It's an adult-oriented parody of a classic game.

Here's every power of 2 from 1KB to 256KB. Strange about errors. I'm using a super old version, though. So who knows what might have changed.

So Sir Ababol is a "classic" already? :p

One approach is to make huge monolithic CHR files, which is fine if you're coming from an NROM or CNROM mindset. Another approach that I have tended to use lately for CHR RAM mappers (NROM-256 modded for a 6264 in the CHR socket, AOROM, BNROM, and UNROM) is make a bunch of small (16 to 128 tile) PNG files that an image converter program converts to CHR files. My build process uses GNU Make to automatically call the converter again whenever the PNG files have changed. Then I can include each CHR file using .incbin and copy it to a given address in CHR ROM as it is needed, such as loading the sprites for the characters that both players have selected. Or I can even compress the CHR files and have the NES program decompress them when loading them. Tile compression slows down loading slightly, but it can help squeeze, say, a 144 to 160 KiB game into a 128 KiB chip.

If you plan to distribute your game on a standalone cartridge, it's OK to aim big, such as 4 Mbit (512 KiB) for UNROM, BNROM, or AOROM. That's how big Dragon Warrior 3, Dragon Warrior 4, Mega Man 4, and Mega Man 6 are, though they use somewhat more complicated mappers. Just be aware of two things. First, it takes more effort from your artists and level designers to fill more space; a small cart can help you limit the scope of your design to something manageable. Second, if you want to get your game included on the next community multicart, you'll have to justify the larger size of your game with suitably compelling gameplay.

Kasumi wrote:Here's every power of 2 from 1KB to 256KB. Strange about errors. I'm using a super old version, though. So who knows what might have changed.

Oh wow! Thank you! That's far more than I expected! These will be very helpful, for just about any future projects I would have in mind!

Well, It wasn't exactly an error, just a strange visual quirk I noticed. Must be referencing invalid string data, somewhere. Format difference between versions?

tepples wrote:So Sir Ababol is a "classic" already? :p

I gave the name a google, and found it on Nintendo Age. Wow! I'll have to give that game a try! It looks interesting! O_O
The game is direct a parody of Ghosts N' Goblins. I'd show off enemy sprites, but they're rather... inappropriate. Haha. The Raccoon Lady loses her armour from being hit, of course!

tepples wrote:One approach is to make huge monolithic CHR files, which is fine if you're coming from an NROM or CNROM mindset. Another approach that I have tended to use lately for CHR RAM mappers (NROM-256 modded for a 6264 in the CHR socket, AOROM, BNROM, and UNROM) is make a bunch of small (16 to 128 tile) PNG files that an image converter program converts to CHR files. My build process uses GNU Make to automatically call the converter again whenever the PNG files have changed. Then I can include each CHR file using .incbin and copy it to a given address in CHR ROM as it is needed, such as loading the sprites for the characters that both players have selected. Or I can even compress the CHR files and have the NES program decompress them when loading them. Tile compression slows down loading slightly, but it can help squeeze, say, a 144 to 160 KiB game into a 128 KiB chip.

If you plan to distribute your game on a standalone cartridge, it's OK to aim big, such as 4 Mbit (512 KiB) for UNROM, BNROM, or AOROM. That's how big Dragon Warrior 3, Dragon Warrior 4, Mega Man 4, and Mega Man 6 are, though they use somewhat more complicated mappers. Just be aware of two things. First, it takes more effort from your artists and level designers to fill more space; a small cart can help you limit the scope of your design to something manageable. Second, if you want to get your game included on the next community multicart, you'll have to justify the larger size of your game with suitably compelling gameplay.

Cat Quest is certainly small enough for inclusion on a community cart! I'm still learning 6502 right now, so it will likely be a while before I can even consider something like that. It's still a slow crawl.

As for this platformer? No, probably not. By "adult oriented" I mean it's a game of a pornographic nature. Certainly NOT suited to a community project!

Alp wrote:Well, It wasn't exactly an error, just a strange visual quirk I noticed. Must be referencing invalid string data, somewhere. Format difference between versions?

The interface of YY-CHR was originally in Japanese. It would appear that your copy's English translation is incomplete. The Japanese text appears as gibberish because the program does not use Unicode, and falls back on your computer's default non-Unicode text encoding.

(By the way, it says 通常表示 which means "normal display".)

Nameguy wrote:If you make copies of that house, won't they all have their own vanishing point?

Well, the vanishing of the house, was carefully measured to it's root position. (bottom, center)
Specifically, so I can do this, to make the world perspective *POP*.



The cliff tiles have only been measured, and are currently incomplete.
Hmm... I may use 4-screen mirroring for that game, make it look like LTTP, on the NES.

Here's a WIP title screen for that adult platformer. The castle itself is incomplete, as it is still a raw pencil sketch.

Alp wrote:I may use 4-screen mirroring for that game

Clean 8-way scrolling is possible even without extra name tables. It's just a little trickier to code.