Author |
Topic: GFXLIB (Read 2180 times) |
|
admin
Administrator
member is offline
Posts: 1145
|
 |
Re: GFXLIB
« Reply #25 on: Sep 12th, 2008, 09:39am » |
|
Quote:IIRC, you suggested a possible solution a few months ago, however it didn't work for me.
|
|
Hmm, it should work. Whenever you change the window style in a way which might change the size of the border, you should force a redraw of the border:
Code:
MODE 8 : OFF
REM. Fix window size
SYS "GetWindowLong", @hwnd%, -16 TO ws%
SYS "SetWindowLong", @hwnd%, -16, ws% AND NOT &50000
SYS "SetWindowPos", @hwnd%, 0, 0, 0, 0, 0, 32+7
If it doesn't work please let me know rather than grumbling to yourself that I've given you duff gen!
Richard.
|
|
 Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender: 
Posts: 452
|
|
Re: GFXLIB
« Reply #26 on: Sep 12th, 2008, 12:34pm » |
|
on Sep 12th, 2008, 09:39am, Richard Russell wrote:
But it doesn't!
Try this (most of the code taken straight from the Wiki):
Code: MODE 8 : OFF
REM. Fix window size
SYS "GetWindowLong", @hwnd%, -16 TO ws%
SYS "SetWindowLong", @hwnd%, -16, ws% AND NOT &50000
SYS "SetWindowPos", @hwnd%, 0, 0, 0, 0, 0, 32+7
DIM BITMAPINFOHEADER{Size%, Width%, Height%, Planes{l&,h&}, BitCount{l&,h&}, \
\ Compression%, SizeImage%, XPelsPerMeter%, YPelsPerMeter%, \
\ ClrUsed%, ClrImportant%}
DIM bmi{Header{} = BITMAPINFOHEADER{}, Palette%(255)}
bmi.Header.Size% = DIM(BITMAPINFOHEADER{})
bmi.Header.Width% = @vdu%!208
bmi.Header.Height% = @vdu%!212
bmi.Header.Planes.l& = 1
bmi.Header.BitCount.l& = 32
SYS "CreateDIBSection", @memhdc%, bmi{}, 0, ^bits%, 0, 0 TO hbitmap%
IF hbitmap% = 0 ERROR 100, "Couldn't create DIBSection"
SYS "SelectObject", @memhdc%, hbitmap% TO oldhbm%
SYS "DeleteObject", oldhbm%
CLS
*REFRESH OFF
REPEAT
CLS
SYS "InvalidateRect", @hwnd%, 0, 0
*REFRESH
UNTIL INKEY(1)=0
Upon closing or dragging a background window, or often moving the program window around (and especially when much of it disappears off the screen), I get two extraneous borders (two pixels in width) on the right and bottom edges of the window.
Even if SetWindowPos is placed after the CLS command, I still get the said borders.
Regards,
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #27 on: Sep 12th, 2008, 5:55pm » |
|
Quote:
Oh yes it does! The code I listed correctly changes the window size, but it doesn't update @vdu%!208 and @vdu%!212 because you've forgotten the VDU 26. You must always have a VDU 26 somewhere between changing the window size and using those variables otherwise they will reflect the size *before* you changed the style.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #28 on: Sep 12th, 2008, 7:13pm » |
|
on Sep 12th, 2008, 5:55pm, Richard Russell wrote:Oh yes it does! The code I listed correctly changes the window size, but it doesn't update @vdu%!208 and @vdu%!212 because you've forgotten the VDU 26. You must always have a VDU 26 somewhere between changing the window size and using those variables otherwise they will reflect the size *before* you changed the style.
|
|
Richard 1, David 0.
Yes, VDU 26 does indeed do the trick.
Thanks! I'm really pleased that I can now fix a problem that affects most of my programs.
David.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #29 on: Sep 13th, 2008, 02:08am » |
|
Code: MODE 8 : OFF
REM. Fix window size
SYS "GetWindowLong", @hwnd%, -16 TO ws%
SYS "SetWindowLong", @hwnd%, -16, ws% AND NOT &50000
SYS "SetWindowPos", @hwnd%, 0, 0, 0, 0, 0, 32+7
VDU 26
Actually, I don't really want the dimensions of the window to change (namely because it breaks one or two of my GFXLIB routines which either expect a 640x512 DIB section/bitmap buffer, or require the window width to be divisible by 4). The window is initially 640 by 512 pixels; after applying the SetWindowPos, VDU 26, it becomes 642 by 514.
I take it the '32' component of the flags parameter is SWP_FRAMECHANGED, I'm not sure where the +7 comes from.
Whilst it fixes the problem, I'd rather it did so without altering the window dimensions.
Regards,
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #30 on: Sep 13th, 2008, 08:53am » |
|
Quote:| I take it the '32' component of the flags parameter is SWP_FRAMECHANGED, I'm not sure where the +7 comes from. |
|
The 7 is SWP_NOSIZE + SWP_NOMOVE + SWP_NOZORDER.
Quote:| Actually, I don't really want the dimensions of the window to change |
|
In that case you're going about things in the wrong order. You need to change the window style before the MODE 8:
Code:
SYS "GetWindowLong", @hwnd%, -16 TO ws%
SYS "SetWindowLong", @hwnd%, -16, ws% AND NOT &50000
SYS "SetWindowPos", @hwnd%, 0, 0, 0, 0, 0, 32+7
MODE 8 : OFF
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB (clipped scaling)
« Reply #31 on: Sep 18th, 2008, 4:48pm » |
|
Just finished translating the BASIC version of my new bitmap scaler (with edge clipping when required), and it's significantly faster than my previous attempt (as seen in Spacerocks). Two demos:
http://www.bb4w-games.com/example39.zip
http://www.bb4w-games.com/example40.zip
Example 39 shows real-time scaling of the ubiquitous ball bitmap, and Example 40 shows full-window scaling plus 'darkening' via GFXLIB_MMXSubtract64.
When I say it's faster than my previous attempt, the new bitmap scaling routine (GFXLIB_PlotScale) is still not as fast as it could be -- and probably slow compared to what an expert coder could achieve. I have a faster method of doing it (prototype version still in BASIC), but whilst it clips correctly (and without memory leaks) at the screen edges, whole scaled pixels just 'pop-off' at the left and bottom edges of the viewport rather than just slide off smoothly. I know why this is, it's just I don't know how to fix it (tried plotting right-to-left, or top-to-bottom -- didn't work).
One more note: as usual with my example programs, I get near-perfect VBlank synchronisation on my laptop with it's mediocre integrated graphics, and this leads to beautifully slick, fluid animation. However, on my P4-based desktop, with its supposedly superior graphics hardware, I'm almost never able to get decent synchronisation, and usually it's quite terrible. Very annoying!
Regards,
David.
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB (yet another 'example')
« Reply #32 on: Sep 21st, 2008, 10:05pm » |
|
http://www.bb4w-games.com/example41.zip
The point of this is to demonstrate one of a dozen-or-so new GFXLIB routines; in this case, GFXLIB_PlotScaleColourBlend.
There'll be a dedicated (albeit very incomplete) GFXLIB website up by the end of this month.
David.
|
|
|
|
81RED
Guest
|
|
Re: GFXLIB (yet another 'example')
« Reply #33 on: Sep 25th, 2008, 07:03am » |
|
on Sep 21st, 2008, 10:05pm, David Williams wrote:http://www.bb4w-games.com/example41.zip
The point of this is to demonstrate one of a dozen-or-so new GFXLIB routines; in this case, GFXLIB_PlotScaleColourBlend.
There'll be a dedicated (albeit very incomplete) GFXLIB website up by the end of this month.
David. |
|
Looks great as always, and that font looks strangely familiar. 
Simon
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB (yet another 'example')
« Reply #34 on: Sep 25th, 2008, 07:13am » |
|
on Sep 25th, 2008, 07:03am, Simon Mathiassen wrote:Looks great as always, and that font looks strangely familiar.
Simon |
|
I like that font 
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #35 on: Sep 25th, 2008, 08:34am » |
|
Quote:| There'll be a dedicated (albeit very incomplete) GFXLIB website up by the end of this month. |
|
Can I encourage you to write up your library (or at least provide a link to your own site) in the 'Third Party Libraries' section of the BB4W Wiki: http://bb4w.wikispaces.com/Libraries
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #36 on: Sep 25th, 2008, 12:50pm » |
|
on Sep 25th, 2008, 08:34am, Richard Russell wrote:Can I encourage you to write up your library (or at least provide a link to your own site) in the 'Third Party Libraries' section of the BB4W Wiki: http://bb4w.wikispaces.com/Libraries
Richard.
|
|
No encouragement is necessary -- I intend to do just as you suggested.
One potential issue that may be cause for grumbles, is the size of the library: it's currently 872Kb, and will probably be around 2Mb by the time I've finished. Having said that, there's a lot of repeated code segments outside time-critical sections across many of the routines, so some space can be saved there. If I were to re-write GFXLIB, I would have the user INSTALL the 'core library' (comprising a couple of essential common routines), and then the user could CALL library components as required, viz.
REM. Install core library
INSTALL @lib$ + "GFXLIB"
PROCInitGfxLib
REM. Install required library routines
CALL @lib$ + "gfxlib\plot"
CALL @lib$ + "gfxlib\plotscale"
CALL @lib$ + "gfxlib\boxblur3x3"
CALL @lib$ + "gfxlib\alphablend"
And so on.
Regards,
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #37 on: Sep 25th, 2008, 5:07pm » |
|
Quote:| One potential issue that may be cause for grumbles, is the size of the library: it's currently 872Kb |
|
I assume much of that is assembler source code. If there's little or no BASIC code how about converting the library into a DLL, which (containing only machine code) ought to be substantially smaller?
Given that (I believe) you already use a 'SYS' interface to your routines - rather than CALL for example - conversion to a DLL should be made easier.
The only area where you might perhaps have problems is the use of 'global' (i.e. BASIC) variables which would have to be reworked for a DLL that doesn't share the same address space.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #38 on: Sep 26th, 2008, 7:12pm » |
|
on Sep 25th, 2008, 5:07pm, Richard Russell wrote:I assume much of that is assembler source code. If there's little or no BASIC code how about converting the library into a DLL, which (containing only machine code) ought to be substantially smaller?
Given that (I believe) you already use a 'SYS' interface to your routines - rather than CALL for example - conversion to a DLL should be made easier.
The only area where you might perhaps have problems is the use of 'global' (i.e. BASIC) variables which would have to be reworked for a DLL that doesn't share the same address space.
Richard. |
|
When I started writing GFXLIB, I set up a jump table of routine addresses at the beginning of the code, then I *SAVEd the assembled code. When I *LOADed the code into memory and tried to execute one of the routines, it didn't work. I can't remember the reason for this, I think it was due to the addresses of the global variables changing, or maybe jumps were jumping to incorrect addresses. This version of GFXLIB employs relatively few global variables -- it relies on a single large variables block (varsblk). I'll have another crack at it at some point, but, really, it'll have to wait until I'm motivated to undertake the considerable work involved in making it work.
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #39 on: Sep 27th, 2008, 09:12am » |
|
Quote:| I *SAVEd the assembled code. When I *LOADed the code into memory and tried to execute one of the routines, it didn't work |
|
It's jolly difficult to write 'position independent' code for the x86 CPU family, and the overheads involved would adversely affect performance anyway. That's why you really need a relocatable object format (such as a DLL or other PE-file) in which all the cross-references and jump destinations are automatically adjusted by the loader.
Richard.
|
|
Logged
|
|
|
|
|
