3D cards of today are becoming more processor based than generalized like the 3D cards of a few years ago, hence the term GPU. They can now run generalized fragment programs and pixel shaders with excellent floating point throughput, in most cases faster than a CPU. Before long graphics cards will be a processor of their own and real multi-cpu systems will be available (multi-core/processor, and a generalized graphics processor, sound processor, etc). Well we are pretty much already there

I guess I was premature posting this anyway, after I left allegro.cc I wound up in Nvidia website that had a bit of info about ALU's etc.

They also had some SDK stuff with a screen shot that had individual blades of grass visible for 30-50 meters out, and some text blitted showing something like 100K polygons with 35 fps!

Thanks, Bob!

Right now I'm googling for more GL tutorials, more like the Allegro docs than just a bunch of examples like the NeHe (which are very impressive). Just today I got gluLookAt to work because I hadn't noticed I'd always been using all zeros for the up vector.::) Looking through the old Pixelate things today also, have to look in them in depth when I get home again.

Searching Allegro forums for polls on memory etc don't seem to bring up anything about what video cards are capable of, and the few computer capability things I saw were several years old.

Could I assume that the usual video card of today has 64Mb video memory? Can do 1024 x 1024 textures? How many vertices fit into a GL_TRIANGLE_STRIP?

Thanks again

All right! Guess I have to figure it out and port a ton of software rendering stuff to make a demo to brag on! Nobody paid any attn to some island thing I hacked into Allegro software rendering thing last spring.

My mind still boggles over all that hardware in a video card, why don't we have the same on the mobo so we can have our own supercomputers? Or it's too specialized maybe?

[EDIT]
Checking out something called ROAM for terrain mapping, I been doing something like this from watching the terrain "pop up" as you get close in a 10 year old game called EF2000. ROAM is supposed to work very well with 3d acceleration. Also was thinking about (in software renderer) to run the game with flat shading, automatic movement of camera while running while I sleep, would color each polygon a unique color, and keep a database of which polygons were visible from certain areas. Would have to compress to run length bitfields, haven't ever seen this elsewhere.

I don't see how this is more true of ROAM than any other system of adaptive meshing? I also take it there is not yet an analogue to pixel/vertex shaders that allow you to programmatically create a vertex list?

I've never owned a card with any sort of programmable functionality, so please excuse my ignorance.

EDIT: but I did do quite a lot in the realm of full software 3d before obtaining a 3dfx Voodoo, too many years ago for me to be willing to remember. So don't feel the need to patronise.

I really don't see how this would be beneficial.

I don't think so. GPU is prepared to handle large number of short very specific task in vertex and pixel shaders. It works more or less like this:
- vertex shader processes every vertex (but vertexes are processed completely independently)
- rasterizer builds triangles and passes data to pixel shaders
- pixel shader processes every pixel and can lookup textures in the process (but again, every pixel is processed independently)
- then some fixed functions common to most renderings happen: alpha test, stencil/Z-buffer test and blending
- finally pixel is written to frame buffer

It probably is possible to write pixel shader, which will build the tree, but it will be highly redundant, because pixel shader has very limiting output (several floating point numbers - not enough to output too much of the tree). Also pixel and vertex shaders probably don't have enough temporary memory to build partitioning tree. GPUs are built to execute simple operations on loads of input data, but they aren't created to do complex task, unless the task is polygon rendering.

I think it should be probably easier to do space partitioning on CPU and do raytracing with pixel shaders on GPU.

Some adaptive meshing scehemes are better than others, but most of them are suboptimal; That is, there comes a time when NOT doing adaptive subdivision is faster than doing it, simply because GPUs become faster than CPUs, more quickly.

Not yet, but it should come soon enough. It's been one of the touted features of DX10.

They're not all that efficient. See Purcell and al. Sorting doesn't scale with computations, it scales with memory bandwidth (which grows much slower).

Sure, but that doesn't disprove what I said above (btw, this paper was forwarded to me by Tim Purcell, a few weeks ago, who incidentally has his desk adjacent to mine).

You'll want to use Vertex Buffer Objects instead of display lists or immediate mode. That's if you care about performance

I think that's normal considering that to my knowledge most q3a levels had less triangles in total

Perhaps if VBO's are not supported then perhaps EXT_vertex_array can help you a bit. Its ugly to use compared to VBO's but it should give some speed boost compared to direct rendering if CPU is holding you back.

[edit]

Funny, I've always thought display lists are the most efficient things for static geometry. Are VBO's really faster for static stuff?

My windows dll's don't have a EXT_vertex_array, but they do have a GL_EXT_compiled_vertex_array...

I see the Alleggl stuff has the EXT_vertex_array, but I'm having way too much trouble with it on windows, my slackware distro compiled version wouldn't respond to any input except cntrl-alt-backspacing my way back to console, and I need to get some glut stuff to get it to compile on my old Mandrake to check it out on that.

The 100k polygons reference was comparing to the NVidea demo thing, so (ignoring furthur optimizations I'm missing) the NVidea computer is about 7 times faster.

The car racing game will "skip" some vertices to make larger polygons in the distance to cut the total down. "Mipbumping?" Somewhat ROAM like. The Allegro thing I put in off topic ordeals last spring had a crude version.

So much to check, so little time...

I just reran the old Allegro thing on this Celeron, it got 12-13 fps @ 320x240x16 at the corner of a 128x vertex array, the gl thing got 23 fps under the same conditions, zbuffering and backface culling didn't seem to slow it down. The allegro thing had prerendered lighting on the slopes (but there was some sort of fencepost error, but that'd be trivial to fix) and there was an occasional clipping error. Got to split up the texture map into small strips for gl, also Thomas Harte was saying to do that for the software thing anyway, it'd cache better too. I forget (already) what my own software stuff did on the AMD K6-2, was much faster than allegro but fog etc. would have slowed it down again. can't run it on this celeron because the stupid vesa implementation sucks so bad and scitech doesn't grok, but gl is better even if I don't get all the fancy stuff down. There, I admit it!
Gotta go now, maybe back Monday.

[EDIT]
Some sort of dll with x810 something or other had the GL_EXT_compiled_vertex_array, so I suppose the Intel drivers are incomplete. NO dll had the EXT_vertex_array.