OS words of wisdom

[Korona]

Yes, they 100% absolutely used VBE. Look at more or less any game for DOS released after about 1994. Quake being one excellent and popular example. Page flipping is possible using VBE, but uncommon. Hardware sprites have never been a feature of any popular PC graphics card.

A few games had specific drivers for certain graphics cards (there were even a few that could use 3D acceleration in DOS; mostly 3dfx Voodoo), but this was not the norm and even when they did, they virtually always had a generic VBE driver which quickly became the de-facto default. For graphics cards that did not have (good) VBE support, users were expected to use SciTech's "UniVBE"/"Display Doctor" products, which were just DOS TSRs that had their own VBE implementations for a multitude of common and uncommon graphics cards.

I was was more referring to older DOS games (late 80s to early 90s, e.g., Commander Keen). I had the impression that some EGA/VGA and many cards marketed as SVGA had hardware sprites. But I only dealt with a limited amounts of such cards and hence this impression might be wrong.

So, do those VBE-based DOS games do VBE page flipping? How do they avoid the latency of writes to the ISA/PCI bus?

Not sure where you get the idea that using "VGA directly" will get you anything beyond 8-bit colour or access to anything beyond 256KB of VRAM... The only ways to exceed those specifications are to write particular drivers for specific cards/families or use VBE or GOP.

I was not implying that this is possible at all. Hence I wrote "low color depth at high resolutions or high color depth at low resolutions". Anything sophisticated compared to today's standards just doesn't fit into the 256KiB.

[bzt]

Not sure where you get the idea that using "VGA directly" will get you anything beyond 8-bit colour or access to anything beyond 256KB of VRAM

Anything sophisticated compared to today's standards just doesn't fit into the 256KiB.

VGA cards were not limited to 8-bit or 256KiB. I still have a card somewhere in the attic with 512KiB. It's a Realtek or Trident if I remember correctly. The problem was all manufacturers had their own standards, actually this lead to VESA (VGA cards supported SVGA modes years before VESA). RBIL still has tables of pre-VESA era for Video BIOS.

So, do those VBE-based DOS games do VBE page flipping? How do they avoid the latency of writes to the ISA/PCI bus?

Some cards supported double buffering. With EGA you can select whether to display B0000 or B8000 on screen in a standard way, unfortunately on VGA cards this wasn't standardized, but most card supported a switch between A0000 and B0000.

Old games did not care about the bus latency either, because the main issue was back then bank switching. This is a procedure selecting which 64KiB you want to access at A0000-AFFFF from the total VGA RAM. Using VBE BIOS int 10 for that is terribly slow. Therefore VESA were mostly used in strategic and adventure games where big FPS was not a requirement. See Settlers II, Little Big Adventure from the 90's etc. Many games have also included "drivers" for the popular cards, these were just a bank switch functions really, not real drivers. Back in the days I've reverse engineered many of those routines, they used different VGA registers. I remember my favourite was Realtek VGA card as it only needed a simple "outb SPECVGAPORT, banknum".
This limitation was overcome by the introduction of the Linear Frame Buffer, where the whole screen area (not just 64k) was mapped at a different location than A0000, hence rendering bank switching unnecessary.

Cheers,
bzt

[Sik]

As far as I'm aware the only case of hardware sprite that was ever widespread on PC was a single sprite for use as the mouse cursor (and every card had its own way to do it), and I don't think that's even used anymore.

Since Commander Keen was mentioned: nope, EGA didn't have hardware sprites (the game used dirty rectangles, i.e. restoring only the parts of the background that got overwritten). What EGA did have (and VGA inherited) was hardware scrolling, although this was rarely exploited. Commander Keen was well known for actually making use of this stuff to get smooth full screen scrolling. I also remember using a S3 card that seemed to have implemented the scrolling in a slightly broken way because it'd jump back and forth every 4px in Commander Keen as if it was dropping a bit from the X offset (it didn't render the game unplayable but it definitely made it annoying).

There were lots of weird things going on actually (like scrolling and split screen being functional even in text mode, or all the weird bit operations that could be done when writing to the bitplanes), but don't expect to see any of that in modern setups, where you're expected to draw a bunch of triangles using the GPU cores (although admittedly, for a 2D GUI you can get reasonable results with CPU rendering… just make sure to keep your work framebuffer in RAM and only blit the final result to VRAM, since the bus when writing to VRAM is slow).

[kzinti]

I worked for a graphics video card vendor at the time. Sprites were not common on hardware and very limited. As Sik mentions, they were used for the mouse cursor in Windows (3.0 / 3.1) and that's about it. Typically they would be very small and only support monochrome black/white.

[Korona]

I see. I guess I messed up hardware scrolling and hardware sprites. Thanks for the clarification.

[zaval]

funny, I was just reading Allwinner A20 and R40 SoC manuals and stumbled across these sprite things. there is such a block, called DEBE (Display Engine Back End of course, you've already guessed, there is also DEFE - Display Engine Front End, this is in addition to TCON - LCD/LVDS controller, HDMI and TV encoder/decoder) it does have these thingies:

- Hardware cursor support
32x32 @8bpp
64x64 @2bpp
64x32 @4bpp
32x64 @4bpp
- Sprite function support
32bpp true color or 8bpp palette mode
up to 32 independent sprite blocks
each block can be set arbitrary coordinate
adjustable block size

I am wondering, why, as some of you say, they are "rarely used"? Aren't they a worthful feature? Looks kinda cool. Too bad, Allwinner only lists features and registers in their manuals, no "guides", "notes" and other so helpful goodies. I have no idea how dafuq to make use of these things yet.

[eekee]

I am wondering, why, as some of you say, [sprites] are "rarely used"? Aren't they a worthful feature?

Sprites are just a primitive form of overlaying textures with transparency, and that's an old trick now. In '05 I built a couple of computers cheaply which could handle thousands of such overlays at once; better than Intel graphics hardware today, if I'm not mistaken.

[kzinti]

Sprites are just a primitive form of overlaying textures with transparency, and that's an old trick now. In '05 I built a couple of computers cheaply which could handle thousands of such overlays at once; better than Intel graphics hardware today, if I'm not mistaken.

The difference between sprites and drawing textures youself is that sprites didn't actually modify the frame buffer. Composition of the frame buffer with sprites was done when generating the video signal to the monitor. The big benefit was that you didn't have to re-draw the sprite every frame and didn't have to restore the frame buffer where the sprite was every frame. All you needed to do was set a new position for the sprite using hardware registers.

Nowaday it is indeed almost silly to try to save this tiny bit of bandwidth to the frame buffer... Especially when you redraw the whole screen each frame anyways.

[Korona]

I don't think anybody is claiming that overlays are a novel invention. Instead, I think a huge aspect today is saving power. If the GPU doesn't need to write to memory, that seems to make a big difference in power consumption. Modern graphics cards do support overlays quite well. I know that Weston can use overlays to directly scan out individual windows without going through the frame buffer. For example, this is useful when movies (or animations, e.g., in web browsers) are played in a window but not on the full screen. I'd assume that other compositors do something similar but I have not checked.

[eekee]

The difference between sprites and drawing textures youself is that sprites didn't actually modify the frame buffer.

Good point! I was thinking that such a texture would save drawing the underlying texture or scene, which is a similar effect but not quite the same.

I don't think anybody is claiming that overlays are a novel invention. Instead, I think a huge aspect today is saving power. If the GPU doesn't need to write to memory, that seems to make a big difference in power consumption. Modern graphics cards do support overlays quite well.

Glad to know overlays are still around. As easy as framebuffers are to use, I always did like dynamic video generation.

If you put a single texture in an overlay, does that constitute a sprite? I suppose it depends on the overlay. If you can move it around by just setting a couple of registers, then it really is a sprite, more so than those of 8-bit Atari computers.* Wow! Real sprites in the present day...

*: 8-bit Atari home computers just had 1-byte registers for sprite data. Vertical variation and movement required CPU action on every scan line. Multi-color required using multiple sprites together. It was good there were 8 sprites, and of course they could be reused if there was no vertical overlap.

[Sik]

Note that the discussion was mainly talking about PC, the embedded world is a wildly different matter and indeed there are still VDPs using sprites for those. (EDIT: VDP = Video Display Processor)

Last month I was looking up electronics components in a site out of boredom and was looking at the new components and ran into a video controller that did over 1000 sprites, scaling and alpha blending included 0_0 (as well as some other niceties like lines and circles), and no it didn't render to a framebuffer, in fact it only has 1MB of RAM (I had to check to make sure). It also supported a single audio channel (either PCM or one of a bunch of built-in sound effects). The single sound channel is meh (unless you couple it with something else to feed its PCM source I guess), but those graphics could have made for a beast of a 2D console.

I admit, it surprised me since I had honestly thought they had stopped with that (especially now that everything has to be "smart" and run Android), but I guess I underestimate the demand for them. I suppose it's still in heavy need for anything based on an Arduino, and now the ESP series (which became popular pretty quickly because it's cheap and includes wi-fi), those cases tend to have limited memory and the microcontrollers being too busy handling other hardware to do smooth graphics.

I worked for a graphics video card vendor at the time. Sprites were not common on hardware and very limited. As Sik mentions, they were used for the mouse cursor in Windows (3.0 / 3.1) and that's about it. Typically they would be very small and only support monochrome black/white.

Pretty sure Windows 98 supports them too. I once had a video mode switch glitch up and I ended up with a glitched mouse cursor in the middle of text mode (it cleaned itself on the next mode switch). Yes, that was the same card that had the broken scrolling in Commander Keen :​P

[eekee]

Awesome!

I worked for a graphics video card vendor at the time. Sprites were not common on hardware and very limited. As Sik mentions, they were used for the mouse cursor in Windows (3.0 / 3.1) and that's about it. Typically they would be very small and only support monochrome black/white.

Pretty sure Windows 98 supports them too. I once had a video mode switch glitch up and I ended up with a glitched mouse cursor in the middle of text mode (it cleaned itself on the next mode switch). Yes, that was the same card that had the broken scrolling in Commander Keen :​P

I don't think the hardware mouse cursor ever really went away. XFree86 & Xorg supported it all through the '00s, if I remember right. Perhaps the drivers map it to some other feature these days, I don't know. In any case, it was obvious there was some hardware feature because the mouse cursor would be present in screenshots if it was rendered by software, but not if it was rendered by hardware.

[Korona]

Hardware mouse cursors are still a thing. A large amount (almost all?) of Linux desktops use them (via drmModeSetCursor() or the atomic/universal planes DRM APIs).

[glauxosdever]

Hi,


Interestingly, I noticed the OP hasn't posted anything since more than a week now. If the rude post that was deleted with a delay of two days is the reason for that, I hate to say it but I think we have huge problems dealing with abuse on these forums...


Regards,
glauxosdever

[eekee]

It's sad that some people allow their opinions of entire communities to be shaped by abusers without giving the mods a chance to deal with the abuse.