flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Windows > How to display an image? (gdi ddb dpi)

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
vivik



Joined: 29 Oct 2016
Posts: 186
How to display an image? (gdi ddb dpi)
I want to display an image.

I'm confused by device dependent bitmap and device independent bitmap.
https://msdn.microsoft.com/en-us/library/dd183382(v=vs.85).aspx

I'm confused by dpi avareness.
https://blogs.windows.com/buildingapps/2017/05/19/improving-high-dpi-experience-gdi-based-desktop-apps/
>When used in multi-monitor configuration, off-screen content will not be updated when the application window is moved between displays with different DPIs.

I'm confused by SetProcessDPIAware.
https://stackoverflow.com/questions/11066255/dpi-awareness-is-really-needed
https://msdn.microsoft.com/en-us/library/ms701681

My goal is a simple tga viewer, and just learning to do gui on windows in general.
Post 27 Aug 2017, 15:02
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
https://msdn.microsoft.com/en-us/library/windows/desktop/dd144877(v=vs.85).aspx
GetDeviceCaps
LOGPIXELSX
>In a system with multiple display monitors, this value is the same for all monitors.
What do they mean? How to get dpi for current monitor then?

Also, if app is displayed on two monitors simultaniously (half on one monitor, half on another), does window receive two WM_PAINT? Because there should be a way to adapt, if two monitors have different dpi.
Post 27 Aug 2017, 15:46
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua
I'm not sure about the DPI stuff, but device dependent bitmaps and device independent bitmaps are basically about the internal representation of the bitmap in memory. For device dependent bitmaps the in-memory store matches the device capabilities (limited colour depth etc.). For device independent bitmaps the in-memory store is an ideal representation of the image (full colour depth etc.) and is converted to match the output device capabilities (the screen, or the printer, or whatever) when you "paint" it to the output (the device).
Post 27 Aug 2017, 15:53
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
Are DDB always represented as RGB or RGBA internally? I guess they can be monochrome for printers, but I don't think monochrome monitors is a thing anymore.
Post 27 Aug 2017, 16:10
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua

vivik wrote:
Are DDB always represented as RGB or RGBA internally? I guess they can be monochrome for printers, but I don't think monochrome monitors is a thing anymore.

No, they supposedly match the target device capabilities. So it might be RGB-6-5-6, or perhaps grey-scale, or maybe something else. In theory it could be anything, but in practice I'd expect that Windows makes certain "optimisations" that reduce the coding requirements.
Post 27 Aug 2017, 16:16
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
If target device is a monitor, shouldn't "device dependent" bitmap be the same or almost the same for most of modern monitors?
Post 27 Aug 2017, 16:21
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua

vivik wrote:
If target device is a monitor, shouldn't "device dependent" bitmap be the same or almost the same for most of modern monitors?

There is no guarantee. Some low cost LCDs only support 6-bit depth and Windows might take advantage of that. You should not rely on it to always be of one particular type.

Just use DIB like everyone else. They are usually easier to deal with and Windows knows how to use the GPU and/or hardware acceleration to convert it if it is needed when painting.
Post 27 Aug 2017, 16:32
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
As it looks like now, to display a tga, I have to first inpack it into DIB, and then from that create DDB. Why can't I unpack to DDB directly. Can't really find what kind of format DDB will have.
Post 27 Aug 2017, 16:34
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua
A DDB format is unknown until you run the code on a particular device. So for example you won't know what format you need for a printer device until you create a context and interact with the device driver.
Post 27 Aug 2017, 16:38
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
I don't care about printers atm, I'm asking about monitors.

Maybe I should learn DirectWrite. To just display an image, yeah.
Post 27 Aug 2017, 16:41
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua
It's the same for monitors though, a DDB format for a monitor is also unknown until you have the context and work with it.
Post 27 Aug 2017, 16:44
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
Hm, okay. Thanks for info. Time to write code then. I'll bump this thread when I'll get stuck.

It's probably possible to get DDB format once at startup, implement a speedy unpacking for the most likely variant, and also implement a fallback to the standard way if something is weird. I'll google it.
Post 27 Aug 2017, 16:54
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua
Unless you are expecting to convert thousands of images per second then I wonder if using the "standard" DIB is the way to go. In theory using DDBs means you need to write so many different variants of converters to match all the possible hardware formats that the code overhead it crazy. Using DIB will take advantage of the device drivers inbuilt rapid conversion to the actual output format, and using DDB means you would basically be duplicating this code yourself, but doing it with the CPU instead of the hardware silicon.
Post 27 Aug 2017, 17:04
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
I said I'd implement only two: the most common and the standard (os provided) one.

Strange how CreateDIBitmap creates DDB. Shouldn't it be called CreateDDBitmap?
Post 28 Aug 2017, 05:19
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
https://msdn.microsoft.com/en-us/library/dd183371(v=vs.85).aspx
BITMAP
WORD bmPlanes;
The count of color planes.
What the hell are planes? Each rgb BITMAP is three bitmaps following each other?
Post 28 Aug 2017, 05:35
View user's profile Send private message Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 88
Location: Russian Federation, Sochi
planes for bitmap(DIB,DDB) can have only value 1 (default), or value 0 (mean that OS ignore it and OS will think here is 1 by default).

_________________
I don`t like to refer by "you" to one person.
My soul requires acronim "thou" instead.
Post 28 Aug 2017, 06:59
View user's profile Send private message Send e-mail Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
About "writing directly to DDB". It looks like windows just wouldn't give me access to that, no way to get a pointer to raw data. https://stackoverflow.com/questions/14207618/get-bytes-from-hbitmap , "if bitmap is not created by CreateDIBSection bitmap.bmBit pointer will be null". Plus I looked inside a real world gdi game, it just used DIB and BitBlt.

When do I need to use DDB then? I guess it's like uploading image to GPU, you can do that if you rarely change it? It's probably safe to forget it's existance.

I just launched elona recently, it got some fancy effects in the main menu, like "cicles on water". Obliviously no gpu here. I wonder how to do this, I guess the same DIB and BitBlt.

http://www.herdsoft.com/ti/davincie/imex3izm.htm
Post 03 Sep 2017, 21:12
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx

"Per monitor–DPI aware applications are a new class of applications in Windows 8.1."

okay, so I can ignore that for now, good
Post 04 Sep 2017, 06:52
View user's profile Send private message Reply with quote
pabloreda



Joined: 24 Jan 2007
Posts: 78
Location: Argentina
I use this ruttines for display graphics in win,

https://github.com/phreda4/reda4/tree/master/r4asm

r4fasm.asm is window mode
r4fasmfull is full screen
r4fasm64.asm is for 64bit mode, not well tested
Post 04 Sep 2017, 11:23
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
@pabloreda

In this piece of code from r4fasm2.asm, there are multiple .fin labels. How does it know to jump to a correct one?


Code:
SYSFFIRST; ( "path" -- fdd )
        push ebx ecx edx edi esi
        mov esi,_dir
.bcpy:
        mov bl,[eax]
        or bl,bl
        jz .ends
        mov byte[esi],bl
        add eax,1
        add esi,1
        jmp .bcpy
.ends:
        mov dword [esi],$002A2f2f
        invoke FindFirstFile,_dir,fdd
        mov [hfind],eax
        cmp eax,INVALID_HANDLE_VALUE
        je .nin
        mov eax,fdd
        jmp .fin
.nin:
        xor eax,eax
.fin:
        pop esi edi edx ecx ebx
        ret

;===============================================
SYSFNEXT; ( -- fdd/0)
        lea esi,[esi-4]
        mov [esi], eax
        push ebx ecx edx edi esi
        invoke FindNextFile,[hfind],fdd
        or eax,eax
        jz .nin
        mov eax,fdd
        jmp .fin
.nin:
        invoke FindClose,[hfind]
        xor eax,eax
.fin:
        pop esi edi edx ecx ebx
        ret

Post 05 Sep 2017, 06:35
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< 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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.