Click to See Complete Forum and Search --> : DD/DX shouldn't be this slow...
git
Apr 9th, 2001, 02:58 AM
Hiyas,
I've just converted a tile game over to Direct X/Draw because I'm sick of BitBlt's poor speed when dealing with transparent images. =) I've just got one of MS's DX8 SDK examples and modified it.
However, the main dx blt loop is VERY very slow (and I have a Duron 800!)... I'm getting a poor FPS rate, when I shouldn't be, because all I'm doing is setting the source/target x/y's, and calling the blt function. What could be wrong with it? I've attached the source code.
I've found that the problem lays somewhere within "For ZArray = 1 To Tactical.ZLevel" and "Next ZArray".
I still haven't got a proper map working (I've switched from pure isometric, back to 2D tiles with an isometric perspective), so it may look a little odd...but all I'm concerned about is the performance!
Just a note that I didn't include the background bmp, as it was too large, so the background won't be cleared for each blt loop.
By the way, how do I make the transparent colour purple, instead of black?
Thanks. =)
-Git
PsychoMark
Apr 9th, 2001, 03:51 AM
Changing the transparant color is easy, but it gets a little tricky when you're dealing with 16 bit instead of 32 bit.
There's a sample at www.vbexplorer.com/directx4vb/ which shows you how to do it, the exact address is: http://64.23.12.52/tutorials/DD_16bitColour.htm (this sample is for DX7, but I think it could be converted to DX8)...
I didn't look at the code yet, but if you're using DX8, you might want to consider stepping back to DX7, since it supports DirectDraw which makes 2D easier...
git
Apr 9th, 2001, 07:36 AM
Cool, I'll check that link out in a sec...
Yeah, I use DX8. I heard DX7 was easier to use with DD, but I couldn't really find any examples using DX7 (on Planet Source Code), and I can't find a link to the MSDX7SDK for VB...
From what I can see, it's maybe slow because I'm using Blt, instead of BltFast...how can I fix this?
-Git
PsychoMark
Apr 9th, 2001, 07:41 AM
The DirectX4VB link I gave you in my last post has a good set of tutorials for DX7...
The DX7SDK is not available from Microsoft anymore (I think), but I'm sure it's available somewhere. At least the DirectX7 Type Library should be included with DX8, so unless you need the samples (which by the way are crap compared to the DirectX4VB site, at least that's my opinion) you don't need the DX7SDK at all...
I can't help you out if you're using DX8, sorry, I'm still using DX7 :)
Btw, BltFast is a little faster as far as I know, but it shouldn't be that much difference...
PsychoMark
Apr 9th, 2001, 07:45 AM
I just opened the game in VB and noticed that you did use DX7, in that case: help is on it's way ;)
PsychoMark
Apr 9th, 2001, 07:51 AM
Changed to BltFast, wasn't speeding it up either...
Why aren't you using Fullscreen mode? I know my video card can't handle windowed mode very well, and so do most video cards I think, so it's probably (probably? I'm sure it is! :D) much faster in fullscreen.
git
Apr 10th, 2001, 01:57 AM
I'm using windowed mode because it's a lot easier to write code while the program is running... I'll have an option to switch later though.
I just changed it so it's fullscreen, no change...this is driving me nuts...
-Git
PsychoMark
Apr 10th, 2001, 02:03 AM
When you changed to fullscreen mode, did you replace the DXPicture picturebox with a back/front buffer method?
git
Apr 10th, 2001, 02:21 AM
Nope... how do I do that ? I'll take a look at some SDK examples and see if I can figure it out.
git
Apr 10th, 2001, 02:28 AM
Just checked it out. I think I'm using a front/back buffer, but also a picture box...
The speed problem appears to be with the blitting for each tile (which doesn't even use a pic box), not with bliting the backbuffer to the screen.
PsychoMark
Apr 10th, 2001, 02:29 AM
http://64.23.12.52/Tutorials/DD_FullScreen.htm
This shows you fullscreen DirectDraw...
Basically, you remove the Picturebox (and the Clipper object) and put an extra surface in it instead, which is used for the front buffer. Everything is drawn to the backbuffer exactly like you did before, but instead of blitting it to the front buffer (or a picturebox), you're calling Flip, which moves all data in the backbuffer to the front. Flipping is much faster than blitting, and done directly by the video card...
git
Apr 10th, 2001, 03:10 AM
Ok, I've implemented the flip... but now I don't have a rtemp RECT. So, how do I tell the function where to blit onto the surface, and the source surface and x/y co-ords? This is what I have so far, but I'm so new to DD/DX I dunno what to do...
HorBlit = (XArray - 1 - Tactical.XOffset) * 20
VerBlit = ((YArray - Tactical.YOffset) * 10) - 50
rBack.Left = (Map(XPos, YPos, ZArray).Tile - 1) * 20
rBack.Right = Map(XPos, YPos, ZArray).Tile * 20
'rtemp.Left = HorBlit
'rtemp.Top = VerBlit
'rtemp.Right = rtemp.Left + 20
'rtemp.Bottom = rtemp.Top + 50
ddrval = BackBuffer.BltFast(HorBlit, VerBlit, MainSurf, rBack, DDBLTFAST_WAIT)
Thanks,
-Git
git
Apr 10th, 2001, 03:13 AM
Btw, the speed problem is solved, but it's just blitting an utter mess of graphics...
PsychoMark
Apr 10th, 2001, 03:16 AM
Well, since you've got the speed, it's just a matter of some maths and blitting tiles. If you don't know how to use DD, I suggest looking trough the tutorials at http://www.vbexplorer.com/directx4vb/ (the DX7 tutorials), since they provide a lot of info...
git
Apr 10th, 2001, 04:40 AM
I've tried to fix this up, but it just isn't displaying the tiles correctly. I thorougly compared a tile engine example form the link you sent me with my code, and I can't see any difference in the DX code.
Does anyone know what's wrong here? Here's the source code again.
Thanks,
-Git
PsychoMark
Apr 10th, 2001, 06:39 AM
Checking now...
PsychoMark
Apr 10th, 2001, 06:40 AM
EXE? No way... sorry, I'm not going to open that, I can't fix anything anyways like this...
git
Apr 10th, 2001, 07:01 AM
Oops, sorry, I sent the wrong zip from another directory (same name zip, completely different contents...).
This is the right one, with source, no EXE. =)
PsychoMark
Apr 10th, 2001, 07:21 AM
Ok, no problem, downloaded the new one...
First of all, at this to the end of your DXLoop sub (declare rScreen As RECT at the top):
With rScreen
.Left = 0
.Top = 0
.Right = 640
.Bottom = 480
End With
BackBuffer.BltColorFill rScreen, 0
This will clear the whole backbuffer so the flickering goes away...
Also, remove the Flip from the DXLoop sub, and add it here:
Do While BRunning
DXLoop
DXBlit
Primary.Flip Nothing, DDFLIP_WAIT
DoEvents
Loop
This is because you only want to flip after everything has been drawn, the way you did it it's called before everything has been drawn...
So that removes the ugly graphics a bit, although the tiles still look messed up. I think that problem is in the calculations you are doing to get the tile's rectangle. I don't know exactly what it is though...
Also: if you try to blit a rectangle which does not fit on the screen (even for a pixel), DD won't draw it. The clipper object doesn't work in fullscreen mode, so you'll have to write your own. For example, if your tile is 50x50, and it's X and Y coordinates are 635, 100 (which is 5 pixels off the screen), set the source rectangle's right value to 50 - (640 - 635) = 45 pixels, that way DD will draw it...
Good luck!
git
Apr 10th, 2001, 07:42 AM
Sweeeeeeet, just fixed it...two problems I fixed:
1. In the sub which initialises the surfaces, the width/height for the surface for the tiles hadn't been set to the correct dimensions of the BMP.
2. I hadn't properly enabled transparencies (hence the lack of colour).
Works now at a very nice FPS - I think I need to slow it down. :D
Thank you very much for all your help. =)
-Git
PsychoMark
Apr 10th, 2001, 07:51 AM
You're welcome...
About the slowing down, don't slow down the FPS by using something like Sleep, instead, use the GetTickCount API to determine the number of milliseconds elapsed since the last frame and work out the moving speed according to that, so whatever FPS one might have, it'll always move for example 300 pixels per second...
vbforums.com
Copyright Internet.com Inc., All Rights Reserved.