Author |
Topic: GFXLIB (Read 2179 times) |
|
admin
Administrator
member is offline
Posts: 1145
|
 |
Re: GFXLIB
« Reply #23 on: Sep 11th, 2008, 08:44am » |
|
Quote:| http://www.bb4w-games.com/example35.zip |
|
Beautiful, as always.
If I move the window partially off the bottom of the screen and then back, a (one-pixel wide?) border around your graphics appears not to be repainted. Is that me or is it you?
Richard.
|
|
 Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender: 
Posts: 452
|
|
Re: GFXLIB
« Reply #24 on: Sep 11th, 2008, 08:55am » |
|
on Sep 11th, 2008, 08:44am, Richard Russell wrote:If I move the window partially off the bottom of the screen and then back, a (one-pixel wide?) border around your graphics appears not to be repainted. Is that me or is it you?
Richard. |
|
It's "fixing the window size" that causes this problem (which affects nearly all of my graphics programs).
Code:MODE 8 : OFF
REM. Fix window size
SYS "GetWindowLong", @hwnd%, -16 TO ws%
SYS "SetWindowLong", @hwnd%, -16, ws% AND NOT &50000
IIRC, you suggested a possible solution a few months ago, however it didn't work for me.
Regards,
David.
|
|
Logged
|
|
|
|
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
|
|
|
|
|
