[…]
>DO> (Tired of fast 3D with crappy RAMDACs... :-( Cost is not an issue - but when not even $10,000+ cards (that you have to order built into a custom system, BTW) can do more than 1600x1200 properly, >DO> one gets seriously worried.) > >Go LCD! ;)Yeah, I considered that, but at the time, the best LCD I could find was twice as expensive as the CRT I bought, and still had significantly worse performance. heh (Oh, and the G400 wasn’t that out of date at the time.)
LCD is not quite there yet, IMHO. Or rather, I find their artifacts more obvious and more annoying than those of a good CRT. The latest high end LCDs look interesting, though.
I did think about modifying some good DVI->analog daughter board for use with a hot nVidia card, but hopefully, I won’t have to mess with that now.
Besides, I don’t really need the fastest 3D around; just something that doesn’t drop to 5-10 fps when you enter some rooms in certain Q3 engine based games… (This is on a P-III 933, though - maybe I need to upgrade that as well? Q3 seems to go accelerator bound around 400 MHz, but I’m quite sure that’s not the case with RTCW or JKII.)
Anyway, interesting though this topic is, it’s hopelessly off-topic.
Perhaps we can get back on-topic now?
Right.
So… How about aiming for portable accelerated graphics? And this applies to SDL (glSDL, “D3DSDL”), as well as games (using OpenGL or D3D directly).
glSDL was the easiest and most portable way I could think of to get full acceleration, alpha included. And acceleration is required for any serious fullscreen action, IMHO. Fullscreen games may run “ok” on Win32 only because of the busmaster DMA support in DirectX, and games can achieve acceptable frame rates w/o busmaster DMA either because they’re only animating part of the screen, or because they’re using very low resolutions.
I used to think software rendering was fun and flexible, especially for 2D, but I’ve more or less given up. It’s not worth the effort. It requires optimized low level code, it imposes lots of restrictions on design and rendering, and you still end up with something that runs dog slow on anything but Win32, and at best, with acceptable speed on Win32. SIMD code is non-portable, and doesn’t eliminate the PCI/AGP bottleneck.
As to quality, the brute force approach of abusing sub pixel accurate rendering to reduce tearing on targets without retrace sync doesn’t work with software rendering. No mainstream CPU has the power to compute that in real time, without imposing even more restrictions upon the engine. Granted, this is mostly about 2D games - there isn’t much to do about it for 3D games anyway. Only retrace sync can fix it properly - and here we go again; retrace sync is much easier to do right in a heavily buffered system like an OpenGL implementation. (Note that actual retrace sync should only be done in the driver, or even better, by the h/w. The application should just block whenever the command buffer is full.)
Finally, there’s this “total CPU power” issue. Software rendering consumes lots of CPU power as it is, and it gets even worse when the CPU has to spend half the time blocking on the AGP or PCI bus when trying to write to VRAM.
Sure, it would be possible to implement busmaster DMA blitting on some of the platforms that lack it, but that doesn’t make it look all that much more attractive to me to have the CPU do what the GPU can do much better (most of the time, at least) in a fraction of the time.
Besides, how many driver hackers care? Some people have showed interest, but of those I seem to be the only one who could actually do it, and seriously considered doing it. As a result, I now believe that I would have wasted my time maintaining (possibly eternally unofficial) patches for one or two targets, and two or three cards.
I think OpenGL is a much safer bet for fast, fullscreen 2D, as well as any real time 3D. It’s a much safer bet for driver hackers as well, as lots of people actuall want these drivers to be as good, fast and reliable as possible.
There is an “accelerated OpenGL” community, with lots of users and a bunch of hackers. AFAIK, the “busmaster DMA for 2D blits on Linux” community was me and a few other Linux loving software rendering die-hards. (Anyone left? 
As to the cases where you really want software rendered effects, well, OpenGL wins again. Apart from the accelerated “post processing” stuff a GPU can do with procedural textures, it seems that if a video driver supports busmaster DMA transfers to VRAM in any way, it’s most likely through OpenGL texture uploading, and not through some 2D API primarilly designed and used for desktop productivity applications.
//David
.---------------------------------------
| David Olofson
| Programmer
| david.olofson at reologica.se |
|---|
| Address: |
| REOLOGICA Instruments AB |
| Scheelev?gen 30 |
| 223 63 LUND |
| Sweden |
| --------------------------------------- |
| Phone: 046-12 77 60 |
| Fax: 046-12 50 57 |
| Mobil: |
| E-mail: david.olofson at reologica.se |
| WWW: http://www.reologica.se |
`-----> We Make Rheology RealOn Tue, 4/06/2002 17:13:11 , Neil Griffiths <n.griffiths at virgin.net> wrote: