Page 2 of 2

Posted: Tue Aug 26, 2003 8:34 pm
by coma
So, clearscreen() and box() commands are very fast (compared to asm copy or poke command) because they use DMA copy or videocards hardware ? (via direct X ?)

Uep, pretty much so.

Posted: Tue Aug 26, 2003 10:45 pm
by oldefoxx
it it is a Windows API command, then it goes through the video drivers. The video drivers provide optimized code for working with a specific video card, and was written by the manufacturer, and sipports every valid video mode for that video adapter. You frequently read where a new video driver is released to improve performance, and where editors sometimes think that the video hardware will probably fun faster after the manufacturer releases their final video software. It's all about building features into the hardware that the drivers are designed to use, but which fall outside the relm of CPU usage. You could conceivably write your own drivers if you understood the hardware well enough, and you could also bypass Windows API and call the existing drivers directly if you understood the nature of the drivers well enough. All this would promise some speedup with the existing hardware, but at the risk that you would move towards a specific hargware configuration and incompatabilities with other platforms.

Also note that more expensive video memory may be capable of allowing the CPU and the Video Card simultaneous access to the same memory address, but that most video RAM can only permit one to have access at a given moment. This could be an added bottleneck when writing to the front buffer. By writing first to the back buffer, then having the video card flip the buffers via Purebasic via windows via the video drivers, you obtain the fastest throughput that is likely possible for that machine.

Although using APs may mean some loss of speed compared to a direct effort to optimize the manipulation of the hardware, the ease of using the APIs and the acceptable performance level with them make this the preferred route. Besides, as you pointed out, DirectX was an effort to reduce the latency of the standard API calls even further, so that you could make a given PC perform much better at games and other video tasks. So learning DirectX (or OpenGL, or other graphical calls) will help you towards the end of faster and smoother screen updates.

A limitation, though is that there will always be a certain roughness to screen updates with Windows, a slight jerkiness during the updates. This is a byproduct of the operating system itself and how it multitasks. It is generally less of a problem under a Windows NT (including 2000 and XP Pro) then it is under Windows 9x/ME, which are not true multi-user, multi-tasking platforms. Further, Unix, Linux, and BeOS are simply better at multi-tasking than Windows is, but they do not have the depth of applications available for them that Windows does, and likely have far fewer processes loaded and running at the same time. I was particularly impressed at how well BeOS performs with simultaneous processes running. You could have multiple video clips open and running at the same time with no artifacts shown such as freezes or jerkiness. If you haven't heard of BeOS, it is much like Linux, and was offered as a free download on the internet (I haven't checked lately, but you use to be able to get it and some aps through http://www.chet.com, and could buy a professional version if you wanted to).

Posted: Tue Aug 26, 2003 11:35 pm
by Karbon
BeOS was a great idea -- too bad they sold a while back..

Though I've never used it I think you can get the free versions from http://www.bebits.com/...

I'll take every opprotunity to plug my favorite server OS FreeBSD - http://www.freebsd.org...

Posted: Wed Aug 27, 2003 8:58 am
by Fred
ClearScreen() use the DirectX command 'Fill' which is hardware implemented. Box() use the API which probably use DX in this case... That's why it's faster than your CPU only method.

Fascinating...

Posted: Thu Aug 28, 2003 8:48 pm
by LJ
A fascinating discussion guys. If anyone knows how to write directly to the screen using Purebasic Inline Assembly with code that is faster than Direct X, please post in Tricks and Tips. I found some code in NASM which the author claims to be 1000% faster than DirectX but unable to convert in Purebasic Inline Assembly. Looking for more material for the Inline Assembly for Beginners sticky thread. Thanks.

Lj

Posted: Fri Aug 29, 2003 9:30 am
by Fred
In most case, DX uses the graphic card hardware (trough the dedicated drivers) to performs the operations and it's not possible to have a 'CPU only' routine faster than an hardware chip (unless you have a very very old gfx card with a very very new CPU which I seriously doubt :-)

Check out

Posted: Fri Aug 29, 2003 9:12 pm
by LJ
@Fred,

Check out http://www.fastgraph.com/tutorial/bench.html

This company's product FastGraph (at $300) blows the socks off DX Software rendering tests. (See benchmark tests above)

The company boasts this capability because of their optimized assembly language code: "Fastgraph is a programmer's graphics library, meaning it is low-level (assembly language) code you can use in your program to create things like graphics primitives, bitmaps, animation, and 3D rendering. Fastgraph supports most video modes, graphics chipsets and compilers. It is easy to use, small, quick, well-documented, and compatible with most other programming toolkits. Fastgraph makes graphics programming easy!"

and "Our code is expertly written in hand-optimized assembly language. Fastgraph is easy to use, thorough, powerful and fast."

Posted: Sat Aug 30, 2003 12:49 am
by coma
Fastgraph software rendering is faster than Direct3D software rendering.

directX software rendering is very slow....