My latest gfx code(actually 2 years old) is not released, coz it is ugly and I found better ( but slower ) implementations of same idea (see swShader). I never got to something more complex than 32 bit(RGB or 8-bit paletted) sprites with several blending modes(add/sub/colorkey/alpha..). Originally it was supposed to replace all old rendering code in my PSX GPU plugin ( ej.psxfanatics.com) .
Main idea is simple. we can make generic "blocks" that process image data, for 1,2,4 pixels. then we can assemble code chains from this code, handling 1..n pixels, starting from aligned/unaligned addresses/etc. , then place entry points into array. chains can jump to each other forming some sort of tree , using less cache lines in L1 cache. this approach results in fastest image processing code known to man It is also possible to generate different basic blocks, after querying CPU capabilities ( check support for MMX/CyrixMMX/SSE/3DNow... ).

OffTopic: How do you pronounce your name ^o)

oh, and isn't 5ticks/px a bit much - seems like a primitive solution, because for example a P4 HT can make 3 micro-operations in one tick in each ALU meaning 30 micro-ops to each pixel - what a waste

Of course I've got no idea of what magic are you doing there but what shading algo takes that much?

More offtopic..
Madis731:
> How do you pronounce your name ^o)
Being from former USSR, you must know
http://www.answers.com/Hedgehog#Dictionary
"yozh" or "iodzh" or something like that

I mentioned real-life benchmarked performance on P-III-compatible Celeron CPU . It is a bit different from yours. you must also consider that only simpler operations on p-IV are 2(3???) per clock on single ALU and even they usually require proper scheduling, frequently unreachable IRL. Alpha-blending involves integer multiply, which can take on p-IV up to 18 clocks (generic MUL), up to 8 (MMX version), according to Intel manuals. Of course, max throughput is higher, but, again, unreachable because of small number of registers ( and "renaming" is not a replacement for "real", adressable registers ).

ugh...
E}I{: Can you help me out, I've looked and I can't find all I need to program a starting VESA 2.0 1024x768 mode in C!?
I've found what I need, but then I'm having trouble with libraries and versions/makes!!!
Caould you just send me a few files and get me started!?

Heh.. When I used DOS & VESA long time ago, I only got to page-switched vmem access (VESA 1.2) from real-mode. Sorry.. Currently I use Win32/DirectDraw.

еж => E}I{ I got it, but I couldn't remember what was the translation from Russian

what;s the dif between 1.2 and 2.0?
Speed? or what, lol

Wouldn't 1.2 be just as fit for 1024x768 32bpp?
*If it is then I'll take any source code I can get!

No, 2.0 makes some things easier to code.

Yes, but you will have to code a specific (bankswitch) driver for your card.
(sidenote, it's not because you have 1024x768@32bpp in -MS Windows- that the same resolution is possible with vesa.)

Anyway, I'm sorry for not wanting to share my extremely outdated experience of splitting primitives between two or more video pages using mostly 16-bit inline asm I even didn't knew about possibility to use two page windows at A000 & B000
And I don't feel like learning newer but still useless for me methods for no reason... -_-

dCool, tell me if this is an amazing enough idea :

To write a GUI in which all (graphical) applications have their main window actually as a browser's window (without those decorations, of course ). A simple browser connected to localhost (or a distant one, why not ?) , where a simple http server is placed; a browser having an instance for each graphical application.
So, writing an graphical interface for an application is simply to write a html page. And eventually a script in JavaScript if the browser is capable enough. The binary part (the not-graphical part) of the application to be accessed through cgi.