flat assembler
Message board for the users of flat assembler.

flat assembler > Examples and Tutorials > SWGPTG - 01

Author
Thread Post new topic Reply to topic
avcaballero



Joined: 02 Feb 2004
Posts: 163
Location: Madrid - Spain
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).
Image


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.


Description:
Download
Filename: SWGPTG.7z
Filesize: 57.9 KB
Downloaded: 28 Time(s)


_________________
Siempre aprendiendo


Last edited by avcaballero on 12 May 2018, 20:22; edited 1 time in total
Post 05 Apr 2018, 19:54
View user's profile Send private message Visit poster's website Reply with quote
avcaballero



Joined: 02 Feb 2004
Posts: 163
Location: Madrid - Spain
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.


Description:
Download
Filename: FilamentsWC01.zip
Filesize: 30.54 KB
Downloaded: 45 Time(s)


_________________
Siempre aprendiendo
Post 15 Apr 2018, 18:08
View user's profile Send private message Visit poster's website Reply with quote
macgub



Joined: 11 Jan 2006
Posts: 205
Location: Poland
Quote:
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.


Thanks for info. I will use CreateDIBSection, Earlier I was using VirtualAlloc for graphic buffer.
Post 24 Apr 2018, 07:24
View user's profile Send private message Visit poster's website Reply with quote
macgub



Joined: 11 Jan 2006
Posts: 205
Location: Poland
OK. Question: Will BitBlt work faster with mem allocated using CreateDIBSection than VirtualAlloc?
Post 24 Apr 2018, 07:50
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15870
Location: 162173 Ryugu
macgub wrote:
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.
Post 24 Apr 2018, 07:53
View user's profile Send private message Visit poster's website Reply with quote
avcaballero



Joined: 02 Feb 2004
Posts: 163
Location: Madrid - Spain
I have never did that prove, if you do it, please tell me the results. I am very interested.
Post 24 Apr 2018, 18:27
View user's profile Send private message Visit poster's website Reply with quote
macgub



Joined: 11 Jan 2006
Posts: 205
Location: Poland
Quote:
But, there isn't really any memory that works faster or slower, it is all just DRAM underneath.

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 Question
Post 25 Apr 2018, 07:10
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15870
Location: 162173 Ryugu
macgub wrote:
[Maybye CreateDIBSection allocates directly mem wich exist on graphic card Question
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.
Post 25 Apr 2018, 13:37
View user's profile Send private message Visit poster's website Reply with quote
donn



Joined: 05 Mar 2010
Posts: 105
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

Quote:
Since the aperture memory segment is addressable by the GPU, the GPU can accelerate these updates to the video memory surface. For example, text rendering, BitBlts, AlphaBlend, TransparentBlt, and StretchBlt are all accelerated in these cases.


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

Quote:
On Vista, GDI will always render on the CPU.
Post 25 Apr 2018, 18:38
View user's profile Send private message Reply with quote
macgub



Joined: 11 Jan 2006
Posts: 205
Location: Poland
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.
Post 30 Apr 2018, 06:47
View user's profile Send private message Visit poster's website Reply with quote
avcaballero



Joined: 02 Feb 2004
Posts: 163
Location: Madrid - Spain
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.


Description:
Download
Filename: RayCastingWC03.zip
Filesize: 32.49 KB
Downloaded: 33 Time(s)


_________________
Siempre aprendiendo
Post 05 May 2018, 17:36
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 2004-2018, Tomasz Grysztar.

Powered by rwasa.