SWGPTG - Small Windows Graphics Programming Tutorial with GDI

Hello, I have decided to post a small tutorial on the programming of graphics with GDI, which is in fact a subset of my Windows Graphics Tutorial with GDI. I'll drop a new post here every weekend (or so) until you/I get tired (that will be soon), as well as here (when I have time) and there. It has two quizzes to exercise us, which we will review in the next weekend (or so).

The size of the client area will be 640x400, which meets the golden ratio of proportionality: 1.6.

You can make use of what you find interesting here with the logical constraints: plagiarism is not allowed and reference is required if you use it.

Surely, many of you who are reading this have already programmed graphics in MS-DOS, probably in 13H mode. The programming of graphics for Windows with GDI is not very different.

PD. Excuse me if any mistake. I did it all in a hurry.


1.- We need a canvas where to paint on

In MS-DOS we wrote at the segment:address A000:0000, now we can not do that, but we will write on the hDC (display device context) that gives us the BeginPaint function that we will place inside the WM_PAINT section / message. However this is very very slow, because it has many different options to deal with. If we paint point to point the wait can be eternalized. To avoid this great inconvenience we will use a data buffer that we will send at once, which is almost immediate.

The data buffer we will create will be a bitmap that we will send to the hDC with a BitBlt or StretchBlt function. We will use the last one. For the creation of the bitmap we will use the function CreateDIBSection, which returns a pointer to the bit values of the created bitmap. This pointer is very important because it is the one that will allow us to write in it very quickly.

Writing to our DIB buffer can be done manually or through GDI functions, such as SetPixel. Contrary to what many people say, SetPixel is not particularly slow in itself, as I demonstrated some time ago here. The writing on the hDC is what is slow. Although, of course, we will always use what gives us the fastest writing speed.

In summary, we could identify the address A000:0000 of MS-DOS with the hDC of WM_PAINT, to which to access effectively we will need an intermediate data buffer with DIB format.


2.- Template

To finish this first post I will attach the templates of several compilers. If they are compiled and executed they will simply show a window populated by a default color. It is not advisable to eat your head on how this file is structured, you just have to take into account the following procedures within the code:

* Inicio. Here you will include the code that you want to run only once at the application starting. It is called within WM_CREATE. For example to initialize certain variables, etc.
* PintaObjeto. Here you will include the code that you want to run every time the pre-established time is met. I've put it every 20 milliseconds. It is the code that will renew what appears in our window. It runs inside WM_PAINT.

It would be interesting to stop at the following points:
* To paint in our DIB bitmap we will use the variable pMainDIB, which is the pointer that directs it. To this address we will pass the desired color of the point that has the format AARRGGBB, each one are byte-size, where AA (alpha) = 0 the rest are from 0 to 0xFF. This means that the size of the point to paint is dword, so to move to the next point we will have to increase our pointer in 4 bytes. The pointer starts at the upper left corner and increases to the right, when it ends with the length of the line we will see appear at the first point on the left of the line below.
* The background color of our main window, set in the WNDCLASSEX structure, must be 0, which indicates that it has no color, otherwise you will get flickering on the screen.
* The capture of the WinMain procedure messages is done with GetMessage instead of PeekMessage because the latter generates an unnecessary increase in work in most cases, as shown here.
* When we set the dimension of the window, it is not the client area, which will be lower, so if we want it for this we will have to do some extra accounts, although given that the window is resizable, it may not be worth it .


3.- Quiz 1
Make a small program that draws a gradient of colors (by your own).



4.- Quiz 2
Free theme to upload note.

EDITED: added the templates 32 and 64 bits for GoAsm and NasmX and a little 64 bits demo for NasmX and the same with a tune in the background made with Fasm/ufmod 32 bits in the root.

Hello. A tinyc demo here. Only with GDI, 960x600 size. A nice tune in the background. Would be nice if somebody check it out and tell me how it runs in its system.

Thanks for info. I will use CreateDIBSection, Earlier I was using VirtualAlloc for graphic buffer.

OK. Question: Will BitBlt work faster with mem allocated using CreateDIBSection than VirtualAlloc?

"faster"? I guess you could test it and time the results. But, there isn't really any memory that works faster or slower, it is all just DRAM underneath.

I have never did that prove, if you do it, please tell me the results. I am very interested.

Former times there was something like VRAM - video mem, faster than DRAM. Or even SRAM - static mem faster than DRAM. I dont know if this kind of RAM exist now. Maybye CreateDIBSection allocates directly mem wich exist on graphic card

It would seem to be inconsistent. DIB sections are independent of the device. If it was a DDB then perhaps, but there is still the problem of moving the data from the CPU memory to the GPU/VGA memory.

Seems like a good article, think I first found it a couple months ago: https://msdn.microsoft.com/en-us/library/windows/desktop/ff729480(v=vs.85).aspx



Haven't read through the entire article in detail yet though. Also, functionality seems to vary by OS:

I tried measure both functions using rdtsc instruction, but I don't know it is reliable enought. Rejecting extreme I got similar results, but I am not sure. So revolution seems to be right.

A tiny raycaster with a tune in the background. The brick walls and the grass floor are generated on the fly which saves a lot of size. 62 kb uncompressed in total.

I have to improve the grass floor and generate more textures.

Edited: added new textures and a cloudy sky instead of a closed ceiling.