Do you honestly think a multi-billion dollar corporation is gonna just make some decision on the fly w/o thinking about it first? "Uhh, 2d sucks, we only made a couple mil off our last couple of 2d games (Age of Empires I and II), let''s scratch it for a while and see what happens." I don''t think so. (don''t quote me on the couple of mil thing). You know they''ve thought this through and through before they wrote a single line of DX8 code. Remember, they didn''t become millionaires/billionaires for nothing!
"We are the music makers, and we are the dreamers of the dreams."
- Willy Wonka
No BLT with DX8?
Why would they improve the DirectDraw interface in DX9 and not in DX8? If DirectDraw is important enough that it should be updated in DX9, why don't they enhance it in DX8?
I don't even use DirectX, I'm just curious.
Paulcoz.
Edited by - paulcoz on November 1, 2000 12:46:27 AM
I don't even use DirectX, I'm just curious.
Paulcoz.
Edited by - paulcoz on November 1, 2000 12:46:27 AM
Well let''s see if I can explain why things get cut in microsoft products.
Direct X is one of microsoft''s which is developed by 2 teams at one time. The first team works on Direct X 8 , and the second team works on Direct X 9. If team 1 misses their deadlines consistantly they are normaly fired, and team 2 takes over. When one team finishes they start working on Direct X 10. This is why we had a DirectX 3.0 to Direct 5.0 jump a few years back.
This is also the reason why microsoft knows what will be in Direct X 9.0 when Direct X 8.0 hasn''t even been released yet. As you can imagine the pressure in this type of situation is fairly great. So if a feature can''t be implemented with in the alloted time it is often left out and passed on to the other team. This allows Microsoft to release a new version of Direct X every year or so.
So if a feature was left out it''s probably for the best. If the feature had been implemented the rest of the API may have suffered in order to get it out on time.
Direct X is one of microsoft''s which is developed by 2 teams at one time. The first team works on Direct X 8 , and the second team works on Direct X 9. If team 1 misses their deadlines consistantly they are normaly fired, and team 2 takes over. When one team finishes they start working on Direct X 10. This is why we had a DirectX 3.0 to Direct 5.0 jump a few years back.
This is also the reason why microsoft knows what will be in Direct X 9.0 when Direct X 8.0 hasn''t even been released yet. As you can imagine the pressure in this type of situation is fairly great. So if a feature can''t be implemented with in the alloted time it is often left out and passed on to the other team. This allows Microsoft to release a new version of Direct X every year or so.
So if a feature was left out it''s probably for the best. If the feature had been implemented the rest of the API may have suffered in order to get it out on time.
quote:Original post by Anonymous Poster
Uh, from what people have already stated, DX8 has no Blt and no surfaces, so how would you blt a DD7 surface onto the backbuffer for DX8? DX8 doesn''t have "surfaces" to Blt onto, so you can''t use DD7''s Blt. There is no DX8 Blt, so you can''t use that.
Well just because you install DirectX 8 doesn''t mean that you can''t use any of the old interfaces. When you installed DirectX 7, you could still access the DirectX 1 interfaces, right? It''s all backwards-compatible, so don''t worry about it. Us 2D people will just keep using the DD 7 interfaces and wait to see what happens when DX 9 comes out. That is, unless Microsoft has decided they want to break COM into pieces, and deny DX 8 users the ability to play any game using DirectDraw, heh. They wouldn''t do that... I don''t think. ::looks around nervously::
-Ironblayde
Aeon Software
The following sentence is true.
The preceding sentence is false.
DX8 has merged 2D and 3D because that''s the way to go given the current/new set of graphics cards.
Todays graphics cards can throw millions of polygons around, but are really crap at 2D operations, so if you write your game using triangles for everything then it will be substantially faster than if you used (outdated) blits.
Plus you get the benefit of (almost) free scaling, alpha, rotating, lighting and blending.
If you want to support older computers with 2D graphics cards, then stick to DX6/7.
Personally I think it''s the best thing they have done to DX
Todays graphics cards can throw millions of polygons around, but are really crap at 2D operations, so if you write your game using triangles for everything then it will be substantially faster than if you used (outdated) blits.
Plus you get the benefit of (almost) free scaling, alpha, rotating, lighting and blending.
If you want to support older computers with 2D graphics cards, then stick to DX6/7.
Personally I think it''s the best thing they have done to DX
Is Microsoft finally figuring out what SGI realised ages ago? 
I am majorly ignorant about DirectX - I''ve set up a full screen window, blitted some bitmaps and draw some lines, but just got irritated when I found out how dumb it''s color-keying is.
The fact that they wrote DDUtil.cpp to cover up that the API doesn''t allow you to specify RGB colors for a color key is ridiculous. Little things like this should be integral to the core API, not afterthoughts.
Plus, I suppose I am a neat freak and just plain can''t read DX code. It messes with my eyes.
OpenGL is just so clean and readable. Also - using lock to manipulate pixels, why does it have to be this way - Why is setpixel so slow?
A good SetPixel function was the holy grail of Mode 13 and such graphics modes and did everything - I really enjoyed that.
Can anyone tell me in laymans terms why things aren''t that easy now.
Game programmers shouldn''t have to struggle with an api - there shouldn''t be the need for forums such as this.
If the API was implemented well and documented clearly life would be much better - we could get down and make games, not struggle for ages just to plot some pixels.
And I''m not just blowing GL''s horn either - even GL can be a major cause for frustration. We shouldn''t have to deal with the fact that some implementations can only handle limited texture sizes etc. etc.
Chris
I am majorly ignorant about DirectX - I''ve set up a full screen window, blitted some bitmaps and draw some lines, but just got irritated when I found out how dumb it''s color-keying is.
The fact that they wrote DDUtil.cpp to cover up that the API doesn''t allow you to specify RGB colors for a color key is ridiculous. Little things like this should be integral to the core API, not afterthoughts.
Plus, I suppose I am a neat freak and just plain can''t read DX code. It messes with my eyes.
OpenGL is just so clean and readable. Also - using lock to manipulate pixels, why does it have to be this way - Why is setpixel so slow?
A good SetPixel function was the holy grail of Mode 13 and such graphics modes and did everything - I really enjoyed that.
Can anyone tell me in laymans terms why things aren''t that easy now.
Game programmers shouldn''t have to struggle with an api - there shouldn''t be the need for forums such as this.
If the API was implemented well and documented clearly life would be much better - we could get down and make games, not struggle for ages just to plot some pixels.
And I''m not just blowing GL''s horn either - even GL can be a major cause for frustration. We shouldn''t have to deal with the fact that some implementations can only handle limited texture sizes etc. etc.
Chris
DirectDraw actually has very fast pixel accessing times, since you are allowed to directly access the display buffer. You need not use SetPixel(), which is:
a) A GDI function (so a lot slower)
b) Not part of the DirectX API in any way.
The reason DirectX is designed as it is is mainly for user customisation and speed. It allows you to write your own Pixel Plotting, Line Drawing and Bltting functions, you need not use the hardware Blt functions to Blit stuff. In fact, some OpenGL drivers use this part of DirectDraw for drawing onto the actual screen (I kid you not, this is why you cannot use DirectDraw and OpenGL simultaneously).
Please state the nature of the debugging emergency.
a) A GDI function (so a lot slower)
b) Not part of the DirectX API in any way.
The reason DirectX is designed as it is is mainly for user customisation and speed. It allows you to write your own Pixel Plotting, Line Drawing and Bltting functions, you need not use the hardware Blt functions to Blit stuff. In fact, some OpenGL drivers use this part of DirectDraw for drawing onto the actual screen (I kid you not, this is why you cannot use DirectDraw and OpenGL simultaneously).
Please state the nature of the debugging emergency.
TheLabRat, what you are saying about what you should have in an API is actually not possible at any reasonable speed on todays computers. To have everything set up for you like that, quite frankly, it''s not gonna happen. Same thing to people who say an application should not be able to crash the OS. If an application is constantly being checked by the OS, how can the program be expected to run at a reasonable speed?
Please state the nature of the debugging emergency.
Please state the nature of the debugging emergency.
Thanks Furby,
I know that setpixel is not DX, but why lock the frame-buffer - I still don''t see why all the complexity is needed.
In mode 13, you just wrote to memory to change what was on the screen - and to stop flicker and seeing changes, you waited til the screen was tracing back up again. Surely it is not that hard to just have a DirectDrawSurface.SetPixel function that works at a reasonable speed - and what advantages would our own blit functions have over hardware ones?
Chris
I know that setpixel is not DX, but why lock the frame-buffer - I still don''t see why all the complexity is needed.
In mode 13, you just wrote to memory to change what was on the screen - and to stop flicker and seeing changes, you waited til the screen was tracing back up again. Surely it is not that hard to just have a DirectDrawSurface.SetPixel function that works at a reasonable speed - and what advantages would our own blit functions have over hardware ones?
Chris
You have to ''lock'' the frame-buffer because you don''t know what''s happening to it at a given time. While your code is executing, the graphics card could be doing all sorts of fancy rendering stuff at the same time, so you can''t just write arbitraily when you want anymore.
As for SetPixel, it''s not really of any use (I think) to be able to set a single pixel (considering a typical screen is now 640x480x16bpp minimum).
Writing your own blit function is useful if you want to perform blits using techniques that the hardware doesn''t have (i.e. Alpha/rotating etc.). This is more important on older machines that don''t have decent 3D hardware.
Don''t forget that a lot of the complexity comes from the vast diversity of different graphics cards which all have their own specifications and features.
As for SetPixel, it''s not really of any use (I think) to be able to set a single pixel (considering a typical screen is now 640x480x16bpp minimum).
Writing your own blit function is useful if you want to perform blits using techniques that the hardware doesn''t have (i.e. Alpha/rotating etc.). This is more important on older machines that don''t have decent 3D hardware.
Don''t forget that a lot of the complexity comes from the vast diversity of different graphics cards which all have their own specifications and features.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
