Author |
Topic: GFXLIB (Read 2262 times) |
|
admin
Administrator
member is offline
Posts: 1145
|
 |
Re: GFXLIB
« Reply #54 on: Nov 16th, 2008, 09:53am » |
|
Quote:| For those who don't know, the plasmaBM%=(plasmaBM%+3) AND -4 statement ensures that plasmaBM% points to a word-aligned address |
|
Bear in mind that in a Windows bitmap (either in the form of a .BMP file or a DIB in memory) every row must be DWORD-aligned.
That doesn't involve any overhead if you're using a 32-bpp bitmap (if the first row is aligned, so must all the others) but if you're using a 24-bpp bitmap then it means every row must be padded to a multiple of 4 bytes if it isn't already.
So the general form of memory allocation for a bitmap is:
Code:
DIM bmp% cy% * ((bpp% DIV 8 * cx% + 3) AND -4) + 3
bmp% = (bmp% + 3) AND -4
Richard.
|
|
 Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender: 
Posts: 452
|
|
Re: GFXLIB
« Reply #55 on: Nov 17th, 2008, 5:45pm » |
|
on Nov 16th, 2008, 09:53am, Richard Russell wrote:So the general form of memory allocation for a bitmap is:
Code:
DIM bmp% cy% * ((bpp% DIV 8 * cx% + 3) AND -4) + 3
bmp% = (bmp% + 3) AND -4
|
|
Thanks for that bit of code, Richard.
GFXLIB is intended for use mostly with 32-bpp bitmaps (although there is a handful of routines for 8-bpp bitmaps). The one routine available for simply displaying a 24-bpp bitmap (GFXLIB_BPlotBMP24) can only be safely written to a 32-bpp DIB section or bitmap buffer.
GFXLIB provides the subroutine PROCLoadBMP which will load 8, 24 and 32-bpp bitmaps, and in the first two cases, will convert the bitmap to 32-bpp. 16-bpp isn't currently catered for, but then who uses those nowadays?
David.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #56 on: Dec 24th, 2008, 11:51am » |
|
The next version of GFXLIB (version 1.2) will feature several new routines, including line, circle and filled triangle plotters, and possibly also routines for rotating lists of 3D coordinates.
Meanwhile, this wee 'demo' indicates the speed of GFXLIB's new line plotter (bear in mind that the coordinates of the line endpoints are updated and checked in BASIC, and that one SYS GFXLIB_Line... statement is issued for each line drawn).
http://www.bb4w-games.com/temp/gfxlib_line.zip
I'll make some much more interesting demos at a later date. 
David.
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: GFXLIB
« Reply #58 on: May 2nd, 2009, 12:05pm » |
|
Nice. That is a really good effect.
What function did you use for that or is it a new one? I would guess at GFXLIB_PlotBMRow?
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #59 on: May 2nd, 2009, 10:17pm » |
|
> Nice. That is a really good effect.
>
> What function did you use for that or is it a new one?
> would guess at GFXLIB_PlotBMRow?
No, PlotBMRow doesn't do any scaling.
What's used here is BPlotScale:
Code:SYS GFXLIB_BPlotScale, dispVars{}, bmAddr, bmW, bmH, newBmW, newBmH, x, y
When used ordinarily and correctly, this would render a scaled bitmap in the way you'd expect. However, to draw an individual (scaled) horizontal line of a bitmap (pointed to by bmAddr), set bmH and newBmH to 1, and add a suitable offset to the bmAddr param:
Code:
SYS GFXLIB_BPlotScale, dispVars{}, bmAddr + 4*row%*bmW, bmW, 1, newBmW, 1, x, y
where row% (given from 0 to bmH-1) is the row of pixels that you wish to draw.
I know you know this, but for other people's benefit, the x4 multiplier is due to the fact that we're dealing with four bytes per pixel here (GFXLIB operates mostly on 32-bits-per-pixel bitmaps).
FWIW, here's the drawing loop from Example #32:
Code:REM. Draw the individually scaled rows of the 480x256 BB4W graphic
FOR I%=0 TO 255
x1% = 80 + 128*SIN( a1# + I%/64 ) * COS( a3# + I%/32 )
x2% = 560 + 128*COS( a2# + I%/64 ) * SIN( a3# + I%/32 )
SYS GFXLIB_BPlotScale, dispVars{}, bitmap%+4*480*I%, 480, 1, x2%-x1%, 1, (640-(x2%-x1%))/2, 128+I%
NEXT
URL: http://www.bb4w-games.com/gfxlib/ex/32bpp/html/example32.html
Regards,
David.
http://www.bb4w-games.com
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #60 on: May 3rd, 2009, 8:04pm » |
|
Would anyone out there like to contribute graphics routines to GFXLIB? Come on folks, this should be a collaborative effort!
Here are some ideas:
* Bitmap blurrers / smoothers (inc. Gaussian blurring)
* Higher quality bitmap scaling -- bicubic interpolation or Richard's somewhat esoteric method
* Lensing effects
* Lighting effects
* Other special effects
* Bitmap distortion routines (e.g., barrel distortion)
* Colour manipulation -- HSV-altering routines, for example
* Faster alpha blending routines (MMX-based, perhaps)
* Robust line, circle and polygon plotters -- with anti-aliasing if possible
* Texture mappers -- even if it's just so-called "affine" texture mapping
* Fast bitmap rotation
* Bitmap rotation *with* anti-aliasing
* 3D routines of various kind
* Bezier / spline curve rendering
* Fast font renderers
For those not able to implement such routines in assembly language, how about creating a working prototype version in BASIC and have one of the BB4W community's willing assembler experts 'translate' it to glorious assembly language?
Help make GFXLIB into something *special* -- and useful.
Even better, perhaps, someone could start to create a competing graphics library with superior graphics routines than is currently available in GFXLIB. 
Regards,
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #61 on: May 3rd, 2009, 9:52pm » |
|
Quote:| Richard's somewhat esoteric method |
|
I would like to point out that it's hardly 'my' method; it's well known and documented, and based on sound fundamental mathematics. For example, it's been routinely used for years at BBC Research & Development (indeed long before I ever joined that august organisation) and is the method used in all Snell & Wilcox Standards Converters, Aspect Ratio Converters, PAL Decoders etc. (one reason why they have the reputation of being the best of their kind).
Calling it "esoteric" does it an injustice, in my opinion, because it's neither difficult to understand nor particularly complicated. It could also discourage people to try it, when it's almost always the best choice.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #62 on: May 3rd, 2009, 11:29pm » |
|
on May 3rd, 2009, 9:52pm, Richard Russell wrote:I would like to point out that it's hardly 'my' method; it's well known and documented, and based on sound fundamental mathematics. For example, it's been routinely used for years at BBC Research & Development (indeed long before I ever joined that august organisation) and is the method used in all Snell & Wilcox Standards Converters, Aspect Ratio Converters, PAL Decoders etc. (one reason why they have the reputation of being the best of their kind).
Calling it "esoteric" does it an injustice, in my opinion, because it's neither difficult to understand nor particularly complicated. It could also discourage people to try it, when it's almost always the best choice.
Richard.
|
|
My word, you seem to be almost offended (I had half-expected a response just like that one from you!).
Can the "frequency domain method" be implemented in IA-32 assembly language so that it's fast enough for use with games -- after all, that's primarily what GFXLIB is intended for, and I've always maintained that? I suspect it's overkill under these circumstances.
A fast (bi)cubic interpolator would be sufficient for GFXLIB's primary intended purpose. Tony Tooth's excellent "Spline Resize" program employs cubic spline interpolation, however it may be too slow for real-time use in games (I'm *not* at all knocking his program, just "telling it like it is").
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #63 on: May 4th, 2009, 09:28am » |
|
Quote:| My word, you seem to be almost offended |
|
It's not a case of being offended, it's a case of not wanting a false impression to be given.
Quote:| Can the "frequency domain method" be implemented in IA-32 assembly language so that it's fast enough for use with games |
|
The 'frequency domain method' is simply an FIR (Finite Impulse Response filter), as is bicubic interpolation and virtually every other known interpolation technique! Therefore not only does it it take exactly the same time (assuming the same number of taps is used) but indeed uses exactly the same code as bicubic interpolation!
If you refer back to my article, you will see that the only difference between cubic interpolation and 'my' method (with 4 taps) is in the coefficients by which the input samples are multiplied. Simply by altering the values of the coefficients, but otherwise making no changes to the code the performance is improved.
Of course, if you're actually calculating the coefficients 'at run time' in your program then there could be an impact on complexity and speed, but that's a one-time calculation for any given degree of scaling.
Perhaps you can now see why I reacted to your terminology. To convert bicubic interpolation into a comparable 'frequency-domain-based' method involves no changes to the code and no changes to the speed. You get a performance improvement for no cost whatever, other than the need to calculate the coefficients differently.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #64 on: May 14th, 2009, 2:32pm » |
|
I'm quite pleased with this animated background made in readiness for the completion of my slightly improved 'colour keying' algorithm. It was made almost entirely with GFXLIB - no tricks, except for a very slight Gaussian blur applied in VirtualDub (it didn't occur to me to use the 5x5 box blur routine available in GFXLIB!).
(BTW - anyone fancy contributing a Gaussian blur routine to GFXLIB? Just wondering...)
File name: bg2_3.avi
Format: DivX AVI
Dimensions: 720 x 576 pixels
Duration: 60 seconds
File size: 6 Mb
URL: http://www.bb4w-games.com/138519651/bg2_3.avi
The freely available DivX codec is required to view this video.
Regards,
David.
http://www.bb4w-games.com
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #65 on: May 15th, 2009, 3:54pm » |
|
Another background animation (created with GFXLIB and VirtualDub) just crying out to be used with Richard's CSO utility:
http://www.bb4w-games.com/138519651/bg3.avi
File size: 4.26 MB
Format: DivX AVI
Codec: DivX
Dimensions: 720 x 576
Frame rate: 25 fps
Data rate: 582 kbps
Duration: 60 seconds
No audio
--
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: GFXLIB
« Reply #66 on: May 16th, 2009, 08:12am » |
|
on May 14th, 2009, 2:32pm, David Williams wrote:(BTW - anyone fancy contributing a Gaussian blur routine to GFXLIB? Just wondering...)
|
|
Didn't Tony Tooth do a Gaussian Blur routine?
Michael
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #67 on: May 16th, 2009, 10:45am » |
|
on May 16th, 2009, 08:12am, Michael Hutton wrote:Didn't Tony Tooth do a Gaussian Blur routine?
Michael |
|
I think you may be referring to his image smoothing program (SmoothX), which, as far as I can tell, performs a 3x3 'box blur' with user-specifiable relative weightings for the central and surrounding pixels.
For the benefit of others viewing this thread, with Gaussian blurring you specify a fractional blur radius 'r' (in pixels). The image below demonstrates Gaussian blurring for r=0.0, 0.5, 1.0, 2.0, 3.0, 4.0, 6.0, 8.0 and 10.0:
http://www.bb4w-games.com/138519651/gaussianblurring.jpg
(That was done with Adobe Photoshop).
David.
|
|
|
|
|
