No BLT with DX8?

Started by
82 comments, last by Gazza 23 years, 6 months ago
Get DX7, look in the SDX, and look up Direct3DX Utility library under Direct3D. It has sprite drawing functions in it.
Advertisement
grasshoppa: there''s a tutorial right here on gamedev about using Direct3d for a 2d isometric, tile-based game. It would be really easy to change it to a different type of game.

quote:
but why lock the frame-buffer - I still don''t see why all the complexity is needed.


    lpDDSfront->Lock(NULL, &ddsd, DDLOCK_SURFACEMEMORYPTR     DDLOCK_WAIT, NULL);    buffer = (USHORT*)ddsd.lpSurface;		buffer[rand()%640+((rand()%480)*ddsd.lPitch>>1)]=(USHORT)RGB(0,0,0);    lpDDSfront->Unlock(NULL); 


Oooh, real hard .

quote:
but just got irritated when I found out how dumb it''s color-keying is.


DDCOLORKEY	ddcolorkey;	ddcolorkey.dwColorSpaceLowValue  = color;	ddcolorkey.dwColorSpaceHighValue = color;	lpDDSbmp->SetColorKey(DDCKEY_SRCBLT, &ddcolorkey); 


I''m strugglin'' here.

quote:
In mode 13 ... to stop flicker and seeing changes, you waited til the screen was tracing back up again.


lpDD->WaitForVerticalBlank(DDWAITVB_BLOCBEGIN, NULL); 


I think you get the idea here.

I''m not picking on you LabRat, really. I''m just trying to show some people that DirectX isn''t really that hard.




"We are the music makers, and we are the dreamers of the dreams."
- Willy Wonka
Thanks for the help. I will check it out.

Kevin =)
-----------------------------kevin@mayday-anime.comhttp://www.mayday-anime.com
quote:Original post by BitBlt

grasshoppa: there''s a tutorial right here on gamedev about using Direct3d for a 2d isometric, tile-based game. It would be really easy to change it to a different type of game.


Yup, I read that article, and I use it in my 2D tile engine. All you have to have is an array of polygons (I made my own little rectanglular polygon class to make it easy), set the textures of those to the tiles you wanna display, and render. Just set D3DRENDERSTATE_COLORKEYENABLE and it''ll use color keys just like normal. The only problem is if you use alpha blending without 3D acceleration, it''s incredibly slow. Like, 2 or 3 frames/sec with 2 layers of 32x32 tiles in 640x480x16 on a P3 450.
Oh, and if you wanna use alpha blending, read http://www.tasteofhoney.freeserve.co.uk/ddab.html (good for just learning how to make D3D do something too^_^)


-Deku-chan

DK Art (my site, which has little programming-related stuff on it, but you should go anyway^_^)

"I'm dropping like flies!" - me, playing Super Smash Bros. (and losing)
"What fun!" - me, playing Super Smash Bros. (and beating the crap out of somebody)
BitBlt,

I don't mean to single you out, but if you look at this code, and you are not familiar with DirectX it looks like latin:

lpDDSfront->Lock(NULL, &ddsd, DDLOCK_SURFACEMEMORYPTR DDLOCK_WAIT, NULL);
buffer = (USHORT*)ddsd.lpSurface;
buffer[rand()%640+((rand()%480)*ddsd.lPitch>>1)]=(USHORT)RGB(0,0,0);
lpDDSfront->Unlock(NULL);

I think what TheLabRat was saying is that without looking up a lot of stuff in the SDK how can you tell what DDLOCK_SURFACEMEMORYPTR is referring to - is it a ptr, is it a surface or what? lpDDSfront and lpDDSfront are really not the best names (descriptive) either.

Just as an example of how complex DirectX is, if you have ever seen 3dfx Glide (and I obviously am not stating that Glide is better, so don't turn this into an API war):

grGlideInit(); initialise the video card
grSstWinOpen(); open a Glide window
grClearBuffer(); clear the LFB
grDrawTriangle(); draw a triangle
grDrawLine(); draw a line
grSwapBuffer(); swap the front and back buffer
grGlideShutdown(); shutdown Glide

Compare grGlideInit() and grWinSStOpen() to the way you have to create a DirectDraw device, attach surfaces to the device (front and back), configure those surfaces, lock and unlock the surfaces, blt etc.. using that obscure code at the top of the screen, and it's no wonder newbie programmers give up! Of course, Glide only works on 3dfx cards, but that wasn't my point - there is a lot of stuff in DirectX that could be simplified, and a lot of stuff that should be encapsulated in single intelligible commands (because the programmer doesn't need to know about it). Give me initialise, open window, clear screen, draw, close window, shutdown anyday.

All hail TheLabRat and his words of wisdom.

Paulcoz.

Edited by - paulcoz on November 2, 2000 6:42:27 PM
I have to disagree, what part of that code is unclear. It''s standard C++, and the parameters are explained very clearly in the SDK
I say, stop complaining and go back to coding. There''s not much we can do except keep programming with the current set of Direct X stuff, learn to utilize the new features of the new Direct X, move to another API or write your own API.
As I explained, it's the amount of code that is required to do very simple things, and the intelligibility of the code that I object to.

The code is very unclear - as someone unfamiliar with DirectX I can understand the Lock and Unlock parts (as they relate to surfaces) but I couldn't tell you what the rest of the code does. I might also question why I should even have to learn that stuff about surfaces when another API does all of that for me, leaving me to concentrate on my own program content?

I think if we were both to write a program that draws a triangle on the screen, one using Glide (or perhaps OpenGL) and one with Direct3D and see which is shorter, mine would be around a page long, and yours would be two or three.

As you say, it's pointless to argue about APIs, but TheLabRat made a good point about the confusion created by MS for existing DX programmers. It is confusing enough as it is, trying to code without having to worry about the graphics API. Should the DirectDraw programmers keep coding with DX7 instructions and risk having their program become behind the times, or should they learn the DX8 Direct3D interface (dropping z) to get around the problem during this limbo-period when they know they will have to re-write it again with the DX9 2D interface later on.

Paulcoz.

Edited by - paulcoz on November 2, 2000 7:41:49 PM
Well i am not sure how true this is but that may all be a thing of the past with directx 8.

Rumour has it you can set the whole envornment up with just a few function calls.

I suppose we will have to wait and see
"Rumour has it you can set the whole envornment up with just a few function calls."

That would be a significant improvement.

I wonder if the people who think DirectX is fine just as it is, object to MS making it simpler to use. They might not like it so much, if they felt it made their programs look less complicated.

Paulcoz.

Edited by - paulcoz on November 2, 2000 10:47:50 PM

This topic is closed to new replies.

Advertisement