This program will draw a bitmap right after it is loaded, but only once then the bitmap seems to destroy itself or the render target. Moving the drawbitmap function any where else doesn't work. Just draws a blank. Works fine in 32 bits....weird.
Are your structures if used appropriate for 64 bit? I only have 32 bit at the moment so I can't run the program.
I am sure it is something simple due to conversion maybe. Also, I am outside on my iPad so can't directly look at the source code just yet.
Thats always tough to do because theres really no 64 bit help files. So I'm always experimenting with the pesky structure types.
/Dx64Includes is missing :biggrin:
Quote from: BugCatcher on June 28, 2023, 01:57:27 AM
Thats always tough to do because theres really no 64 bit help files. So I'm always experimenting with the pesky structure types.
aha... possibly a good starting point for troubleshooting. When I get back inside, I'll take a looksee
QuoteThe system cannot find the path specified.
Assembling: screenbitmap.asm
Dx2Includes\d2d1.inc(3) : fatal error A1000:cannot open file : c:/Dx64Includes/D2DBaseTypes.inc
Microsoft (R) Incremental Linker Version 14.33.31629.0
Copyright (C) Microsoft Corporation. All rights reserved.
actually missing 2 includes
;--- include file created by h2incx v0.99.20 (copyright 2005-2009 japheth)
include D2DBaseTypes.inc
include dcommon.inc
I also corrected path for includes. Should not have drive letter
Okay, you updated the download...
do not put the path "Dx64Includes/D2DBaseTypes.inc" its already in the Dx64Includes directory:
include Dx64Includes/D2DBaseTypes.inc
include Dx64Includes/dcommon.inc
include D2DBaseTypes.inc
include dcommon.inc
the code though still has errors...
Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation. All rights reserved.
Assembling: screenbitmap.asm
screenbitmap.asm(107) : error A2022:instruction operands must be the same size
Microsoft (R) Incremental Linker Version 14.33.31629.0
Copyright (C) Microsoft Corporation. All rights reserved.
Okay I must have an old win64.inc I corrected MSG struct it was 'message DWORD'
MSG STRUCT STRUCT_ALIGN
hwnd HWND ?
message QWORD ?
wParam WPARAM ?
lParam LPARAM ?
time DWORD ?
pt POINT<>
MSG ENDS
I changed message to qword. It assembles but same result as yours.
We need a DX expert. Siekmanski... where art thou? I know exactly nothing about the api's involved
Sorry that I couldn't be more help. Only to watch the paths. Most of us here do not put the drive letter in the path. Also the include files that are already in the "Dx64Includes" folder do not need "Dx64Includes" in the path there
I thought this might be a simple conversion error. Seems not. I had reinstalled my copy of Win 10 64 bit to look at it. Unfortunately it (my masm64 install) has an old buggy win64.inc in the masm64 directory. my bad on that bit.
Siekmanski and a few others are pretty good with this stuff. My graphics knowledge is limited to gdi and just barely :tongue:
First, I've got the old version assembled, and indeed, some paths need to be fixed. Inter alia, it should be known by everybody in this forum that not all members place their masm32 or masm64 folders in C:
include c:\masm64\include64\masm64rt.inc is thus bad style.
Use include \masm64\include64\masm64rt.inc
Second, there are absolutely no error checks. I refuse to even look at this code.
Post your coinvoke macro, so that we can use it to check for errors.
Quote from: BugCatcher on June 28, 2023, 01:36:25 AM
Works fine in 32 bits....weird.
In 64 bits you can't use OFFSET to point things in
.data? section.
You must use
lea in coinvoke macro, or you can just put that structures in
.data section and must work:
.data
g_pDirect2dFactory LPID2D1FACTORY NULL
g_pIWICImagingFactory LPIWICIMAGINGFACTORY NULL
g_pRenderTarget LPID2D1RENDERTARGET NULL
;.data?
RTP D2D1_RENDER_TARGET_PROPERTIES <>
HRT D2D1_HWND_RENDER_TARGET_PROPERTIES <>
sizeRenderTarget D2D1_SIZE_F <>
Indead really strange behavior, work well from x64dbg but not from command or explorer :biggrin:
I used Hutch's loop:
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
msgloop proc
LOCAL msg :MSG
LOCAL pmsg :QWORD
mov pmsg, ptr$(msg) ; get the msg structure address
jmp gmsg ; jump directly to GetMessage()
mloop:
invoke TranslateMessage,pmsg
invoke DispatchMessage,pmsg
gmsg:
test rax, rv(GetMessage,pmsg,0,0,0) ; loop until GetMessage returns zero
jnz mloop
ret
msgloop endp
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
but no difference making:
mov eax,msg.message
This fails. Look for errcounter in the sources, especially in the coinvoke macro.
coinvoke g_pRenderTarget,ID2D1RenderTarget,DrawBitmap,\
g_pStartBitmap,\
offset dRect,\
Opacity,\
D2D1_BITMAP_INTERPOLATION_MODE_NEAREST_NEIGHBOR,\
NULL;offset sRect
Coinvoke is in the Dx2includes/Dx64MacroHelpers. I know the second one fails, thats why I put in there and thats the problem.
No, it's not the second one, it's the 17th coinvoke, as demonstrated by the code I posted above. I caught the bug for you, BugCatcher, now it's your turn.
Quote from: BugCatcher on June 28, 2023, 06:40:48 AM
I know the second one fails, thats why I put in there and thats the problem.
I think nothing fail :biggrin:
Using india.
jpg file only requiere just a little thing:
.case WM_PAINT
invoke LoadD2Resources,hWnd
invoke Render
Perhaps there is a bad factory converter setting using buttonatlas.
png (or very slow?).
Won't that create a memory leak?
Quote from: BugCatcher on June 28, 2023, 09:10:26 AM
Won't that create a memory leak?
:thumbsup: Yes there is a problem.
Sorry, folks, I had assumed that all coinvoke calls return S_OK if there is
no error - see below, Microsoft docs.
Apparently, that's not the case for D2D1; for example, ID2D1RenderTarget,GetSize returns 0000000140003824 in rax, but x=887, y=499 in the sizeRenderTarget. Btw no matching picture for these values, which are clearly floats and look plausible but I can't see the jpg or png file that matches these dimensions :rolleyes:
QuoteError Handling in COM (COM) (https://learn.microsoft.com/en-us/windows/win32/com/error-handling-in-com)
Almost all COM functions and interface methods return a value of the type HRESULT. The HRESULT (the name can be read as "result handle") is a way of returning a success, warning, or error value. A HRESULT is actually not a handle (see Why does HRESULT begin with H when it's not a handle to anything?); it's just a value with several fields encoded into it. As per the COM specification, a result of zero indicates success, and a nonzero result indicates failure.
Dx64MacroHelpers.inc, coinvoke with error checking:
coinvoke MACRO pInterface:REQ, Interface:REQ, Function:REQ, arg1,arg2,arg3,arg4,arg5,arg6,arg7,arg8,arg9,arg10
LOCAL istatement, lbl
...
istatement CATSTR <call qword ptr >,<(Interface PTR[rax]).&Interface>,<_>,<&Function>
mov rax, qword ptr [rcx]
istatement
test rax, rax
je lbl
mov _rcx, rcx ; define in .DATA?
mov _rdx, rdx
conout "CoInvoke fails in line ", str$(@Line)
conout chr$(13, 10)
mov rcx, _rcx
mov rdx, _rdx
xor eax, eax
ENDMThat returns this (line numbers might be slightly different with your code):
CoInvoke fails in line 228
CoInvoke fails in line 339
CoInvoke fails in line 341
CoInvoke fails in line 266
CoInvoke fails in line 367
CoInvoke fails in line 369
CoInvoke fails in line 385
CoInvoke fails in line 367
CoInvoke fails in line 369
CoInvoke fails in line 385So the error-checking coinvoke macro is more challenging. Instead of the
test rax, rax, there should be a more individual test that checks if rax returns the expected value.
Hi BugCatcher
In 64bit when calling Win APIs and COM you need to make shadow SPACE always and sometimes stack "argument" SPACE when
there are greater than 4 parameters. Remember COM has one extra "hidden" parameter.
You also need to keep the stack aligned to 16 bytes before calling APIs or COM, i.e rsp's address must always end with a "0" .
If you do not add the stack "argument" SPACE, you will be writing over any data in your locals, if you have any, when you use
the invoke or coinvoke macros.
Just look in your coinvoke macro
IFNB <arg10>
mov rax, arg10
mov qword ptr [rsp+50h], rax ; <- This WILL do damage without stack space
ENDIF
Worst-case you will overwrite your proc's return address placed on the stack - then you crash and burn.
===============================>
main proc
LOCAL wc :WNDCLASSEX
LOCAL lft :QWORD
LOCAL top :QWORD
LOCAL wid :QWORD
LOCAL hgt :QWORD
add rsp, -68h
and rsp, -10h
===============================>
msgloop proc
LOCAL msg :MSG
LOCAL pmsg :QWORD
add rsp, -28h
and rsp, -10h
===============================>
WndProc proc hWin:QWORD,uMsg:QWORD,wParam:QWORD,lParam:QWORD
mov hWin, rcx
mov uMsg, rdx
mov wParam, r8
mov lParam, r9
add rsp,-28h ; <- This wind proc ALWAYS comes in unaligned.
===============================>
D2D1Init proc hWin:HWND
.......
.code
add rsp, -68h
and rsp, -10h
mov hWin, rcx
invoke D2D1CreateFactory,\
===============================>
LoadD2Resources proc ;; hWin:HWND <- leave this out.
......
.code
push rbp
mov rbp, rsp
add rsp, -68h
and rsp, -10h
invoke LoadResourceBitmap,\
......
leave
ret
===============================>
LoadResourceBitmap proc pRenderTarget:ptr ID2D1RenderTarget,\
pIWICFactory :ptr IWICImagingFactory,\
resourceName:PCWSTR,\
resourceType:PCWSTR,\
destinationWidth:UINT,\
destinationHeight:UINT,\
ppBitmap:ptr ptr ID2D1Bitmap
..........
.code
mov pRenderTarget, rcx
mov pIWICFactory, rdx
mov resourceName, r8
mov resourceType, r9
add rsp, -68h
and rsp, -10h
invoke FindResource,hInstance,resourceName,resourceType
===============================>
Render proc
....
.code
push rbp
mov rbp, rsp
add rsp, -68h
and rsp, -10h
f2f dRect.left,FLT4(600.0)
......
leave
ret
===============================>