#NATIVE GAME RESLUTIONS FULL#
#NATIVE GAME RESLUTIONS PC#

You’re basically using your GPU’s graphical power to render images at a much higher resolution than your eyes can see on the screen, causing various subtle but pleasing enhancements to the way polygonal edges and lighting effects appear. The benefit is that you “see” graphics at a much higher level of detail, avoiding some basic pitfalls like aliased polygon edges and lighting artifacts.

Various software-only solutions for this have been around for awhile, but now video cards are powerful enough to brute force the technique onto games that don’t natively support it. It’s called “supersampling,” among other names, and the basic gist is that the game renders its graphics at a resolution above what the monitor can display…then scale it down to your monitor’s native resolution.

#NATIVE GAME RESLUTIONS PC#

Now that PC game developers have become experts at getting their games to run at 60 frames per second even on middling hardware, and even under-$200 graphics cards are getting ridiculously powerful and efficient, a new technique to make games look better has emerged. One issue with this, console games that switch resolutions on the fly (Seiken Densentsu 3 / the unreleased Secret of Mana 3?) can not take advantage of this.What’s the ideal resolution for a PC game? Ask most players and they’ll immediately answer, “Whatever your monitor can support.” That’s the obvious solution-after all, it would hardly make sense to render graphics at higher than your equipment can actually output and your eyes can see, right? …Right? A Quick Primer on Supersampling It will be implemented in my standalone minimalist MAME image that can be found here.

This is the basis of my video mode switching algorithm for emulation going forward. What we do in these cases is to reduce the front and back porch portion of the video signal and use that to get the addition line count. Games that go over 240 lines break the rules somewhat (see my video generation tutorial here) and will likely have problems being displayed on anything but adjustable arcade monitors. It can almost be ignored except for a few games that display at 248 and 256 lines like Irem’s R-Type and Midway’s Mortal Kombat and other games. Vertical line count is less of a problem. This works out quite well with most games displaying properly and fitting nicely to the available horizontal screen real estate.

For horizontal resolutions 288 and 384 pixels, we use 9.6Mhz.

The raspberry Pi has 3 low frequency pixel clocks 4.8MHz, 6.8Mhz and 9.6Mhz. What we need to do is come up with a scheme to display most of these games at native resolution. This is expected, due to the limitations of an arcade monitor. We also have a large quantity of games at 336 and 384 which will not display correctly at 320×240 unless rescaled, which we are trying to avoid.įor vertical resolution or line count, we have most games displaying either 224 or 240 lines. We have popular horizontal resolutions of 256 and 288 and 320. It just means that the screen size may be reduced.

Most games will run in a resolution of 320×240 without scaling. So, there are some things that are worth noting. Popular Horizontal Arcade Video Modes Number of Games Here’s the list: Popular Horizontal Arcade Video Modes Number of Games This came from MAME’s game info xml dump. I started looking at the most commonly used resolution in arcade games.

#NATIVE GAME RESLUTIONS FULL#

Now, there are emulators that already do this, but I wanted to be able to possibly use emulators that don’t, and have full control of the process. So the idea here is that the video output would be set to the exact resolution of the game, before emulation is started. This was in preparation for getting my standalone MAME image for the PJ adapter. I did a bit of experimenting with setting different resolutions on the raspberry Pi for arcade emulation.

Native game reslutions