Author |
Topic: GFXLIB (Read 2227 times) |
|
admin
Administrator
member is offline
Posts: 1145
|
 |
Re: GFXLIB
« Reply #17 on: Sep 10th, 2008, 09:14am » |
|
Quote:| Now having a Blast.exe that "explodes" into 29 additional items on said desktop Is not the ideal way to make friends |
|
I suggested that you "package the resource files into the executable", not that you 'explode' 29 items onto the desktop. One doesn't follow from the other!
For a start, I would always recommend putting the resource files into a single sub-directory, not keeping them in the same directory as the executable. Thus if one were to download the executable to the desktop and run it there the most that would happen is that a single additional folder icon would appear.
Arguably the appearance of that icon isn't in itself a bad thing, since it would draw attention to what is in any case bad practice - putting an executable file on the desktop. However it could easily be removed by setting the resource directory's attributes to 'hidden' early in your program.
But what I think is more important is that David's method of embedding all the resource files means that you don't have to (explicitly) download the programs at all. To run one of his programs I just 'open' it from the web site - the downloading and extraction of resource files to a temporary directory happens 'behind the scenes'. Literally his programs are four mouse-clicks away from a message on this forum.
Anyway it's ultimately up to you. I've marvelled at David's programs but I've not even looked at yours because I can't be bothered with the hassle of downloading, extracting and subsequently deleting it.
Richard.
|
|
 Logged
|
|
|
|
81RED
Guest
|
|
Re: GFXLIB
« Reply #18 on: Sep 10th, 2008, 10:37am » |
|
Quote:| I suggested that you "package the resource files into the executable", not that you 'explode' 29 items onto the desktop. One doesn't follow from the other! |
|
Admittedly, no. But, with the danger of repeating myself, there will always be a risk when you unpack something without the users consent or control.
Quote:| For a start, I would always recommend putting the resource files into a single sub-directory, not keeping them in the same directory as the executable. Thus if one were to download the executable to the desktop and run it there the most that would happen is that a single additional folder icon would appear. |
|
The files in the Blast.zip contains *two* files in the root of the archive - a Blast.exe and a readme. The rest is in a \data folder.
Quote:| Arguably the appearance of that icon isn't in itself a bad thing, since it would draw attention to what is in any case bad practice - putting an executable file on the desktop. However it could easily be removed by setting the resource directory's attributes to 'hidden' early in your program. |
|
Hang on a moment, did you just suggest that I clutter the users harddrive, only to hide it afterwards? I sincerely hope I read that paragraph wrong..
Quote:| But what I think is more important is that David's method of embedding all the resource files means that you don't have to (explicitly) download the programs at all. To run one of his programs I just 'open' it from the web site - the downloading and extraction of resource files to a temporary directory happens 'behind the scenes'. Literally his programs are four mouse-clicks away from a message on this forum. |
|
May I suggest WinRAR. It makes running anything inside a zip file equally simple to what you describe above.
Be warned though - WinRAR requires that you actually install it.
Quote:| Anyway it's ultimately up to you. I've marvelled at David's programs but I've not even looked at yours because I can't be bothered with the hassle of downloading, extracting and subsequently deleting it. |
|
Hmm.. I'm still glad I could "be bothered" to download a certain compiler, run the installer, click "next" an amount of times, enter a serial number, click "next" a few more times etc. so that I could produce Blast in the first place.
That you cannot "be bothered" to unzip my game is just something I will have to live with.
Simon
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #19 on: Sep 10th, 2008, 2:42pm » |
|
Quote:| The files in the Blast.zip contains *two* files in the root of the archive - a Blast.exe and a readme. The rest is in a \data folder. |
|
So where do those 29 items on the desktop come from when you embed them? I would have expected there to be just two (in addition to the executable): a folder icon and a readme icon.
Quote:Hang on a moment, did you just suggest that I clutter the users harddrive, only to hide it afterwards? I sincerely hope I read that paragraph wrong..
|
|
What's wrong with that? Loads of applications install 'hidden' files, and as for cluttering the user's hard drive you can simply delete the folder when your program exits. Another solution is to store your resource files in a subdirectory of @lib$, in which case they are deleted automatically on exit.
Quote:| I'm still glad I could "be bothered" to download a certain compiler, run the installer, click "next" an amount of times, enter a serial number, click "next" a few more times etc. so that I could produce Blast in the first place. |
|
I don't see that it's a valid comparison. If you develop your game into a fully-fledged application that needs to be 'installed' then of course I'd have no objection to carrying out those steps. I'd still encourage you to use a proper installer (so that again I can just 'run' the program from a web page) rather than require me to download it and extract the files manually.
I'm puzzled at your negative reaction to what was intended to be a practical suggestion to improve the user-friendliness of your software. It's a strength of BBC BASIC for Windows that you can embed resource files in the executable, and being able just to 'run' a program from a website or forum message seems to me a useful feature, so long as it is used appropriately.
|
|
Logged
|
|
|
|
81RED
Guest
|
|
Re: GFXLIB
« Reply #20 on: Sep 10th, 2008, 4:48pm » |
|
on Sep 10th, 2008, 2:42pm, Richard Russell wrote:I'm puzzled at your negative reaction to what was intended to be a practical suggestion to improve the user-friendliness of your software. It's a strength of BBC BASIC for Windows that you can embed resource files in the executable, and being able just to 'run' a program from a website or forum message seems to me a useful feature, so long as it is used appropriately.
|
|
I did not mean to sound negative. A little bit sarcastic perhaps, but not negative.
Must admit it amuses, more than it irritates me that it's now the second time that you have complained about the packaging rather than the content of my creation.
First time was when the original (non GFXLIB version) version of Blast was posted to the yahoo files area - you did not like/trust/approve of my Windows Installer MSI file.
I duly removed that and replaced it with a zip file. This was all a long time ago.
Now, as it turns out, you cannot be bothered with zip files either.
Have removed the current zip file from yahoo, will replace it with an exploding version at some later stage. And then again, I might not.
Simon
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #21 on: Sep 10th, 2008, 7:08pm » |
|
Quote:| Now, as it turns out, you cannot be bothered with zip files either. |
|
You mustn't take that personally. Computer games have never been my 'thing'; really they don't interest me at all (possibly because I'm hopeless at writing them and hopeless at playing them). David has achieved the near impossible by making his games so easy to run that even I bother to do so - although I still just watch the demo and listen to the music rather than actually play the thing.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender: 
Posts: 452
|
|
Re: GFXLIB (GFXLIB Example #35)
« Reply #22 on: Sep 11th, 2008, 07:17am » |
|
Although I won't publish the source yet (since it relies on subroutines not implemented in the publicly available version of GFXLIB), here's Example 35, which demonstrates two subroutines:
1. PROCLoadBMP24Scaled
2. GFXLIB_PlotColourBlendOpaque
(1) Loads and scales a 24 bits-per-pixel bitmap (original bitmap discarded)
(2) 'Colourizes' a bitmap to a specified colour and strengh, and then alpha-blends the resultant colour with the background pixel colour.
http://www.bb4w-games.com/example35.zip
[ Michael: this proggy uses only ~15% CPU on my laptop  ]
Regards,
David.
|
|
|
|
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.
|
|
|
|
|
