I've recently been reading the Chris Hobbs' win32asm game writing articles' serie. Well, I haven't finished it yet, but I have already tested the binary. Can you imagine how astonished I was when this game(tetris) turned out
to be damn slow. Well, I agree I have a bit outdated computer(PPlain 90, 40MB Ram,Win95 OSR2), but StarCraft was running absolutely smoothly on it. How does it turn to be, that DirectX(I have DirectX 8.0 SDK installed), precisely
DirectDraw, is so slow?

I just can't believe it ;(((

Any ideas???

P.S. If yes, then I will have to think about DOS graphics programming(Graphic Programming Black Book and Zen of Graphic programming rule!).
Posted on 2002-10-26 09:20:17 by Zedr0n
Well, Starcraft is a piece of art (IMHO has many many maybe ASM optimizations inside)
First it uses 8 bit GFX and that is damn fast, alpha blending is done by table lookup and that is again damn fast and possible for only 256 colors...
Besides it uses 640x480 resolution...

As you can see a lot of time saveiours

Besides there is the issue of monitor refresh rate when using ->Flip() method ... if you syncro the final drawing to the verstical refresh rate you can only have 60 up to 120 max fps no matter how fast you draw.

IMHO Starcraft is not using this syncro because you ca easyly see some tear off when fast scrolling over a lot o selected PILONS on a slow PC

DirectDraw is pretty fast IMHO but curent video board technology and sometimes DX itself are careless for 2D performance, they only concentrate on 3D performance. On 2D you are on your own with your CPU power...

Video to video - 2D hardware blitting is very fast but unfortunately it has no support for alpha blending(???) and you can not make games without explosions and such ... also it is pretty hard to keep all sprites inside video memory as support for custom compression algorithms is inexistent...

We do pretty well on HE however ;)

Because of curent 3D limitations (triangles and stuff) 3D rendering is extreemly fast but quite limiting IMHO on what you can really do... just small variations on the same themes no real new stuff (like ray traceing)

This also creates an false impresion on the speed of current CPU witch is much more lower then usually expected...

For example a AMD k6/2 at 400Mhz with a fast 3D video board is very capable of playing a little old 3D games but fails miserably on 2D strategic games because on low CPU computation power (but Starcraft work)

I guess i can stall with complex 2D operations even some new P4s :)
because of this we have droped 32 bit and curently using 16 bits pixel formats on HE

Please fell free to ask for directions on any 2D stuff
Posted on 2002-10-26 11:20:09 by BogdanOntanu
the notion of raytracing being "new" brought a smile to my dial...

I've been involved in coding 2d and 3d fx ever since the single color vector demos of the Apple 2 era, and I've seen a lot of changes over this time.
I witnessed the introduction of matrix math and was coding 8 bit 3d using trig-based rotation via a sine lookup table at the time. Raytracing has been with us since shortly before the introduction of matrices in 3d math. It's always been somewhat out of reach in the past due to it ultimately being about per-pixel calculations, but then again, today that's become normal, with pixel shaders being the perfect example. That's exactly why there's no need for DirectX to enshrine raytracing as a rending method... it's available through pixel shading.
Portal-based raytracing likewise can be performed via drawing subsets using your own pixelshader ray renderer.

Nothing much is new huh, it just gets applied in new ways...
Posted on 2002-10-27 00:38:58 by Homer
Hehe EvilHomer2k

I do not mean emulating raytracing via pixelshaders, i mean the ability to use your own algorithms in creating the 3D final image, this is something you just can not do... today. I agree pixel shaders add a level of custom design to current triangle scanline algorithms but that is it... just a touch of... pathetic IMHO after all ANY software triangle renderer coul easyly add procedural pixel shaders to any texture it wanted at any time and WITHOUT use of a strange new assembly language :) ... as you can see i agree it is a plus but...no new algorithm

Why not doing fuul real raytracing in video boards? i do not mean Portal based raytracing i mean per pixel ral raytracing like in POv RAY...this is the future IMHO and curernt 3D algorithms are just much to optimized ...

sorry have to go i will contimue later .... cya
Posted on 2002-10-27 07:31:55 by BogdanOntanu
I see that day coming very soon, right now remember that only a small percent of video cards out there support pixelshaders in hardware.
Yes I know, the ugly ugly coprocessor instructions ...
well, I can't see them going anywhere for a while, what I can see happening is that we will be more and more loading code to the video memory and executing it from there in hardware, which is very much akin to the days of the commodore64 where all devices had their own cpu and memory and operated asynchronously to the main cpu and memory, which served them through hw interrupts.
The simple fact is that any api which purported to be performing these functions in hardware is really just going to be compiling the code for the hardware shader on the fly. The alternative would be the api precompiling the entire pixelshader code before rending begins, which is not at all flexible.
I feel your pain! Alas, we never get an even break. There's always going to be subsystems where hardware acceleration is involved, and we'll always have to code in some fancy shmancy opcode set. I guess that doesn't bother me since I've coded on so many cpu's at the opcode level that a new instruction set isn't frightening anymore. Anyway, we're off topic, the original question asked whether the code in DirectX is at fault in slowing down carefully coded binaries, and I agree that although some of DX has been optimized and DX is generally quite decent, it is indeed slow, and could be improved through further optimization. I must disagree that the 3D side is fast in comparison to the 2D side, because ultimately the thing which slows D3D down is its matrix math functions, which quite frankly, suck. The light at the end of the tunnel is that because DX is a library, you decide what functions to use and what functions you will replace yourself in your code since they suck so badly. How can D3D be faster than the 2D functions since D3D inherits its 2D functionality from DirectDraw, and since then it has a bunch more code on the top? Oh, the lighting equations also suck (badly), and now I've berated the entire T/L pipeline u may wish to consider the fact that most ppl don't love DX for its speed or grace but simply because it allows them more or less transparent access to the graphics card's higher functions, and will work for the gamut of cards out there (would you like to code a driver interface for every single card likely to be in a box running ur warez? I didn't think so !!)
Posted on 2002-10-27 10:00:43 by Homer
Hi i am back,

Well my pain is not because of stupid instructions of eithrt the coprocesor or the video board GPU. I have also codeD for may CPUs and hardware one more stranger than the other. My problem is vith video board architecture and concepts that it is IMHO very wrong those days. .. limiting to one single algorithm for generateing 3D images is simply PATHETIC...

Yes the addition of pixel shaders is a big steep forward BUT in the wrong direction because it is only affecting textures not the geometry or the algorithms used to generate 3D objects... I also do not sympathise with the hardware oriented approach for the sake of speed in one direction only... this LIMITS creativity and basically limits our way of thinking and evolving as programmers. I prefer software solutions or hardware that is capable to accomodate as many algorithms as possible.

The current line of video board developement is purely comercialist... i did not say that reaytraceing as an algorithm is new, it is just new to use it on video boards (actually never happend besides some emulation via triangles tests), and since at the current CPU power it becomes quite possible to use it and it looks 10x better than curent scanline algorithms... why not start useing it? Because the video board industry will loose a lot of money / research... they over invested in this line of products ... that is why...

So instead they will push this line further and further until every drop of money was taken out of the market... even if they know this i wrong. one part of this push is to hide 2D optimised functions from the programmer.

Yes i think it is pathetic that 2D exposed fuctions are slower that 3D since i agree with you that 3D has to use 2D to fill tirangles (with current algorithms). Manufaturers just choosed not to expose the fast 2D functions to the public :( in order to gain an 1-2% extra speed for the 3D rendering...

I think i have answered the original question also:

NO DX is not slow.

Actually it is the fastest API available, you can only use HAL drivers if you want to be even faster and that is very hard...(PS. OpenGL is extreemly slow ;) ESP on 2D ).

However DX is not so programmer friendly as OpenGL but it is becomeing (and slowing down also of course with DX8)

For 2D speed take care at:
-never read from video memory
-make your own routines to gain some speed and take advantage of particular resolutions/pixelformats
-avoid syncro with monitor refresh rate if possible and if gaining something
-avoid multithreading
-do not over estimate CPU/GPU power at high resolutions and pixelformats just because 3D game "X" works. 3D games "cheat" by using video board to fill huge areas on screen.
-did you know that compiled sprites are 2x up to 5x faster on modern CPUs ? (but also eat huge RAM so it is not a thing for RTS games rather for arcade)
Posted on 2002-10-27 13:47:23 by BogdanOntanu
First of all, thanks for all the answers.

Can you direct me at some good DirectX programming
tutes, especially win32asm?

And one more question? Can anything good looking be
developed at PPlain90 with 1MB video ram? With a lot of
assembly optimization? I believe it can, for 'There ain't such thing as fastest code', and, well, Michael Abrash did code Quake ;) I have another computer at home(a much more
powerful one(Athlon 1.5 Ghz, Geforce 32 MB)), but I would
really like to try to squeeze as much perfomance as I can
from my old P90. Is that possible?

Once again, thanks for answers...
Posted on 2002-10-28 12:06:19 by Zedr0n
There's lots of D3D tutorials around but most are written for C coders.
Scronty has some cool example sources and imho the most bugfree masm includes for dx8 and 8.1 at his site, scrontsoft
They aint tutorials, but I recommend u grab them, and then study them while reading the tutorials available at say gamedev
This will teach you to teach yourself :alright: and then you will be able to reach for the stars.
Posted on 2002-10-28 23:13:25 by Homer

the notion of raytracing being "new" brought a smile to my dial...

I've been involved in coding 2d and 3d fx ever since the single color vector demos of the Apple 2 era, and I've seen a lot of changes over this time.
I witnessed the introduction of matrix math and was coding 8 bit 3d using trig-based rotation via a sine lookup table at the time. Raytracing has been with us since shortly before the introduction of matrices in 3d math. It's always been somewhat out of reach in the past due to it ultimately being about per-pixel calculations, but then again, today that's become normal, with pixel shaders being the perfect example. That's exactly why there's no need for DirectX to enshrine raytracing as a rending method... it's available through pixel shading.
Portal-based raytracing likewise can be performed via drawing subsets using your own pixelshader ray renderer.

Nothing much is new huh, it just gets applied in new ways...


Well, I happened to stumble upon this ancient thread, and I thought this was interesting enough to respond to.
Yes, raytracing is one of the oldest means of rendering on a computer, if not THE oldest. You can find papers on raytracing dating back to the 1960s.
It is older than the concept of triangle rasterizing.
As for matrices... they are a mathematical concept, and were conceived hundreds of years before the first computers arrived. Geometric calculations using matrices predate computers altogether.

And to get back to the original question: DirectX is very fast, when used properly. I was an 'early adopter' of DirectDraw, starting to use DirectDraw 1.0 on a 486DX2-66 on Windows 95. The performance difference with DOS was negligible, even back then. These days Windows is the fastest common OS for graphics on x86-based PCs, with Direct3D being the fastest API on Windows. And while OpenGL is slower than Direct3D on Windows, Windows is still faster at OpenGL than alternatives such as linux and OS X.
Posted on 2011-01-10 04:33:33 by Scali
That takes me back a long way :D
Bogdan was such a nice fellow, it's a pity I was not more interested in game development back then, I could have learned something from him.
Now it has become my life, and there seems somehow to be less to learn :(
IGDA Melbourne
Posted on 2011-01-10 05:32:41 by Homer
I suppose Bogdan crossed over to the Dark Side?
Posted on 2011-01-10 06:33:05 by Scali
Nah, I am beyond Light or Dark Sides... I am still watching you :D but granted I do prefer the MASM32 forums to this one ;)

And reviving such an old thread is "priceless"

But yes I do agree that DirectX is the fastest GFX API even today.

I do "detect" a tendency of DirectX to become more "user friendly" and more "like OpenGL" and  slower  with every new release :D However since CPU and GPU's become more powerful and have more features this tendency is partly compensated by hardware.


Posted on 2011-01-10 12:24:23 by BogdanOntanu
I'd say that Direct3D has become more difficult since DirectX 10.
They completely cut out the state machine and the fixed-function shading.
This means that when you want to get anything on screen at all, you need to write vertex and pixelshaders, and also devise your own pipeline for matrix handling and related tasks (texture states, alphablending, that sort of thing).
In Direct3D 9 and earlier, you could get things on screen with a lot less work, much like OpenGL.

In theory, some of the changes to the API and driver model introduced in DirectX 10 should make it more efficient, but in practice I've not seen too much of it.
On my nVidia card, performance from fastest to slowest is something like this:
1) Direct3D 9
2) Direct3D 10
3) Direct3D 11
4) OpenGL

Direct3D 10/11 have come a lot closer to Direct3D 9 with some driver updates though, so perhaps it's only a matter of time.
Posted on 2011-01-10 14:17:03 by Scali