nesdev.com

What all might I need to consider before embarking on attempting to port an old DOS game to the SNES (assuming I have the rights to do this)?

Here's all I can think of (having not learned much about SNES hardware yet):
-the DOS game's music is in mod format. It doesn't sound like it has more than say 4 voices going at once. I am aware there are various tools to both convert and play this type of music on the SNES.

-the graphics used mode 13h, which was 320x200. the SNES provides several modes including 256x240. How do I mock up how stretched or squashed the original game's graphics will look like on the SNES (on a CRT)? I can play the game on a Windows PC with square pixel aspect ratio. My impression is the SNES has 8:7 pixel aspect ratio, so the graphics, if not modified, will look slightly wider on the SNES than playing on a Windows PC with a square aspect ratio.

-cropping of the scrollable area, assuming no modification of original graphical assets, and whether this will affect gameplay.

-how many layers may be in use in the scrolling graphics. As far as I can tell, there are usually 2 layers of background graphics. I don't know anything about the SNES, but I assume the 256x240 mode can support 2 layers of bg graphics, with sprites able to go "between" them.

-performance. I'm not too concerned here, the game is pretty low-key action wise and in terms of how many sprites are on the screen---well within limits that I've read in the SNES specs.

-palette. as I understand it, I would not be able to have a flat 256 set of colors as in DOS. I would have to break it up into separate palettes for groups of bg objects and sprites. But, in sum total I would expect to be able to display the same number of colors if not more.

What else might I need to investigate?

Standard advice is to pixel double (without interpolation) the original 256x224 to 512x448, and then scale (with interpolation) to 585x448.

Note that Mode13h, 320x200, doesn't have square pixels either. (640x480 and 320x240 do.) The actual PAR for 320x200 is 5:6, so original game content would need to be scaled to 35/48 the original width for accurate DAR on the SNES.
The SNES supports anywhere from 1 to 4 background layers, depending on color depth per layer. q.v. wiki.superfamicom, fullsnes.

I wouldn't recommend 256x240; that's overscan mode. You won't see the top and bottom of the screen on a real TV. (No, a modern flatscreen is not a real TV.) Most developers used 256x224 for this reason.

Well, that and the fact that you get something like 70% more DMA bandwidth per frame, since each frame has only 262 scanlines total and you can't send data to VRAM while the screen is drawing...

Are you targeting the European, Australian, and New Zealand market or the Japanese, Brazilian, and North American markets? The PAL S-PPU has a ~1.3862:1 pixel aspect ratio* (no nice integer ratio), and the 239-line mode will produce smaller top and bottom borders than the 224-line mode.

And how large is the tile grid of the "original graphical assets", if any?

* The exact PAR of PAL per Rec. 601 is 2950000/2128137.

As for differences between regions, I'm less concerned there, I'd be happy if I got it ported to work on just north american SNES's and any equivalents in international regions.

By tile grid, do you mean whatever the SNES's equivalent is of CHR data on the NES? Or do you mean size of a scrollable map? I see "Backgrounds Up to 4 planes; each up to 1024 × 1024 pixels" in the SNES Wikipedia article. Surely there are games that scroll beyond this size, presumably by updating offscreen much like scrolling is done on the NES? I'm pretty sure the game I'm hoping to port has maps much larger than 1024x1024.

Tepples is talking about tile size, like how on the NES everything wants to be a multiple of at least 8x8, but often 16x16 or 32x32.
Framebuffer-like systems, such as the VGA's graphics modes, don't really have a constraint on what size tiles they use, including "no tiles at all", whereas things made for the SNES will be much more annoying if they're not a multiple of 8x8.

...right, PAL vs. NTSC. I think in NTSC, and I often forget PAL exists.

If you're developing for PAL natively (you aren't, but I'm speaking hypothetically), go for 239 high. It looks better, and DMA bandwidth is huge compared to NTSC so updating between frames isn't as much of a bottleneck.

I'm talking about the size of the metatile grid on which objects in a scrollable map are placed. For example, Super Mario Bros. uses a grid of 16x16 pixel spaces, Kirby Super Star uses 24x24, and Dr. Mario uses 8x8. Likewise, Chip's Challenge has an obvious grid, as do other PC games like Hocus Pocus, Commander Keen series, Syobon Action, I Wanna Be the Guy, and Warcraft. The grid in Jazz Jackrabbit is a bit more disguised, but it's there. There's even a grid in Starcraft, but it's hard to see outside the map editor. The metatile size on PC will determine part of the port's architecture.

I just went looking into this in my own project, since the top row of tiles is cut in half on my TV for some reason. I've verified that $2133 is set to zero, which should give 256x224. Am I missing something?

Different TVs are known to cut off different amounts of the picture. Because of certain low-level details of CRT operation, a CRT driven at 240p with short scanlines (341 instead of standard 341.25 dots per line) and short fields (262 instead of standard 262.5 dots per frame) may cut off more at the top than the bottom.

What the public has seen of official NES developer documentation (the "background planning sheets") recommends not putting anything important in the left or right 16 pixels or the top and bottom 24 pixels of NTSC. But the NES always runs in overscan mode, so in Super NES 224-line mode, that translates to 16 pixels from each side. But then this guideline is fairly conservative, equating to an 80% safe area. The 1970s TVs in use in the early Famicom days were not calibrated as precisely as the 1980s TVs used with the Super Famicom and Super NES, and video production standards switched to a 90% safe area sometime in the 1990s (source: BBC).

A practical safe area for TVs made in the 1980s and later is the area visible in the PocketNES emulator for the Game Boy Advance. In NES or Super NES overscan terms, this cuts 16 pixels from the top, 11 from the bottom, and 8 from the left and right side. In Super NES 224-line mode, it is equivalent to cutting 3 pixels from the bottom and 8 from the other three sides.

Best case, you'll be able to shrink 320x200 to around 240x200 and have things look mostly the same. There are tools to automate clean scaling of pixel art, such as my own Rotpixels that applies three passes of EPX followed by nearest neighbor resampling. But to evaluate the feasibility of that, I'll need to know the metatile size if it's a 2D game.

What I'm sincerely hoping is the game will look alright without modifying the graphics at all. If the scrollable area is cropped, so be it. If the sprites look a little fatter, so be it. Playing the game on my Windows PC, probably stretches the sprites out already from how they would have looked on an old CRT monitor in actual Mode 13h, as I'm pretty sure the pixel aspect ratio is 1:1 viewing the game on my PC. I think I'd only try to scale the graphics if it winds up looking really squat on the SNES, which I suppose is a possibility. I won't know til I try to convert that first sprite. I don't yet know the internals of the tile system of the PC game. I have the source but, til I finish my current project won't be able to truly dig in. Just trying to get a preliminary taste of what might be in store for me. Thanks all!

I agree. I find that squashing the screen looks terrible, and it can make porting a game more difficult as well. (adjusting the tile map, and resizing the graphics.) I really don't think losing 32 pixels on each side is that big of a loss, and for a lot of platform games where the character is always dead center in the middle of the screen, you can just adjust the camera to where it focusses a bit in front of the character. If you aren't sure what I mean, see what happens when you turn on Donkey Kong Country. (It's little things like this that make the Donkey Kong Country games very solid, in my opinion.)

All modern wide-screen monitors that I've seen give up on correctly rendering the PAR for the 320x200 (and 640x400, and 720x400) video modes. The original is nonetheless definitely a full-screen DAR of 4:3 on a 4:3 monitor, so the original PAR is unequivocally 5:6 for the first two (and 3:4 for the last one).

The big reason they've done this is that 320x200 (and 640x400) can be trivially scaled by an integer factor of 6 (3) on both axes to get 1920x1200. (720x400 isn't quite as clean, but it can be scaled by 2⅔ to get 1920x1067).

Or if you're playing in a window when using DOSbox or DOSemu or NTVDM, then necessarily you'll retain the square PAR of the host's mode.

Really, my only point is that the original graphics will be conspicuously squashed:

Cool, thanks for that. Yes, I think you're right, what I'm viewing on my windows PC is probably already fatter than how it may originally have looked. On the other hand, I left out the detail that this DOS game was developed far after DOS's heyday, and very well may have been developed on a windows machine with a PAR of 1:1. So perhaps the final SNES version will not be all that bad. I'll just have to see.

If you have the rights, perhaps you can ask the original author whether it was intended to be viewed in 4:3 DAR (5:6 PAR) or 8:5 DAR (1:1 PAR).