-------------------------------------------------- ----- Game Editor Frame Tutorial Unlike Willow ------------------------------------------------------------------------------------------------------------------------------- -----------------
I. Foreword: I have been looking for the combination of DX programming and MFC libraries, and I have put a picture from "Computer Programming Skills and Magazine" on the second life http //webking.com.cn / secondlife. . It should be said that that example is very good, the only shortcoming is that it only studies the full screen display, and for the map editor personnel, it is urgent to use the Frame of the original MFC to use the DX function. Things, this is also what I have been looking for, today (1999/12/4) finally found it.
It is a map editor that I have written for MUD, although there is no lack of function, but as a good job, the interface is too bad. There is no response action when the button is pressed, and it is not convenient to use All features of the MFC. After completing this map editor, other programmers' MFC editors are also murder, and their graphic display part is a problem. If you want to use a classic programming method to operate and display pictures of 256 colors, it is very troublesome. Can I make the MFC and DDRAW's window pattern perfectly? After completing the map editor, I already have such an idea, waiting for the machine to test it. As a result, it is completely feasible, and it is so simple!
Second, the first example:
In this example, I generated a standard single document window with the VC's AppWizard and saved. Then, add four DX members, a DDRAW pointer, a DDRAW4 pointer, a front buffer, one after the first buffer, one after which the DDRAW pointer is added to the header file of the view class CGAMEEDITVIEW. In the header file, two functions are added, one is the MSG function, used to display the message box, which is directly copied from someone else; the other is the initddrawsurface () function. Then add the function body of these two functions in CGAMEEDITVIEW.CPP. Msg has nothing to say, you can use it directly to use it. InIntDrawSurface You can also copy directly, and a DDRAW object is created in this function, and then it takes the interface of DDRAW4. Then create a DDSurface4 home screen buffer page with the DDRAW4 interface, which is responsible for displaying the content on the screen. Finally, create a background buffer page of DDSurface4, which is responsible for preparing a picture in the background before the main buffer is displayed on the screen. Only two functions are only.
There are two actions in the program, one is to perform initddrawsurface () initialize the DDRAW page while the Putch window is initialized. If you do not succeed, you will exit. Another action is to copy a rectangular area from the background buffer to the front buffer (also displayed on the screen) in OnDraw () of the view class. Since the background buffer is not placed in data, the displayed content will be random, generally black. The steps displayed can be read from the program comment on the source code, I generally write more fine.
Why don't you add a change of changes in hike? This is because I just want to tell you how a simple DDRAW window page is created and used. The following tutorial will slowly join how to read bitmap and display, time control, window area detection, cutting block, color keys Wait for content. When the tutorial is over, you should have a simple game with MFC and DDRAW should have no problem.
Download Source Code GameEdit1.zip
Third, the second example:
1. There is an obvious vulnerability in the last example, and the width and high are explicitly specified when creating a background buffer in initddrawsurface (). When creating the LPMAINSURFACE, there is no specified size, because it is not required, the front buffer is the range of the entire screen, which is used to display memory. The post-buffer is not displayed. It is actually in system memory (window mode cannot create a background page in display memory). In general, it should be set as large or greater before the buffer. The explicit specification of 1024 * 768 may be enough to the general display, but in case the user can use a larger resolution, it may cause errors. So the second example first modified the part of the background buffer in initddrawsurface (), and the current display of the current display resolution is obtained with the standard Windows function getDeivcecaps (of course, the number of color bits can be obtained). Then use the acquisition high and wide to create a background buffer, which ensures the same size as the resolution. Of course, this is not absolute insurance. In case the user has changed the resolution, it is still possible to cause errors, but we don't need to be responsible for that case, you can't think about it. 2, this time we have to read a picture, look very horrible, you seem to have to study the file structure of Bitmap. In fact, there is no need to be so complicated. For a general game and editor, you don't have to understand the details of those details. The two files used in the DX routine can be moved directly, they are DDUTIL.H. And DDUTIL.CPP, you can find them in most DX routines, then copy it to your program's folder, add these two files in the project, try to compile. Direct recompilation is unable to succeed, because the MFC program is a bit special, to make it can be used by MFC, and must be added to the two files mentioned above. "Stdafx.h". After using this statement, the MFC recognizes these two files and then can be used normally. Of course, if you want to use the function in the View class, you have to join the #include "ddutil.h" on the head of GameEditView.cpp. This is common sense, saying that these seem to be a bit, and in the source code, these steps are done and have an explanation.
3. Pass Step 2, I have been able to read into the BMP file at any time, and the specific reading is very simple because you can use the functions in ddutil.cpp. You can also modify the source code of this file or create a modified version if needed. As an example, I first add a DDSurface4 page pointer in GameEditView.h:
LPDIRECTDRAWSURFACE4 LPBITMAPBUFFER; // DirectDraw read bitmap page saved here
Another bitmap is read into this bitmap page in the pre-setup () function of GameEditView.cpp. After the read is successful, copy this temporary page to the background buffer. In this way, the background buffer has content. Compile a program, it will find that the black block in the upper left corner of the window has become this picture (a horse riding figure in UO), the code is as follows:
lpbitmapbuffer = ddloadbitmap (LPDD4, "Test.bmp", 200, 200); if (null == lpbitmapbuffer) // If there is no read success, exiting the program {msg ("Unloaded bitmap, demonstration unable to do"); exit -2);} // Read successfully Copy to the background buffer to lpBackBuffer-> Bltfast (0, 0, lpbitmapbuffer, "); you can see the bitmap specified in the code The file name is Test.BMP, so you also need a bitmap file for such a file name, attached to the source package below, if you want to change a file, but this file will be used to demonstrate an example .
The second example is finished, please download the source number GameEdit2.zip if necessary.
Third, combined with GDI:
There is no resource file in the source code of the above two examples, so please build your own simple MFC single document program in accordance with the method mentioned above, and replace the source file to compile your own file.
In the second example, a bitmap is read and displayed on the upper left corner of the window. This does not have any problems in the program, and the speed is still very fast. But if you run other programs simultaneously, or move the window to the edge of the screen, some abnormal phenomena will occur. If you move the window to the edge of the screen, a very rectangular error occurs when transferring from the background to the front desk, means that you try to transfer the page to the screen area, that is, the front buffer (before, before, before The screen size is the same). The result will not make your program as a machine, but this transmission will not be performed. In addition, when you cover this program window with the window of other programs and move the above window, this window can cause the bitmap to cover in another window area. This is a serious problem, this is not in writing when writing full-screen programs, because the screen is exclusively by your program, and when writing a window program, your program will display very bad.
To solve the above problem, a way is that when the program lost the focus, you prohibit the transfer of bitmaps from the back buffer to the front buffer, and then recover bitmap transfer when the focus is re-obtained. But sometimes this is not ideal, such as when you are in programs or games, simultaneously send ICQ information, although ICQ accounts for a small area, or it will cause your program to stop updating the screen, and if you are in the game It is very unfriendly when you are tense and you can intervene.
Another way is to combine with GDI, combined with GID leads to a small decline in image speed, but it will make your program very nature. In fact, the method is also very simple, just get the HDC of the background buffer, then use the HDC's Bitblt method to copy the background buffer to the window CDC, you can modify the BLTFAST in OONDRAW to:
HDC HDC;
LPBACKBUFFER-> GetDC (& HDC); // Get the background buffer HDC
:: Bitblt (PDC-> M_HDC, 0, 0, 100, 100, HDC, 0, 0, SrcCopy); // Transfer the background buffer to window DC
LPBACKBUFFER-> ReleaseDC (HDC); // Don't forget to release HDC after using it, otherwise it will be wrong
