8

I'm used to the idea that the maximum resolution there was any point in trying to generate on NTSC TV sets was about 320x224 (or 240 as a compromise figure between NTSC and PAL), but according to Wikipedia the original PlayStation was designed to go up to 640x480.

But that machine only had one megabyte of video RAM. Even if you dial the color depth down to 16 bits, a single frame buffer would take 600K, and for 3D gaming you need two buffers, which would exceed the total video RAM even before trying to reserve any for textures or whatever.

Did any PS1 games use such a high resolution? If so, how did they do it?

Improve this question
  • 1
    Ridge Racer Hi-Spec demo (Turbo Mode outside of Japan) might be work looking into. I can't immediately get a straight answer of what res it ran at but it was higher than normal, plus higher frame rate. Impressive really. – user19862 Jan 13 at 10:50
  • 1
    You'd be surprised with you can do with 640x480x8 bit color depth if you plan in advance. I've got this Zoo CD; you wouldn't know by looking that everything is 8 bit color to keep the PC drivers of the era happy. – Joshua Jan 13 at 23:06
  • 1
    .... you accepted an answer that neither says no nor lists any games. – Mazura Jan 14 at 1:43
  • 1
    The title screen/main menu for Space Invaders on PSX uses 640x480. I originally wanted to use 480i for the entirety of the game, but unfortunately only we didn't have enough time to optimize the rendering to maintain 60fps, and drop down to 240p for in-game play. mobygames.com/game/playstation/space-invaders/screenshots – falken Jan 14 at 9:46
  • @Mazura While I am still interested in examples of games, the accepted answer explains how it is possible, which is valuable. – rwallace Jan 14 at 17:37
18

You don’t need two buffers at 640x480 because television is interlaced — each field is only 640x240; if you can render at 60Hz then you can always draw the next field while the current is being output and therefore maintain proper even/odd sampling positions for a genuine interlaced signal. This is even a better solution than a 640x480 buffer because it recognises that fields are distinct things drawn at distinct times, not halves of some hypothetical ‘full image’.

I’ve personally written Yaroze software that ran in full 3d at 640x480 and it’s a common title-screen resolution; Tobal #1 springs to mind as an example of a commercial title which runs at that resolution.

And as an aside: it is not true that two buffers are a requirement for 3d gaming; if your scene were simple enough that you could draw in the time between the final visible line of one frame and the first of the next then a second buffer would be unnecessary.

While there is no definitive (short) list of the commercial PS1 releases that included game play running at 480i resolution, some enthusiasts have created an informal list of 480i games.

Improve this answer
  • 4
    The last point is a really important one that I see a lot of newer developers working on live 3D rendering fail to understand. Double-buffering is only ‘needed’ due to the amount of time it takes to render a scene being longer than the inter-frame delay on modern hardware, and it’s becoming increasingly rare that a developer actually works on something where that is not the case. – Austin Hemmelgarn Jan 13 at 15:19
  • 2
    It also struck me that if you had a vertical split-screen game then you wouldn't need to lose anything in the way of graphical fidelity to run with a single buffer, as you've basically got two buffers built into your one — the one on top and the one below. As soon as the raster enters the one below you can start repainting the one on top and vice versa, for no GPU downtime. It's a special case versus full-frame rendering of 3d graphics because because you have two buckets for rendering that attach exactly to two continuous raster areas. Don't know any such titles though. – Tommy Jan 13 at 15:58
  • 1
    And it's super primitive 3d by Playstation standards, but here's my little 640x480@60Hz demo: YouTube GitHub. Apologies for not being able to dig out a good YouTube sample — 99.99% videos don't indicate whether they were captured on real hardware or via a potentially-upscaling emulator, but with my own tiny tinkering I know for certain that it's from real hardware. And the GitHub repository is the proof of 640x480. – Tommy Jan 13 at 16:25
  • 1
    @Tommy: Such a principle can be applied even if there isn't a visible "seam" between the two halves. The arcade game Defender did this. I don't know exactly what scan lines it used, but if e.g. one had interrupts on lines 0 and 128, and no object is more than 16 pixels tall, it would be able to achieve smooth animation if the line-128 interrupt draws all objects whose top was above (lower numbered than) line 112, and the line 0 interrupt draws all objects whose top is on line 112 or below (higher numbers), finishing before line 112, and then computes object positions for the next frame. – supercat Jan 13 at 20:17
  • 1
    @eps "Racing the beam" refers to writing code that's tightly synchronized to the display refresh, such that you're determining what to output just as it's needed. For example, the Atari 2600 (the original example) didn't have a framebuffer, so you'd perform your calculations during the blanking intervals and then more or less bit-bang the video output the rest of the time. Super Nintendo racing games would also race the beam, changing the Mode 7 transformation matrix between each scanline to make a ground texture appear to curve. See also "Raster Interrupt". – ssokolow Jan 14 at 12:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.