I'm releasing an alpha version of what I'm playing with (GDI library), if anyone wants to offer suggestions or help and I follow up with it, I'll put your name or screen name into the credits.? I ran my example with Memproof and found no memory leaks.

An executable example and bitmap are zipped here:
http://www.drarem.ms11.net/code/WLmemTest.zip

It runs some basic tests with the memory it allocates/copies to, displaying text boxes.
It also opens the bitmap and blits it to the main screen - since double-buffering is employed, if there were moving entities on the screen,
there would be no flickering.


The library is located here:
http://www.drarem.ms11.net/code/WankerGDI_A10.zip

To use it in your own program, all you need to do is this:
? ?include ..
? ?include ..\WLmem\WLmem.Inc
? ?
? ?includelib ..
? ?includelib ..\WLmem\WLmem.lib


Here is the initial documentation:
http://www.drarem.ms11.net/code/wankerlib.html


Please give me your thoughts or concerns. Thank you.

The source for the above example is posted below:

.586
.model flat,stdcall
option casemap:none

? ?include windows.inc
? ?include user32.inc
? ?include kernel32.inc
? ?include ..\WLmem\WLmem.Inc
? ?
? ?includelib user32.lib
? ?includelib kernel32.lib
? ?includelib ..\WLmem\WLmem.lib

WinMain proto :DWORD,:DWORD,:DWORD,:DWORD

.const
BCKGND equ 1

.data
? ?ClassName db "MainWinClass",0
? ?AppName? db "Main Window",0
testtext db "This is a test of the hardcoded junk ....? "
db "and so is this and so is this and so is thi"
db "s.. Inspired by the beauty of HDTV, XBRITE.",0
lpOut? db "? ? ? ? ? ? ? ? ? ?",0
lpFmt? db "%c"

.data?
? ?hInstance HINSTANCE ?
? ?CommandLine LPSTR ?
ohwnd dd ?
? ?stringtest dd ?
.code


; ---------------------------------------------------------------------------


start:
invoke GetModuleHandle, NULL
mov? ? hInstance,eax

invoke GetCommandLine
mov? ? CommandLine,eax

invoke WinMain, hInstance,NULL,CommandLine, SW_SHOWDEFAULT
invoke ExitProcess,eax

WinMain proc hInst:HINSTANCE,hPrevInst:HINSTANCE,CmdLine:LPSTR,CmdShow:DWORD
LOCAL wc:WNDCLASSEX
LOCAL msg:MSG
LOCAL hwnd:HWND
LOCAL arx:DWORD

mov? ?wc.cbSize,SIZEOF WNDCLASSEX
mov? ?wc.style, CS_HREDRAW or CS_VREDRAW
mov? ?wc.lpfnWndProc, OFFSET WndProc
mov? ?wc.cbClsExtra,NULL
mov? ?wc.cbWndExtra,NULL
push? hInstance
pop? ?wc.hInstance
mov? ?wc.hbrBackground,COLOR_BTNFACE+1
mov? ?wc.lpszMenuName,NULL
mov? ?wc.lpszClassName,OFFSET ClassName

invoke LoadIcon,NULL,IDI_APPLICATION
mov? ?wc.hIcon,eax
mov? ?wc.hIconSm,eax

invoke LoadCursor,NULL,IDC_ARROW
mov? ?wc.hCursor,eax

invoke RegisterClassEx, addr wc
INVOKE CreateWindowEx,NULL,ADDR ClassName,ADDR AppName,\
? ? ? ? ? ?WS_OVERLAPPEDWINDOW,CW_USEDEFAULT,\
? ? ? ? ? ?CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,NULL,NULL,\
? ? ? ? ? ?hInst,NULL
mov? ?hwnd,eax
mov? ohwnd,eax
invoke ShowWindow, hwnd,SW_SHOWNORMAL
invoke UpdateWindow, hwnd
mov arx,0

NEW stringtest, 128000
invoke lstrcpy, stringtest, addr testtext
invoke MessageBox,NULL, stringtest, NULL, MB_OK

;TESTING AS FOLLOWS:
;? stringtest is a dword pointer
;? testtext is a byte array (string of text)
;? after each READ, the dword pointer is incremented - preserve eax as needed
;? after each WRITE, the dword pointer is incremented

RESTORE stringtest
READ arx,byte
READ arx,byte

RESTORE stringtest
xor ecx,ecx
mov ecx,65
loopa:
mov arx,ebx
WRITE cl,byte
add ecx,1
cmp ecx,91
jb loopa

READ arx,byte
? ? READ arx,byte
? ? READ arx,byte
? ? READ arx,byte
? ? READ arx,byte
? ? READ arx,byte
? ? READ arx,byte
? ?
? ? WRITE 66,byte
RESTORE stringtest
READ arx,byte
? ? READ arx,byte
? ? READ arx,byte
? ? READ arx,byte
? ? READ arx,byte
READ arx,byte
READ arx,byte
READ arx,byte

invoke wsprintf,addr lpOut, addr lpFmt, arx
invoke MessageBox,NULL,addr lpOut, NULL, MB_OK

invoke MessageBox,NULL, stringtest, NULL, MB_OK

.WHILE TRUE
invoke GetMessage, ADDR msg,NULL,0,0
.BREAK .IF (!eax)
invoke TranslateMessage, ADDR msg
invoke DispatchMessage, ADDR msg
.ENDW

invoke cleanup
FREE stringtest

mov? ? ?eax,msg.wParam
ret
WinMain endp

WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
LOCAL hdc:DWORD
LOCAL ps:PAINTSTRUCT

.IF uMsg==WM_DESTROY
invoke PostQuitMessage,NULL
invoke DestroyWindow,ohwnd
.ELSEIF uMsg==WM_CREATE

invoke BackBuffer,hWnd,800,600,1,1
invoke LoadBANK,CTEXT("test.bmp"),BCKGND,800,600,0

.elseif uMsg==WM_PAINT
invoke BeginPaint,hWnd, ADDR ps
mov? ? hdc,eax
invoke blit,BCKGND,0,0,800,600,0,0,800,600
invoke flip
invoke EndPaint,hWnd, ADDR ps
.ELSE
invoke DefWindowProc,hWnd,uMsg,wParam,lParam
ret
.ENDIF

xor eax,eax
ret
WndProc endp


end start

Posted on 2005-06-24 16:30:42 by drarem
Why the childish name, wouldn't a more descriptive one have been better .
Posted on 2005-06-24 17:22:12 by Eóin
I have the brain of a child. Really it is for lack of a better one, I'll change the name unless you want to name it. Should have thought it out.
Posted on 2005-06-24 17:44:44 by drarem
Right now there's nothing unique or even close to useful in WL :| . With the banking feature it gets close to useful - but trust me, banking is less than 2% of any GUI code we GUI coders write. In x86, I use primarily 1024x300 bitmaps, with dozens to hundreds of sprites. These sprites can never be completely algorithmically positioned, otherwise we lose lots of memory for empty (useless) pixels.
I always do
invoke Blt,destX,destY,Wid,Hei,srcX,srcY,SourceBitmap ; DestBitmap is pre-set
or I can pre-set SourceBitmap, too.

Well, I could give some (or lots of) advice on making a graphics library (I have 2 years of commercial experience in it), but all my apps that need a graphics engine have literally thousands of "child elements": buttons, knobs, triggers, special-drawn... So, only a few might find my advice useful/interesting ^^" .

I've concentrated on DirectDraw (in the x86 field that is) - since GDI proves extremely slow even on good PCs (but with bad nVidia drivers) - and my apps need 30fps full-update ^^.

Ah, and btw the FREE/.. macros ... slow, taking too much i-memory, garbling registers (actually, not preserving them) - put separate procs for malloc/free that don't call GetProcessHeap everytime. Preserving the registers saves coders from typing and later debugging a lot!
The RESTORE macro is utterly useless - it takes less time to type  "mov eax,var1", and the code is much more readable.

As for bitmaps - a compression is best to use (jpg/gif/png). But, the buttons and smaller images should never be jpeg - or the GUI will look awful. I downsample my images to 565 (16-bit), and then compress them. LZSS by Haruhiko Okumura (patent-free) is very good. But for simple GDI stuff, gif/png is better (though loading time of apps increases).

I can be useful if you tell what your target software is (where WL can/should be used).
Posted on 2005-07-08 18:13:19 by Ultrano
Thank you for your honest and useful feedback.

Yes the next release would include the sprites - I am stalled trying to write a decent skinner.

One point I tend to disagree with is the garbling of registers - I've learned long ago not to trust the win32api's as they garble the registers also. Why add to the confusion and/or difficulty of coding as to preserve them?  I always save my registers before any function call which isn't mine. When I come to code it again later like in five months, what documentation do I have to say it's safe to spit in the wind?

The target is myself and other newcomers who wish to run before they walk.  It will primarily be for myself to code simple games or remakes.  When I go code something else, it will be reusable and I won't have to start from ground zero. If someone else finds it useful then great.

I do need help with the memory. I found I had to do a call to GetProcessHeap everytime to allocate each block of memory and again to release it, but if I am wrong please let me know.

Posted on 2005-07-15 09:57:08 by drarem
hahahahhahaha WankerLib its golden
Posted on 2005-07-15 10:52:50 by comrade