[size=24px]Writing Games with DelphiX's DXDraw[/size]
[size=12px]by Armand Postma[/size]
CONTENTS
1. What is the DelphiX?
2. Using DelphiX
3. High Frequency Redrawing
4. Retrieving the screensize
5. Running fullscreen
6. Don't forget to Flip!
7. Drawing Images
7.1 Using the DXImageList
7.2 Drawing directly on the Surface
8. Transparency
8.1 Transparency with the DXImageList
8.2 Transparency when drawing directly on the Surface
9. Using the DXDraw Canvas
10. When an error is given on the Draw method?¢_¬¶
11. DelphiX Game Template!
12. Contact
[size=18px]1. What is the DelphiX?[/size]
DelphiX is a Delphi component collection that has been written by a man called Hiroyuki Hori. It enables programmers to conveniently use MS DirectX, because it works much easier and saves the time of writing it all from scratch. The latest DelphiX version has 13 components:
- TDXDraw: DirectDraw and Direct3D component.
- TDXDIB: Component by which DIB is maintained.
- TDXImageList: List of Tpicture. Surface is controlled.
- TDX3D: The Direct3D component (works with TDXDraw).
- TDXSound: DirectSound component.
- TDXWave: Component by which Wave is maintained.
- TDXWaveList: The list of Wave. The buffer is controlled.
- TDXInput: Input component. (Keyboard and Joystick).
- TDXPlay: Communication component.
- TDXSpriteEngine: Sprite engine.
- TDXTimer: High-speed timers (better than TTimer).
- TDXPaintBox: DIB version of TPaintBox.
- TDXForm: Optimizes forms for DelphiX.
Unfortunately, there hasn't been a DirectX 8 update for DelphiX. However, DelphiX is most commonly used by 2D game-programmers and DirectX 8 hasn't changed anything for 2D programmers and still provides the DirectX 7 Surface there is no problem for us!
[size=18px]2. Using DelphiX[/size]
DelphiX is a cool package and after installing it you see 12 cool new components (one is not visual) in your Delphi component-palette. When you examine the components you'll notice that there's a component for everything you ever want to do! However, in this tutorial I will only describe the use of 2 DelphiX components: TDXDraw and TDXImageList. The reason for this is quite simle. A few years ago I wrote my first game using DelphiX, a space invaders clone, and it looked very nice. I used the DXDraw component, the DXImageList and the DXSpriteEngine like all the demo files that are provided with DelphiX do. The problem was however that when the game ran for about 5 to 10 minutes the 2nd row of my aliens escaped of my screen and where never to be seen again, even thought I wrote a piece of code that moved all the aliens (every row) the same number of pixels to the left or to the right. However I made the SpriteEngine do the position calculations and things like that, so it screwed up. Since then I have decided that Delphi in combination with my knowledge of math (which is not THAT much) and my programming skills do all the thinking and I would let DelphiX worry about the drawing and ONLY about the drawing!
However if you need high-level sound handling (like two sounds at the same time), you could consider using the DXSound component, I have had no problems with that, but barely use it now a days. However I will only explain the drawing part of DelphiX in this tutorials.
I use DelphiX for the graphical parts of my game, because its one of the fastest drawing-surfaces out there (well there is also JEDI-SDL, which belongs to the fastest too). I use DelphiX when I write games that require too much graphical handling for the Windows Canvas, or when I write games that have to work fast on slower machines (P200, P400, etc.), because it really is a fast way of drawing stuff, even when you draw multiple layers!
Of course it would be nice if you would have the latest DelphiX version installed on your computer. It can be downloaded from Hori's page that can be found at: http://www.yks.ne.jp/~hori/ The installation procedure is very simple and is explained in the readme.txt file provided with the DelphiX zip-package. Another thing you need to have installed is Microsoft's DirectX 7 or higher, this doesn't have to be the DirectX SDK, because the runtime version works just as well.
Note. If you have an computer with more than 1.2 GHz running Win98 you could experience some compilation problems in Delphi (in my case it showed a message that an error occured in DDHELP.DLL). I haven't heard of a solution for this problem and found that the only solution is to switch either to Windows NT/2000 or to Windows XP.
If you have installed both DirectX 7 or higher and DelphiX you are ready to begin programming games using DelphiX!
[size=18px]3. High Frequency Redrawing[/size]
As you might, or might not know windows redraws its windows very frequently in an event called paint, which is a very good thing, it makes sure the window always looks as good as we want it to look. However when we draw an image upon the form and windows redraws the form our image is gone. For example when we draw an image on the form and then minimise the form and restore it to its original size, the image will be gone, because the paint event is called when the window state of a form is changed. The solution to this problem is easy, we redraw the screen as many times as possible, which will also help us to update the data on the screen often, so when a character moves this will be shown very fluently! For programmers who have had some experience in game-programming with DelphiX or DirectX this isn't very new, because you'll have to redraw a DirectX surface as many times as possible to keep seeing the image and to get fluent movements. So what we need is a loop that keeps refreshing our screen with a high frequency. There are three ways of accomplishing such a game loop without the use of DelphiX:
- By using a TTimer object with a low interval number
- By overriding the Paint event
- By using the Application.OnIdle event with done set to false
I do not like the use of the TTimer object when writing games, because its another component and components use memory and because I think its just not fast enough for the task at hand! Overriding the Paint event of the Form has the right speed and doesn't use extra memory. However I would never use it, because what it actually does is capture every WM_PAINT message that the application receives and this means that when you would place a nice button on your form it will not be visible. The WM_PAINT message that was going to tell the button to redraw has never arrived, because it was captured by the Paint event-override! The best way of assuring a high frequency update of your scene is by using the Application.OnIdle event, with done set to false. By using this method we will not use memory, because the event will be triggered anyway and it will not be in the way of normal operations, because this event is not used in any normal application! Using this method is very easy. All you have to do is declare a new event-handler (a procedure) in the forms private declaration like this:
[pascal]type
TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
procedure GameLoop(Sender: TObject; var Done: Boolean);
public
{ Public declarations }
end;
[/pascal]
Then you have to add a new procedure called TForm1.GameLoop to your unit like this:
[pascal]Procedure TForm1.GameLoop(Sender: TObject; var Done: Boolean);
Begin
Done := False;
// Game Stuff Goes here...
End;
[/pascal]
Finally we have to assign our event-handler to the Application.Idle event and this we immediately when the form is created. To do this, double-click on your form and Delphi will add the TForm1.OnCreate procedure to your unit. Add the following line to the procedure (between begin and end):
[pascal]Application.OnIdle := Form1.GameLoop;[/pascal]
Now we have assigned our event-handler to the OnIdle event, so every time an Idle-event occurs our GameLoop procedure will be called and due to the fact that we put Done := False in the procedure, the gameloop event will be infinite. The effect is the same as if we would create an endless loop with a while statement, but by using a while statement all the other events would be neglected and the application would get an overflow. By using the OnIdle event, we will get the same end-effect as with an endless while-loop, but the other events will still occur and we will not get an overflow!
[size=18px]4. Retrieving the screensize[/size]
Say you would like to have a tiled background, for example a wooden texture that looks like a table, and the tile you are going to use is 128x128 pixels, how many tiles do I need to draw until my entire screen is filled? This question can't be answered before we know the width and height of the screen. Well you could easily look into the display properties and find that your screen has a resolution of 1024x768 pixels, but when you give your game to a friend who has his resolution set to 800x600 your game would look pretty bad! So it's not that easy to know the width and height of your screen because it can vary from machine to machine, but luckily for us, its almost that easy to find out the resolution of our screen!
The Windows API has a build in function that will provide us with exactly the information we need! The function I'm talking about is GetSystemMetrics. To find out our resolution we will call it twice, one to find out the width of your screen and once to find out the height. Because this is essential information that could be needed immediately we place these calls in the OnCreate event of our form, so we will have access to the screensize-values immediately after the form has been created!
To do this we first have to declare 2 variables called VideoModeX and VideoModeY of the SmallInt data-type. I always declare them in the var section that can be found right above the word implementation, however if you wish to retrieve that screensize-values from other forms, you could declare the variables in the public declarations section of your form. After the variables have been declared the var section will look something like this:
[pascal]
var
Form1: TForm1;
VideoModeX, VideoModeY : SmallInt;
[/pascal]
When we then click on our form we will be brought back to our forms OnCreate event. After we have added the GetSystemMetrics function-calls to the procedure it will look as follows:
[pascal]procedureTForm1.FormCreate(Sender: TObject);
begin
// Retrieve the screensizes...
VideoModeX := GetSystemMetrics(SM_CXSCREEN);
VideoModeY := GetSystemMetrics(SM_CYSCREEN);
// Assign the Gameloop event-procedure to the Application.OnIdle event
Application.OnIdle := Form1.GameLoop;
End;
[/pascal]
Now we can find the answer easily if our VideoModeX is 1024 and our VideoModeY is 768 that we need to draw:
Horizontally: 1024 div 128 = 8 tiles to fill the screen.
Vertically: 768 div 128 = 6 tiles to fill the screen.
[size=18px]5. Running fullscreen[/size]
The DXDraw component has an option to run fullscreen, so we only have to set it to run our program fullscreen. This would be true if this option would work on every computer, unfortunately it doesn't. On some computers using the DXDraw fullscreen mode will cause the application move a lot to the bottom-right corner and so the application will only be visible partly and it still doesn't run fullscreen. However we can use a little trick to run fullscreen on every computer using DelphiX.
The screen size we have retrieved is the size of the entire screen, however our form doesn't cover the entire screen, but only a part of it. Of course we could maximize our form, but then our form still wouldn't have the same size as our screensize, because of the title-bar!
There is a small trick that is commonly used to make our form have the same dimensions as the screen-dimensions. We turn off the border of our form and then maximize it. This way we will get a form that covers the entire screen. We do this in our forms OnCreate event. So after adding the fullscreen mode to our OnCreate event-handler the event-handler will look like this:
[pascal]procedure TForm1.FormCreate(Sender: TObject);
begin
// Retrieve the screensizes...
VideoModeX := GetSystemMetrics(SM_CXSCREEN);
VideoModeY := GetSystemMetrics(SM_CYSCREEN);
Form1.BorderStyle := bsNone;
Form1.WindowState := wsMaximized;
// Assign the Gameloop event-procedure to the Application.OnIdle event
Application.OnIdle := Form1.GameLoop;
End;
[/pascal]
If you want to make sure that no other application runs on top of your form, you could add the following line to the event-handler, right after the Form1.WindowState := wsmaximized line:
[pascal]Form1.FormStyle := fsStayOnTop;[/pascal]
This line will tell windows that our form will always be on top, no matter what other applications are being started, we will be on top!
A problem that will occur because we removed the titlebar is that we won't be able to close our application. This can easily be solved by creating an event-procedure that handles key pressing and by closing the application when the ESCAPE key is pressed. This is done by selecting the Events tab in the Object Inspector and double clicking on the OnKeyDown event, this will create an OnKeyDown event-handler. All we have to do is add a few lines which handle the program-close-on-escape procedure. The OnKeyDown event-handler will look like this after the lines have been added:
[pascal]procedure TForm1.FormKeyDown(Sender: TObject; var Key: Word;
Shift: TShiftState);
begin { If the ESCAPE key has been pressed then close the program! }
If Key = VK_ESCAPE then
Begin
SendMessage(Handle, WM_CLOSE, 0, 0);
End;
end;
[/pascal]
Now all you have to do is press the ESCAPE key and the application will close itself!
[size=18px]6. Don't forget to Flip![/size]
If we would start drawing on the DXDraw surface we would still see nothing, because everything we would draw would end up in the back-buffer of DirectX. DirectX uses a technique called double-buffering to speed up drawing even more. Double buffering is the technical term for a drawing method that is often also referred to as "offscreen drawing". The name indicates that we do not draw on the screen, but somewhere else and that's exactly what double-buffering means! When we double-buffer we do not draw to the screen, but to our computers memory. Since a computer's memory is one of the fastest media available today, drawing to the memory will be a whole lot faster than drawing directly to the screen. So when we draw we actually draw into the computers memory. To make it visible on the screen we only have to call the DelphiX command Flip, which will "flip" the back-buffer to the screen and make it visible. So every time we have finished drawing our entire scene we flip. So to make it easy on ourself we just add the command DXDraw1.Flip to the Gameloop procedure. This makes our GameLoop look something like this:
[pascal]Procedure TForm1.GameLoop(Sender: TObject; var Done: Boolean);
Begin
Done := False;
// Game Stuff Goes here...
DXDraw1.Flip;
End;
[/pascal]
[size=18px]7. Drawing Images[/size]
If you have not placed a DXDraw component, this would be the moment to do so, because when we draw we have to have something to draw on! At this point we have to make a choice, because there are two ways to draw images to the surface of DXDraw:
Let DXImageList worry about the actual drawing.
Draw directly to the surface of DXDraw.
Normally the choice would be easy, because we would just choose the fastest method, but I do not believe that there is a noticeable difference between both methods. The downside of the first is that you have to use another component and have to fill it with images. The plus of using a DXImageList is that it stores its images inside the application and when compiled the images are compressed, so you get a bigger exe, but your total application will be smaller. The plus of the second is that you are totally in control and that it resembles drawing to the Windows Canvas. I prefer the second way, because I like total control when I am programming, but I will explain both methods to let you make your own choice!
7.1 Using the DXImageList
As said before it has a downside, but also a very important plus the application size! However when you write a dynamic application where the images can change without having to recompile the exe, the plus becomes a downside. However when you would need dynamic images it would still be possible to use the DXImageList, because you can also fill it during runtime!
Before we can begin using the DXImageList we have to add a DXImageList component to our form, so select it from the component palette and place it on the form. Then we will have to tell the DXImageList what surface it should use to draw upon. This surface will be our DXDraw component and to link the DXImageList to the DXDraw component we have to set the DXDraw property of the DXImageList in the object inspector. The easiest way to do this is to simply click two times on the property in the object inspector (make sure the DXImageList component is selected) and the name of our DXDraw component will appear, in my case it is called "DXDraw1". If this property is not set, you cannot draw to the surface, so everything you draw with the DXImageList component will just not be visible. Then we need images to draw of course. We can add them to our DXImageList by using the object inspector. Just double-click on the property Items and an edit window will appear.
In this window you can either add or remove images from the DXImageList. To add an image you have to click on the only available button in the entire window:
When you have clicked on it a new DXImageList item will appear in the white part of the edit window.. It is probably called "0 - TpictureCollectionItem" and when you click on it its properties will be visible in the object inspector. It has the look and feel of a VCL Timage object and works about the same way, so to select an image we just have to double-click on the picture property. Then you can put in a name for the image in the name property, but this is not required, because we will use numbers to select the images, like in an array. If you want to place another image you click on the same button as you did before and repeat the whole process until you are done adding pictures!
Okay, now your DXImageList is filled with images and we can start drawing. Say we want to draw our 1st image on position (15, 10) on the DXDraw surface we would simply add the following line to the GameLoop, before we flip the back-buffer to the screen (before the DXDraw1.Flip command):
[pascal]procedure DXImageList1.Items[0].Draw(DXDraw1.Surface, 15, 10, 0);[/pascal]
Allright, that looks impressive, but how does it work? Well its not that hard actually, the first part of the command specifies which image in the DXImageList we want to draw in our case the first (so number 0) so by specifying DXImageList1.Items[0] we select our first image then we tell the DXImageList we want to draw the image on something by using the command Draw. For the draw command to work, we must answer four questions:
1. Question: Where do I have to draw on? Answer: DXDraw1.Surface
2. Question: How many to the right should I draw (X coordinate)? Answer: 15 pixels
3. Question: How many to the bottom should I draw (Y coordinate)? Answer: 10 pixels
4. Question: What pattern do I have to draw? Answer: No Pattern (0)
The fourth question is not very important for us, so we just always answer it with 0. So when we put this all together you get the command line that looks like the one we specified above. And when we add it to our GameLoop, the gameloop will look as follows:
[pascal]Procedure TForm1.GameLoop(Sender: TObject; var Done: Boolean);
Begin
Done := False;
// Game Stuff Goes here...
DXImageList1.Items[0].Draw(DXDraw1.Surface, 15, 10, 0);
DXDraw1.Flip;
End;
[/pascal]
That's all there is to drawing to the DXDraw component when you use the DXImageList component. It may look a bit difficult at first, but once you get the hang of it, its quite easy!
7.2 Drawing directly on the Surface
A lot of people think this is much harder than using the DXImageList, but for those who read my Canvas Game Programming tutorial this method may actually look very easy, because it has a lot of similarities with the Canvas.Draw method and its not as long-winded as using the DXImageList.
However before we can start drawing we have to have something to draw. Normally we would load our into a Tbitmap object, but since DirectX doesn't support Bitmaps as a native-format we will have to use something else. DirectX's native image-format is called DDS (Direct Draw Surface) so we could of course make a TDirectDrawSurface object for each image we are going to need and give the object names like CarImage etc. This would work fine when we would be using two or three images, but in game programming we mostly use more images. In a case like this we create arrays of TDirectDrawSurface objects. This means that we will create a variable that can hold a whole pile of TDirectDrawSurface objects. I will call this variable GameGraphics. Say we need 5 images. In that case we would declare an Array that consists of 5 TDirectDrawSurface objects in the var section of our unit. If we would declare the array of 5 TDirectDrawSurface objects in our var section it will look something like this:
[pascal]var
Form1: TForm1;
VideoModeX, VideoModeY : SmallInt;
GameGraphics: Array[0..4] of TDirectDrawSurface;
[/pascal]
Now that we have declared our GameGraphics array, we will have to fill it with images, but before we can fill the TDirectDrawSurface objects with images, we first have to create the images (remember we only have reserved memory for the object). So the best thing to do would be to create a procedure to load the images from the harddrive into the memory. We declare this procedure in the public section of our form again and call it LoadGameGraphics. After we declared it our public section will look as follows:
[pascal]type
TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
procedure GameLoop(Sender: TObject; var Done: Boolean);
public
{ Public declarations }
procedure LoadGameGraphics;
end;
[/pascal]
After we have declared the LoadGameGraphics procedure we will have to write the actual procedure somewhere in our form. When we do so, the procedure will look like this:
[pascal]Procedure TForm1.LoadGameGraphics;
var D : Integer;
Begin
For D := 0 to 4 do
GameGraphics[D] := TDirectDrawSurface.Create(DXDraw1.DDraw);
GameGraphics[0].LoadFromFile(ExtractFilePath(ParamStr(0)) + 'image1.bmp');
GameGraphics[1].LoadFromFile(ExtractFilePath(ParamStr(0)) + 'image2.bmp');
GameGraphics[2].LoadFromFile(ExtractFilePath(ParamStr(0)) + 'image3.bmp');
GameGraphics[3].LoadFromFile(ExtractFilePath(ParamStr(0)) + 'image4.bmp');
GameGraphics[4].LoadFromFile(ExtractFilePath(ParamStr(0)) + 'image5.bmp');
End;
[/pascal]
This procedure first creates the TDirectDrawSurface images in a for loop and then loads the images from bitmaps that are in the same directory as the application is located. With the function-call ExtractFilePath(ParamStr(0)) we retrieve the directory where the application is located and then we add the filename of the image. Of course if you would use this procedure you have to place 5 images in the directory where the application is located and you would have to rename the files or change the name of the files in the LoadGameGraphics procedure to the names of your images. This is another great feature of using DelphiX, because we can load Bitmap images into DDS images exactly the same way as we would load an image into a Tbitmap object. To do this from scratch you would need a pretty big procedure! The only thing left is make a call to this procedure when the application starts So in our OnCreate event-handler. However this call can only be made when the DXDraw object is allready created and fully initialized, so before the call to the LoadGraphics procedure can be done we first have to make a call to the DXDraw.Initialize procedure to make sure the DXDraw component is fully initialized and created! After doing this our OnCreate event-handler will look like this:
[pascal]procedure TForm1.FormCreate(Sender: TObject);
begin
// Retrieve the screensizes...
VideoModeX := GetSystemMetrics(SM_CXSCREEN);
VideoModeY := GetSystemMetrics(SM_CYSCREEN);
// Resize the form so our game runs in fullscreen mode!
Form1.BorderStyle := bsNone;
Form1.WindowState := wsMaximized;
DXDraw1.Initialize;
LoadGameGraphics;
// Assign the Gameloop event-procedure to the Application.OnIdle event
Application.OnIdle := Form1.GameLoop;
End;
[/pascal]
Now that we have filled our GameGraphics array with DDS images we can start drawing them to the screen. Let's say I wanted to draw our first image to the surface at position (15, 10). To do this we simply add a line in our GameLoop before the Flip command. This line would look as follows:
[pascal]DXDraw1.Surface.Draw(15, 10, GameGraphics[0], False);[/pascal]
The first two values are to specify the x and y values of the top-left corner of our image so in our case that is X:15 and Y:10 then we specify which image to draw so we tell the command we want the first image drawn so we provide GameGraphics[0]. Finally the last part of this command is if we want the image drawn transparent, however I will come back on this subject later, but in this case we told the command not to draw transparent.
After adding this line to the GameLoop it will something like this:
[pascal]Procedure TForm1.GameLoop(Sender: TObject; var Done: Boolean);
Begin
Done := False;
// Game Stuff Goes here...
DXDraw1.Surface.Draw(15, 10, GameGraphics[0], False);
DXDraw1.Flip;
End;
[/pascal]
It's that easy! As you can see, not half so long-winded as the DXImageList and it must seem very familiar for people who have ever worked with the windows Canvas!
[size=18px]8. Transparency[/size]
A big problem in computer graphics is that a bitmap (or any other image format) is always a rectangle, while sometimes we want a disk, a triangle or another shape for our sprites. In game programming this problem is solved by using transparency.
In the image shown above, you see the same image twice. The image on the left does not use transparency and the image on the right uses transparency, which provides the effect that the spacecar stands on a grassy landscape much more realistic.
Transparency is done different in both methods, although the basic theory is the same. They both use a transparency colour to do transparency. In general we choose the colour Fuchsia for transparency, because it is almost never used in images.
8.1 Transparency with the DXImageList
Using transparency with the DXImageList is very easy, because you can do it entirely with the object inspector. Say you have added the car above to the DXImageList and its the first item in the list. Before we can do transparency we first have to select the item from the itemlist so the object inspector will show the properties of our item.
To do transparency with the colour fuchsia we have to set the TransparentColor property to clFuchsia and the Transparent property to True. Mostly DXImageList recognizes the transparent-colour automatically, however sometimes you have to do it manually and you always have to check it! When both these properties are set correctly you are ready to draw the image and when done so, the image will be drawn transparent.
8.2 Transparency when drawing directly on the Surface
This is a bit harder than using the DXImageList, because it is all done with code, however once you get the hang of this, it is much faster to do than using the DXImageList. Sometimes you can even use a for- or a while-loop and that will save you a lot of coding and therefore time!
To do transparency when drawing directly on the surface with the colour fuchsia we only need two lines of code. In the first line of code we specify the transparency-colour with the TransparentColour command, so when we would use the transparency-colour fuchsia on the first image of our GameGraphics array it would look something like this:
[pascal]GameGraphics[0].TransparentColor := clFuchsia;[/pascal]
This line can be both called before drawing or in the LoadGraphics procedure. Calling in the LoadGraphics procedure would be the best option because it is only called once and so it saves time and therefore speed! Remember however if you would call the command TransparentColor from the LoadGraphics procedure that you have to call it after the loading of the images otherwise it won't work!
Then we have to draw the image transparent to the screen. When using this method the draw-line will change slightly, because we have to specify that we want to draw transparent. To draw the image transparent to the screen, our draw-line will look like this:
[pascal]DXDraw1.Surface.Draw(15, 10, GameGraphics[0], True);[/pascal]
The only difference between the non-transparent drawing-line and the transparent one is the True value at the end. By specifying true we tell the Draw command to draw the image transparent using the transparent-colour we have specified before! Pretty easy isn't it?
[size=18px]9. Using the DXDraw Canvas[/size]
DXDraw, like many other visual Delphi components, features a Windows Canvas implementation. This enables us to draw lines, rectangles and pixels to the screen without the need of images. I will not go into the details on how to use this canvas, because it works exactly the same as the Windows Canvas and if you need any help using it, you can read my Canvas tutorial on this subject. However there is a tiny little difference between the normal Canvas and the DXDraw canvas, so I will discuss that difference in this tutorial.
The first thing I will have to explain is how to call the DXDraw canvas. The canvas is not directly a part of the DXDraw component, but more a part of the Surface, so to when we call the canvas it will look like DXDraw.Surface.Canvas followed by a canvas command like rectangle. To clearify I will show an example of how to draw a rectangle using the DXDraw canvas:
[pascal]DXDraw1.Surface.Canvas.Rectangle(50, 50, 100, 100);[/pascal]
This line will draw a rectangle from coordinate (50, 50) to (100, 100).
When we would just put this line in our GameLoop our entire rectangle wouldn't be visible and all the graphics drawn after the rectangle won't be visible either?¢_¬¶ This is the real difference I was talking about. The drawing itself is pretty much the same, however the use of the canvas is a special part of DXDraw and to show whatever we have drawn on the canvas and everything after that we have to release the canvas. It can be compared with flipping the back-buffer to the screen, only with the canvas it is called releasing. To do this we call the command Canvas.Release every time that we are finished drawing to the canvas. So when we only needed to draw the rectangle to the canvas our code would look something like this:
[pascal]DXDraw1.Surface.Canvas.Rectangle(50, 50, 100, 100);
DXDraw1.Surface.Canvas.Release;
[/pascal]
I have found that it is a good idea to release the canvas before we flip the back-buffer, every time in the GameLoop, so we can never forget it. However this solves some problems but not all of them, it can still happen that you draw something that you will not see on the screen when you have forgotten to release the canvas!
[size=18px]10. When an error is given on the Draw method?¢_¬¶[/size]
I noticed that older versions of Delphi (4 or lower) or older versions of DelphiX have some problems with the Draw method. This could be because there are two different Draw procedures or that older versions of DelphiX do not feature the draw method used in this tutorial. If the draw method doesn't work in your version, you can use the following procedure for drawing. You have to declare the procedure in the public declarations of your form so the public declarations will look like this:
[pascal]type
TForm1 = class(TForm)
DXDraw1: TDXDraw;
procedure FormCreate(Sender: TObject);
procedure FormKeyDown(Sender: TObject; var Key: Word;
Shift: TShiftState);
private
{ Private declarations }
procedure GameLoop(Sender: TObject; var Done: Boolean);
public
{ Public declarations }
procedure LoadGameGraphics;
Procedure DrawImage(X, Y : Integer; DDS : TDirectDrawSurface; Transparent : Boolean);
end;
[/pascal]
Then you can have to place the following procedure somewhere in your unit:
[pascal]Procedure TForm1.DrawImage(X, Y : Integer; DDS : TDirectDrawSurface; Transparent : Boolean);
var SourceRect : TRect;
Begin
SourceRect := Rect(0, 0, DDS.Width, DDS.Height);
DXDraw1.Surface.Draw(X, Y, SourceRect, DDS, Transparent);
End;
[/pascal]
Now you can use this procedure exactly the same way you would otherwise use DXDraw.Surface.Draw. So when we would draw the first image of our GameGraphics array non-transparent to the screen at (15, 10) then you would use the line:
[pascal]DrawImage(15, 10, GameGraphics[0], False);[/pascal]
And our gameloop would look like this:
[pascal]Procedure TForm1.GameLoop(Sender: TObject; var Done: Boolean);
Begin
Done := False;
// Game Stuff Goes here...
DrawImage(15, 10, GameGraphics[0], False); // not transparent
DrawImage(15, 10, GameGraphics[0], True); // transparent
DXDraw1.Flip;
End;
[/pascal]
[size=18px]11. DelphiX Game Template![/size]
I thought a working example of all the preparations that this tutorial features would come in handy while writing your games using DelphiX, so I have included a game template in this zip file. All the preparations that you need for high frequency drawing and the linking of the DXImageList with DXDraw are allready done for you in this Game Template. So it will save you time when you start a new game and it will help you to understand this tutorial! The game template consists of two versions, one is intended for use with the DXImageList and the other is intended for drawing directly to the surface!
>>> Click here to download the DelphiX Game Template <<<
[size=18px]12. Contact[/size]
If you find any mistakes in my tutorial or if you have any questions, ideas, comments or if you just want to say hello, please post a message in this thread!
Of course you can also send me an e-mail at lion.tiger@home.nl or visit
the Lion Productions website at http://lionprod.f2o.org/
I can also be found on the DelphiGames mailinglist (delphigames@yahoogroups.com)
and on the Delphi@Elists mailinglist (delphi@elists.org).
THE END
Copyright Ac 2002 Lion Productions
Bookmarks