next »

[J-Snake]

One thing to keep in mind is that snes games on crt screens have a significantly smoother look to them than on emulators today. I personally have never been a fan pixelated visuals. I am using "smoothed out" Super Metroid Sprites for a game in 1366*768 (the resolution many notebooks have) and it feels just right, probably the way the snes was supposed to look.

[Gregg Williams]

Yeah I did most of my console gaming on less than 25" TVs as well, things tended to be not giant pixels. (Atleast in 8/16bit era) Same with arcade monitors which were mostly under 25"

[Schoq]

There's really no excuse to not include some video options for how and if to stretch the image. It feels incredibly lazy when a game doesn't.

[Richard Kain]

There's really no excuse to not include some video options for how and if to stretch the image. It feels incredibly lazy when a game doesn't.

This isn't always feasible with the engine being used. Also, giving greater control to the player over how the game is displayed can effect the design of the game. Some types of games don't lend themselves well to re-sizing. This is especially true of lower-resolution pixel games, which are often based on exact sprite dimensions.

Speaking of sprite dimensions, I did a few more calculations and have a different recommendation.

384 x 208 (for fullscreen)
288 x 208 (for fullscreen stretched)

My previous recommendation allowed for some overlap and cropping on the rendering. The scaled versions wouldn't both fit on screen for a 720p display and a 1080p display. This new recommendation allows for x3 and x5 scaling to both fit on those displays with minimal waste. This recommendation assumes a widescreen aspect ratio.

For the 8 and 16 bit "styles" it's important to take sprite dimensions into account. The basic rule is that your dimensions need to divide evenly into 16. 16 x 16 was the standard sprite size for most retro games from that era.

[Richard Kain]

Yeeeesh, I've been terrible at these calculations. I just realized my most recent attempt was based on a 3:2 standard definition aspect ratio, but the actual standard for most TVs was a 4:3 aspect ratio. Back to the drawing board. I've been having a bit of fun with this challenge though. In the next week or so I will post a tutorial on how to achieve this effect in Unity.

[crowe]

Allow me to begin my thesis by explaining that I feel aspect ratios and resolution should be withheld from the player's control, as they may compromise the vision of the auteur (or author, for you plebeian readers) which is above-all the utmost in import. Please disregard questions of whether most monitors will handle a given resolution, as this is irrelevant!

[Schoq]

For the 8 and 16 bit "styles" it's important to take sprite dimensions into account. The basic rule is that your dimensions need to divide evenly into 16. 16 x 16 was the standard sprite size for most retro games from that era.

Disregard this because it's false.

The smallest is 8, and 16 is far from standard. And as a quick inspection of some SNES screenshots show, most "sprites" are composed of a cluster of smaller hardware sprites in such a way that they do not end up forming images with dimensions divisible by 16. Divisible by 8 becomes a bit more true but even that is a loose rule of thumb at best.


And I have no idea what you mean by

Some types of games don't lend themselves well to re-sizing. This is especially true of lower-resolution pixel games, which are often based on exact sprite dimensions.

What does resizing matter as long as the dimensions of everything on screen stay proportional? Sounds stupid as heck.

[Richard Kain]

What does resizing matter as long as the dimensions of everything on screen stay proportional? Sounds stupid as heck.

How many sprites wide is the screen in The Legend of Zelda? How many sprites wide is the standard map screen in Super Mario Bros. 3? How many sprites wide is the playfield in Bomberman? Bubble Bobble? Gyromite?

While quite a few classic games feature extensive scrolling, there are quite a few that rely on grids for their general structure. That grid-based focus for constructing levels and environment was a crucial part of the "style" from that era.

It is true that there were often some sprites that were 8x8, and even some that were 8x16, or 16x32. And yes, some characters were made up of collections of multiple sprites. But quite a few games relied on that 16x16 standard for level construction. And that is far more important to screen resolution. (since levels and rooms often took up the entire screen) If you changed the resolution on a game like The Legend of Zelda, you would have to change the structure of the rooms to compensate. And the structure and layout of the rooms was a huge part of the content.

For some games, altering the resolution or aspect ratio is a minor consideration, and relative spacing for GUI and HUD elements can easily compensate. But for games that rely on a specific resolution for their environmental structure, such flexibility is not possible. That's why it is useful when emulating that style to have a specific resolution to target that can be scaled effectively.

A big part of this whole discussion is the shift from CRT to fixed resolution displays as the primary means of displaying games. CRTs were multiple-resolution technology. No matter what resolution signal you fed into them, they would display it full-screen. And because of the nature of the technology, they were able to handle this re-sizing quite capably.

That flat panels that have become the norm are all fixed-resolution displays. This type of technology is much worse when it comes to re-sizing lower-resolution signals. It's part of the reason why older systems usually look like garbage when attached to a modern television. When shooting for a lower-resolution game, it is necessary to consider these sorts of factors.

[Schoq]

I'm only talking about stretching the image, not resizing any elements individually or increasing the view. No idea why you would think something else.

Background metatiles were very often 16*16 yeah, still doesn't apply to sprites at all. You're still way off with "8x8, and even 8x16, or 16x32". The apparent metasprite dimensions in a SNES game can be basically anything you want.
It's good to keep hardware sprite sizes in mind and imagine you're trying to make good use of them, as style advice. But "your dimensions need to divide evenly into 16" is just nonsense.

[Richard Kain]

It's good to keep hardware sprite sizes in mind and imagine you're trying to make good use of them, as style advice. But "your dimensions need to divide evenly into 16" is just nonsense.

I would say more "want" than "need." This is a stylistic approach from the get-go, nothing about it is a hard requirement.

And stretching the final rendering is what's really important, as far as the hardware is concerned. As far as re-sizing the final rendering is concerned, that is definitely the crucial element for initial lower-resolution styles. Stretching the "image" improperly will lead to undesirable distortion, thanks to it being displayed on fixed-resolution screens.

And unfortunately, that's where most of the problems arise. The 720p and 1080p resolutions don't line up perfectly. They have the same aspect ratio, but there is no way to map them identically with integer scaling. And integer scaling is the best way to maintain a low-resolution chunky pixel look without distortion on fixed resolution displays. Just taking the final render and scaling it up isn't enough.

[Schoq]

Oh, me from the past wants to chime in with a good suggestion regarding that!

One thing you can do is draw an image upscaled with nearest neighbour to a surface and then bilinear stretch that image to the screen resolution, resulting in something like this, which I think is a nice compromise.
Either way it's always good to have multiple display options for different preferences.

[Richard Kain]

One thing you can do is draw an image upscaled with nearest neighbour to a surface and then bilinear stretch that image to the screen resolution, resulting in something like this, which I think is a nice compromise.

That IS a pretty good compromise. Of course, for my own projects I'm using Unity Free. And Unity Free doesn't have the draw-to-texture feature. It hampers post-processing scaling somewhat. Nearest neighbor and bilinear stretching aren't an option for me.

I can still pull off some of this, there is plenty of utility in the Camera class. But I just don't have the level of granular control that you are describing.

[Gregg Williams]

Oh, me from the past wants to chime in with a good suggestion regarding that!

One thing you can do is draw an image upscaled with nearest neighbour to a surface and then bilinear stretch that image to the screen resolution, resulting in something like this, which I think is a nice compromise.
Either way it's always good to have multiple display options for different preferences.

Ungh, any filtering of pixel art, is pretty much against the whole point of pixel art in the first place ;/

Nearest neighbor scale, and then if you have to letter/pillar box.

[Richard Kain]

In Unity, the secret to maintaining proper pixel scaling is to carefully balance the rendered viewport of your camera, the orthographic scaling value of your camera, and the specified pixel density of your sprites.

The new Sprite class in Unity offers the user the option of determining how many pixels are in a single Unity unit. (Unity units are displayed as the default grid you see in the editor, one square equals one unit) Whatever you specify for this value will determine the pixel density of your individual sprites. This is determined on a texture basis. Different textures can have different pixel densities. Whatever pixel density you are using most frequently should probably be considered your "standard" density. I normally use 16 for my standard density, but you can also use 4, 8, 32, 64, whatever suits your needs. You can also use non-power-of-two values, but I just like sticking to those. Not a requirement, but I've been working with computers so long that its just a personal habit.

The scaling value of your orthographic camera is half the height of your camera in Unity units. I like to think of it as the orthographic camera's "radius." When viewing your orthographic camera from behind in the standard position, it is the distance from the camera icon to the top of the camera's limits. Increase that value and the distance increases. If you want your dimensions to match a specific grid, you should set this value so that when it is multiplied by two, it divides evenly by your standard sprite density.

(Camera orthographic scale * 2) % Standard sprite density = 0

This step is only necessary if you want that exact grid, it is not needed if exact pixel scaling is all you desire. For exact pixel scaling, all you need to do is this.

(Camera orthographic scale * 2) * Standard sprite density = Any integer value

As long as this calculation evaluates to an integer value, you're good to go for exact pixel rendering.

The final step is to adjust the camera's viewport rectangle based on the exact pixel dimensions of the Screen you're rendering to. This is where a lot of the personal preference and scaling happens. It's also where you would add options for the user to adjust the scaling based on their own preferences.

[Richard Kain]

Okay, here's a revised recommendation based on Schoq's feedback about not slavishly adhering to exact sprite grid consistency.

320px x 180px

While this resolution isn't quite on-target for classic retro consoles, the increased width makes for a pixel density that is very close to the same pixel density of the NES and SNES. And this pixel density scales perfectly up to 720p and 1080p at a factor of 4 and 6. Using this resolution will allow you to make a retro-styled game that can be re-sized for both standard HD resolutions with exact integer scaling and no loss of screen real-estate.

And for those grid-purists like myself, you would have the option of using either 10x10 or 20x20 sprites. Both of those divide evenly into both proportions, giving the user plenty of flexibility.

[Polly]

And for those grid-purists like myself, you would have the option of using either 10x10 or 20x20 sprites.

The screen resolution doesn't have anything to do with the internal tile-size. Stick to ( a multitude of ) 8x8 regardless.

The only system from that era that isn't bound to ( a multitude of ) 8x8 tiles is the ATARI Lynx ( with its frame-buffer based architecture and oddball resolution of 160x102 ), but a significant chunk of 2D games still use a tile-size that is a power-of-two due to the CPU related performance benefits.

[Richard Kain]

The screen resolution doesn't have anything to do with the internal tile-size. Stick to ( a multitude of ) 8x8 regardless.

The only system from that era that isn't bound to ( a multitude of ) 8x8 tiles is the ATARI Lynx ( with its frame-buffer based architecture and oddball resolution of 160x102 ), but a significant chunk of 2D games still use a tile-size that is a power-of-two due to the CPU related performance benefits.

I've gone over this already. Some games use a strict grid by design. I also already pointed out that this is a matter of style and design, not a limitation. It's a guideline, not a rule.

And in this modern age, with the kind of technology and game engines that we have at our disposal, restricting ourselves to power-of-two isn't necessary. Whatever benefits you would glean from this are minimal. I only mention it as an example of how things were commonly done on those older systems. Restricting yourself to those standards is a personal choice in pursuit of the style in question.

I would still recommend the resolution I mentioned. 320 x 180 is a good place to start from, no matter what standard tile-size you settle on.

[Polly]

I've gone over this already. Some games use a strict grid by design. I also already pointed out that this is a matter of style and design, not a limitation. It's a guideline, not a rule.

The SNES only supports tiles that are 8x8 pixels. It's not a guideline, it's a hardware limitation.

[Richard Kain]

The SNES only supports tiles that are 8x8 pixels. It's not a guideline, it's a hardware limitation.

But I'm not developing games for the SNES, and neither are most of the people reading this thread. Thanks to the hobbyist scene, it is possible to develop games for the SNES if you were so inclined. But the thrust of this thread is in emulating a style, not the strict hardware limitations. Your suggestions are useful for anyone looking to ape the restrictions of the SNES. But most modern developers aren't looking to shackle themselves too firmly to those limitations.

[Polly]

You're entitled to your opinion of course .. it just baffles me that you would want to ignore a aspect that's so intrinsic to the SNES "feel".

But the thrust of this thread is in emulating a style, not the strict hardware limitations.

The style is a product of the hardware though.