Video display controller with VGA output

[White Flame]

Some machines with larger numbers of sprites per line simply did it in the same way, having per-pixel decisions about multiple planes (including sprites) as to which to display. Others used a 1-line pixel buffer and painter's algorithmed the scanline's image onto it, often still in smaller paletted form, only expanding to full RGB when actually sending that buffer's pixels out to the display. I'm sure some combination of the two has been done as well.

Each has their own strengths and weaknesses. They'll both take the same amount of external memory bandwidth to pull in all the bits to render (thus it's advantageous NOT to have everything as 8- or 16-bit pixels in tile/sprite game display modes), but how and when things like alpha channels work, or complex priority bits might be easier in one or the other, depending on the specific design.

[Chromatix]

I suppose if you have an explicit line buffer, it's easier to double pixels vertically go to with a lower dot clock than VGA normally requires. That might also make things easier to implement, if you're satisfied with a QVGA pixel resolution for your games. As you note, the pixel resolution requirements are generally higher for productivity.

[JimDrew]

whartung wrote:

You can fill a pool with a drinking straw. I don't doubt you can move data to the chip. But as Gordon mentioned, drawing an 800 pixel line on a display, pixel by pixel, is expensive.

I agree, but nobody redraws every single pixel on the screen every frame in real-world applications. Not even video playpack software does that. There is plenty of speed to do most anything with a 1MHz 6502 (a 20MHz 65816 is even better). Most all of the various game machines of the era only had 320x240 graphics so I don't expect hires (640x480 or larger) games to be written for any '816 machine anyways. Besides, DOOM is 320x240 and that is all that seems to matter.

[DerTrueForce]

I wouldn't limit myself to 1MHz these days either. We have the technology to go faster.

[White Flame]

JimDrew wrote:

whartung wrote:

You can fill a pool with a drinking straw. I don't doubt you can move data to the chip. But as Gordon mentioned, drawing an 800 pixel line on a display, pixel by pixel, is expensive.

I agree, but nobody redraws every single pixel on the screen every frame in real-world applications. Not even video playpack software does that. There is plenty of speed to do most anything with a 1MHz 6502 (a 20MHz 65816 is even better). Most all of the various game machines of the era only had 320x240 graphics so I don't expect hires (640x480 or larger) games to be written for any '816 machine anyways. Besides, DOOM is 320x240 and that is all that seems to matter.

If you want to invoke the DOOM era, it certainly did redraw every single pixel on the screen every frame, at 320x200. (Maybe some of the border UI elements didn't, but they probably did due to mode13 paging, and that's still just a small fraction of the screen.) Pretty much every 3d game before 3d accelerators became a thing did a full clear & redraw of the visible framebuffer every frame, including those on 6502 home computers (with their requisite low frame rate). Some got away without the clear, if they provably cover the whole display every frame: DOOM did, which is why you get those graphics trails when you idspispopd out of bounds where there's no geometry. But that's still just "redraw every single pixel on the screen every frame" once instead of twice. Of course, PC hardware was unaccelerated plain framebuffers for the longest time, so the only thing you could do is redraw everything with the CPU, even for scrolling 2d games.

On the 6502, Elite, Driller, many flight simulators, many 3d driving games, etc, simply chugged along in the exact same way, CPU-pushing entire bitmap screens of pixels as fast as it can manage in single-digit (or less) frames per second.

Same with video playback, every pixel was software placed every frame (except for dirty rectangle compression in single-buffered displays, which is actually pretty rare), drawn into small windows or fullscreen low-resolution modes. The first major acceleration to video playback was hardware scaling onto a chromakey, but the CPU still had to draw a 320x240 or lower resolution video fully in software, pixel by pixel, for the GPU to stretch it. Of course, even later came actual hardware video format decoding, but that's well past the era we're talking about.

I've always compared tile/sprite chipsets as being hardware video decoders, with the video data being usefully editable directly in its compressed form. It's in my opinion the only reasonable way to have high quality, well-animated, colorful, fullscreen interactive graphics from 80s-to-early-90s class of hardware, as evidenced by arcade hardware & home game consoles of the time. The CPU can get away with doing very little in very dynamic game graphic scenarios, as long as that video chip is pumping quality from easily-editable display specs. I think the SNES had some of the best looking and playing 2d games of the era, yet its '816 had a very crippled clock speed between 2 and 3.5 MHz.

But even in the 6502 era we had 3d games, GUIs, productivity apps, visualizers, graphics shape editors, proportional fonts, etc, all of which still had to bite the bullet to move every pixel with the CPU, often with very large screen refreshes, sometimes the whole screen by necessity.

Increasing resolution has a quadratic increase in workload, compared to linear MHz of CPU work done, without a command-based GPU doing heavy bitmap processing for you (which I think wouldn't be very retro). However, that level of work is sometimes inevitable to do what you want on the machine, and can't be dismissed. Without such capabilities, either in useful fullscreen CPU pixel-pushing speed or only sticking with tile graphics, it could easily be seen as only a "games console" rather than a "home computer" in my opinion. (platforms predating that era of color home computer gaming would be held to a different standard)

[JimDrew]

White Flame wrote:

If you want to invoke the DOOM era, it certainly did redraw every single pixel on the screen every frame, at 320x200.

That's really not the case. I made a DOOM engine for the Amiga using the stock WAD files from the PC game. The data is refreshed as changes are made to the display, which does not mean updating every single pixel on the screen from frame to frame. I did some game engine programming for the C64 as well as the Amiga, and I worked on some video playback code as well. Video encoding uses changes from frame to frame, not new full screen refreshes for each frame. Sometimes (like during a scene switch) that does in fact force a full refresh of all of the pixel data, but general playback does not have all of the pixels being refreshed each frame. Same for games. Look at any C64 or Amiga game. You are not going to find a single game that refreshes the entire screen every frame. During the VB (vertical blank) period we would refresh character data and such, or may even toggle between screen buffers (double buffering) and then update large parts of the screen to prevent tearing when there is not enough time in the short VB period to update all of the display data.

I also wrote the first Intel Pentium emulation (1.6 million lines of 68K assembly code), and I did full video card emulation including all video modes like the infamous MODE13. I got to see first hand internally how the data was written to the display and I was able to optimize the video emulation by looking at programs like DOOM, Castle Wolfenstein 3D, etc.

The CPU horsepower is very limited with 8 bit systems and I agree that large resolutions require a LOT of data to be pushed. 8 bit systems, whether they are 6502, 65816, Z80, etc. are all limited on bandwidth. Short of a high-speed dedicated graphics co-processor (GPU), there is not much we can do about the issue. One thing that this limitation did do though is increase the creativity of the games. It's funny because we have these 4K first person shooting games that look amazing, but really suck for game play. My son and his college buddies are now opting for games like Tower Fall Ascention on the PS4. It is an old school 320x240 8 bit color game. It and other low-res/low-color games are making a huge come back because they are simply fun to play. So, other than making a terminal program, word processor, or something else with no real graphics data, I would not attempt anything with a screen resolution larger than 320x240 on an 8 bit machine without a GPU. That's my 2 cents.

[White Flame]

JimDrew wrote:

That's really not the case. I made a DOOM engine for the Amiga using the stock WAD files from the PC game. The data is refreshed as changes are made to the display, which does not mean updating every single pixel on the screen from frame to frame.

Could you be more specific about where this was done? If the player moves or turns, the entire screen needs to be drawn, since the viewpoint is different. There were animated lights, as well as explosions/gunfire which changed the lighting, which would require a full refresh from within a room. Walls and floors had animated textures. Drawing the moving enemies and projectiles happens inside the BSP traversal rendering for occlusion. There's very few places & times in the game where parts of the the screen would legitimately be static, and those are points where frame rates wouldn't really matter; running & gunning matters for framerates, and delta updates can't be done there. John Carmack didn't use it, and he's pretty obsessive about finding performance advantages.

Quote:

Video encoding uses changes from frame to frame, not new full screen refreshes for each frame. Sometimes (like during a scene switch) that does in fact force a full refresh of all of the pixel data, but general playback does not have all of the pixels being refreshed each frame.

Well, that's getting into a bit of a technicality. Video codecs use compressed numeric pixel deltas in P and B style frames, such that it's a read-modify-write adjustment to the prior frame's pixels, which is even more costly in terms of the count of framebuffer memory operations than write-only I-frames. If you're lucky there can be completely unchanged blocks from one frame to the next, but especially with moving camera angles or real-world moving backgrounds many videos touch all pixels in delta frames as well. The CPU was in charge of all the individual pixels in the video output, requiring the ability to do full updates while retaining full frame rate, with nothing magic going on until accelerators came about. It couldn't rely on only X% of the screen being updated to keep up, because the 100% update case was common.

Quote:

Look at any C64 or Amiga game. You are not going to find a single game that refreshes the entire screen every frame. During the VB (vertical blank) period we would refresh character data and such, or may even toggle between screen buffers (double buffering) and then update large parts of the screen to prevent tearing when there is not enough time in the short VB period to update all of the display data.

As I said, pick any flight or space sim. Chuck Yeager's, F-19 Stealth Fighter, Elite, & Echelon were some of the ones I played as a kid on the C64. Full bitmap mode pixel updates per frame. Amiga had plenty as well. Some cropped the screen down for performance reasons, but the same concept applied: fully redrawing the visible bitmap data.

But outside of bitmap mode, the C64 is fast enough to redraw the entire character screen at full frame rate, if you keep the color RAM constant, and letterboxing for the score area lessens the workload as well. Some games did that for code simplicity, or to support high-speed scrolling (>=1 char per frame), or to do fast pseudo-3d made from characters. Of course, character mode is the common case for most games, but I brought up the others simply to show that those full-update techniques were done back then, and is effectively a requirement for certain styles of games that don't fit neatly into a tile mechanism. It also kind of sets a baseline of expectation of performance for such platforms in those scenarios.

Quote:

That's my 2 cents.

Sure, I'm just pointing out that "no game updated everything every frame" simply wasn't true, even in very early years. Many of us were digging into code to see how the cool things were done behind the scenes, and replicating them ourselves. But regarding modern reiterations, the things that the systems struggled to do back then should be better supported, without overstepping the bounds of retro style & enjoyment. That does involve reasonable timeliness in redrawing the screen, bitmap mode or otherwise.

[BigEd]

You mention Elite: did that not draw and overdraw lines? I wouldn't have thought it paints the whole screen. Likewise I'd expect Revs was careful only to draw changing edges.

For a contemporary game, on Acorn's 6502 systems, see these two recent examples, both of which link to technical threads about implementation:

• Stunt Car Racer for BBC Master
  New game for the BBC Master : Planet Nubium

[Chromatix]

Yes, Elite's wireframe graphics were definitely a performance optimisation. Bresenham lines are relatively easy to draw quickly, compared to filling the scanlines of a triangle. The ship models were also very carefully designed so that certain mathematical properties could be exploited while transforming their vertices and removing hidden lines (lots of symmetry, and strictly convex hulls). Elite: Dangerous' models follow the same general forms but are much more detailed, and no longer strictly convex as a result.

If you were to run Elite on a 4x faster CPU with a screen resolution doubled each way, it would actually run more than twice as fast; the work of line drawing depends on linear dimension rather than area, and the geometry transform workload wouldn't be increased.

[JimDrew]

I spent 20 years of my life (permanent day job) writing software and designing hardware for the Commodore line of computers. Games didn't redraw the same data over and over again at 50/60Hz. That is myth that I had never even heard of before until this thread. There is a video buffer that is pointed to for the video hardware and video data is refreshed automatically using that. When you change the buffer contents, the display changes. In DOOM when stationary, there is nothing being pushed to the video card. Only when changes occur with the video display is there actual data being moved. If you shift left or right in DOOM, the screen shifts left or right and the entire display is moved in 1 frame period. You don't need to keep updating the video buffer for another 59 frames (for 60 fps) because the data is already. For the Amiga port I improved upon this by using a "compare page" to compare changes that were pushed to the video buffer (in FAST RAM instead of on a bus), and only updated actual pixels that were changed to the actual video buffer. If you shift black and it's already black there is no reason to re-draw the black. I took it a step further and used the MMU (when available) to map 4K pages and created "damage regions" that could be checked for any change within a 4K page.

[whartung]

JimDrew wrote:

In DOOM when stationary, there is nothing being pushed to the video card. Only when changes occur with the video display is there actual data being moved. If you shift left or right in DOOM, the screen shifts left or right and the entire display is moved in 1 frame period.

Nobody was suggesting that the frames were being needlessly redrawn. Nobody is suggesting that they're repainting the bottom score part of the display needlessly either.

The assertion was that when the play field changed, notably in DOOM, the entire play field changed. This isn't Pacman with 4 blinking dots and 5 characters running around a static map. If I'm in DOOM, and start turning, then, yes, it's going to repaint the entirety of the play field part as fast as it can.

I don't know if DOOM treated monsters as 2D sprites, scaled and clipped to virtual geometry, or as a sprite in 3D space and rendered along with the rest of the scene. Similarly with gun shots and what not. (I do know that they were just 2D pixmaps, not "models". Just cardboard monsters pre-rendered at different angles.)

You can certainly potentially optimize the repaints if the camera is stable, and just update the monsters and gun shots against a static background (with clipping shenanigans as appropriate). But, in something like DOOM, a twitch of the mouse or keyboard is going to purge the entire frame anyway. Folks run around a lot, and when static, there's not a lot of motivation for better FPS anyway. Does it really matter if moving a single monster can be rendered at twice or better the FPS than an entire refresh?

DOOM is a run and gun game, moving the camera is the norm, not the exception, and where the play experience is most noticeable in terms of game lag and what not. Make that fast and who cares about the rest.

A weak CPU is going to have enough trouble keeping the frames painted in time, much trying to do any differential analysis.

Quote:

DOOM(TM) requires an IBM compatible 386 or better with 4 megs of
RAM, a VGA graphics card, and a hard disk drive. A 486 or
better, a Sound Blaster Pro(TM) or 100% compatible sound card
is recommended.

I used to play it on a 25Mhz 486SX laptop with no problem at all.

[JimDrew]

The source code for DOOM is readily available. You can look at exactly how the pixel map is converted and push to the video hardware.

[BigEd]

I wonder if this is a good point to stop this line of thought. While it's incredibly interesting to hear from someone who has actually written the software, it's painful to see a series of shifting claims and challenges from someone who has not. I wouldn't want the good natured and informative discussion to result in frustration and anger.

[mojo]

I actually worked on an Amiga port of Doom. It constantly redraws the entire screen, even when the player is not moving, as fast as possible. There are no partial updates, except for the status bar area at the bottom of the screen. The entire 3D scene is being constantly refreshed.

One idea to speed it up for the Amiga port was actually to just update the changed bits, because memory bandwidth is limited and you have to do a chunky to planar conversion too. But it was quickly abandoned because when moving every frame is 100% different so there is no benefit.

Not redrawing the whole screen is more relevant to games that use flat shading, like a lot of early flight sims and racing games. If I made a GPU I'd like to have some accelerated horizontal line drawing capability just for classic 3D games.

[BigEd]

My recollection of those early games is that the FPS were low, maybe as low as 10. The games were spectacular or good fun, or both, so that was fine.

The modern remakes and ports and new games as seen discussed on stardot often aim for 25FPS, I think. That's rather demanding. (Edit: For example Scramble (technical development thread) does run at 50fps.)