Index
> Windows > Screen Buffer. |
| Author |
|
|
AsmGuru62 24 Aug 2011, 12:56
Without Windows experience - it will not be easy.
Windows API provides functions to work with double buffer imaging. In short, it goes like this: 1. You paint the window in response to WM_PAINT message. By processing the message (BeginPaint API) you get back the Device Context (HDC) to pain onto. 2. You create a second HDC (using CreateCompatibleDC API) - this is your memory buffer where you will draw your data pixels. 3. You create a bitmap object - using CreateCompatibleBitmap API. 4. You select the object created in #3 into object created in #2 using SelectObject API. 5. Perform ALL your drawing operation into object from #2 - in other words: paint into memory. 6. In one call to API BitBlt dump memory buffer into screen buffer. Source is your memory buffer from step #2 - destination is your HDC from step #1. 7. De-select your memory buffer (HBITMAP created in step #3) from your object created in step #2 8. Destroy objects created in #2 and #3 9. Call EndPaint to signal to Windows that drawing is over. If you are planning to do animation - it is better to create and select objects once to speed up the frame rate. I know - it sounds confusing, but as I said - without knowing Windows - it is not easy. I was planning to write a sample (a game), but never finished it. Also: Windows does not allow the direct access to screen memory, like in DOS games - unless you want to create your own driver - which is what DirectX is - it is a driver for Windows, but writing drivers is even more complex than my explanations. |
|||
24 Aug 2011, 12:56 |
|
|
f0dder 24 Aug 2011, 13:41
macgub: either go by the APIs (which would be DirectX for giving you the native lowest practical level of access), or you go write for an OS that gives you direct access.
The only way you'd be certain to get direct framebuffer address on Windows is writing a driver - but that's not something you'd want to do, for several reasons. Even if you ignore all the practical reasons, a pretty damn good one is performance... if you want any of that, you'll be using APIs and not even considering framebuffer access. |
|||
|
24 Aug 2011, 13:41 |
|
|
pabloreda 24 Aug 2011, 21:48
I use this code... work in many windows
http://code.google.com/p/reda4/source/browse/trunk/screenshot/framebuffer.asm with many fixes but without example in http://code.google.com/p/reda4/source/browse/trunk/r4asm/r4fasm.asm I hope this help |
|||
|
24 Aug 2011, 21:48 |
|
|
macgub 26 Aug 2011, 07:52
Thanks guys for your replies. I will try understand code that Pabloreda gave links.
|
|||
|
26 Aug 2011, 07:52 |
|
|
rain_storm 13 Sep 2011, 02:49
Here's what I use, there are a lot of corners cut here, but who cares it works and it is easy to understand.
Code: const int resx = 640; const int resy = 480; int pixel[resx*resy]; int main(void) { static PIXELFORMATDESCRIPTOR pfd = { sizeof(PIXELFORMATDESCRIPTOR),1,PFD_DRAW_TO_WINDOW|PFD_SUPPORT_GDI|PFD_DOUBLEBUFFER,PFD_TYPE_RGBA,0x20,0,0,0,0,0,0,0,0,0,0,0,0,0,0x10,0,0,PFD_MAIN_PLANE,0,0,0,0 }; static BITMAPINFO bmi = { sizeof(BITMAPINFOHEADER),resx,-resy,1,32 }; static MSG msg; static HWND hwnd; static HDC hdc; int screenx = GetSystemMetrics(SM_CXSCREEN); int screeny = GetSystemMetrics(SM_CYSCREEN); if (!(hwnd = CreateWindowEx(0,"edit",0,WS_POPUP|WS_MAXIMIZE|WS_VISIBLE,0,0,0,0,0,0,0,0))) return 0; if (!(hdc = GetDC(hwnd))) return 0; if (!SetPixelFormat(hdc, ChoosePixelFormat(hdc, &pfd), &pfd)) return 0; ShowCursor(FALSE); do { PeekMessage(&msg,0,0,0,PM_REMOVE); StretchDIBits(hdc,0,0,screenx,screeny,0,0,resx,resy,pixel,&bmi,0,SRCCOPY); SwapBuffers(hdc); } while (msg.message != WM_KEYDOWN); ReleaseDC(hwnd, hdc); DestroyWindow(hwnd); return 0; } |
|||
|
13 Sep 2011, 02:49 |
|
|
pabloreda 22 Sep 2011, 14:23
Thank's rain_storm for sharing, I try to test your code, mine have tearing (because I not use double buffer), perhaps you code work better, Im interesting in the speed too.
I try to make the same framework for win64, linux32 and 64 and others OS too, if anyone have a code for doing this please post...fasm better |
|||
|
22 Sep 2011, 14:23 |
|
|
macgub 27 Sep 2011, 07:39
Quote: ... if anyone have a code for doing this please post...fasm better I agree with Pabloreda. If someone could translate this code to fasm, will be great...And maybye not only main procedure, but whole program. It's only reqest... [/b] |
|||
|
27 Sep 2011, 07:39 |
|
|
bitRAKE 27 Sep 2011, 08:09
I've got several examples on the board already:
http://board.flatassembler.net/topic.php?t=8289 win32 & win64 http://board.flatassembler.net/topic.php?p=118955#118955 timer/thread ...there are others, too. |
|||
|
27 Sep 2011, 08:09 |
|
|
pabloreda 27 Sep 2011, 12:31
t hanks bitRAKE
the first have, hilbertW.asm and hilbertw64 and the second plot.thread0.asm. nobody work in asm in Linux? |
|||
|
27 Sep 2011, 12:31 |
|
|
bitRAKE 27 Sep 2011, 16:09
From what I've read it appears OpenGL support on Linux is quite good. So, it might be easiest to work with a single API across all platforms. Of course, such simple Windows applications would work through WINE, afaik. Note: I have almost no Linux programming experience. Is OpenGL required to access frame buffer?
|
|||
|
27 Sep 2011, 16:09 |
|
|
bitshifter 27 Sep 2011, 23:31
Its hard (or maybe impossible) to get to framebuffer with hardware GL.
Maybe with X11 software implementation it is possible? |
|||
|
27 Sep 2011, 23:31 |
|
< Last Thread | Next Thread > |
Forum Rules:
|