Author |
Topic: GFXLIB (Read 2189 times) |
|
Michael Hutton
Developer
member is offline
Gender: 
Posts: 248
|
 |
Re: GFXLIB
« Reply #51 on: Nov 15th, 2008, 03:19am » |
|
Hello,
I've been using GFXLIB. I've got the latest version and I like the Autoinit bit!
http://tech.groups.yahoo.com/group/bb4w/files/Graphics/Plasmas/
I've been making some simple plasmas, reminds me of the FRACTINT plasmas but at the moment they are all fixed SIN functions. I am coding a 'realtime' RGB plasma which should change the pattern with time not just the colours. I was also going to try to use the plasma as an alpha mask...
At the moment I am using my own bit of code to do the palette rotation but I thought I might be able to use GFXLIB_****LUT1/2/3 but I wasn't quite sure how to implement them.
LUT1, looks up the colour value (RGB) from a one dimensional look up table, yes? So in effect I was thinking of filling a bit map with the plasma pallete values, each separate byte containing a separate pallete code. For example if the palette colour was 255 the pixel would be &FFFFFF not just &FF and then using LUT1 to find my colour and then BPlot the resultant bit map... I wasn't quite sure form the documentation what exactly I should be doing. Could I use LUT3 instead. Also I noticed a line REM'd out in LUT1 function. I presume this is correct but was just wondering!
I love the Bplotscale(NC) functions I got some very 'nice' plasma effects in BASIC by drawing a 50x50 grid using PLOT and then scaling it up to full screen. The 'Blockyness' was quite good.
I have found a good way (well, I think it's good) to make a blank bitmap which avoids all the CreateDC,CreateCompatibleBitmap, SelectObject calls (which I HATE by the way, as I always get lost (same as idiv/div - always gets me down...  ). Just *SCREENSAVE a bit of the screen (I found you have to make it four times the x and y co-ordinates you want) and then load it back in with GFX. I noticed that when I got the size wrong subsequently when I DIM'd more variables they ended up in the middle of my bitmap! Very frustrating, with multiple crashes...
Are there any transforming (ie rotation, sphere, cylinder stuff coming up?) I know I don't ask for much! I have tried a sort of cylinder but only can manage it aligned along the x-axis using Plot**row (can' remember the name sitting here!) and some sin/cos functions. It would be good to be able to wrap it 'properly'.
anyway, keep up the good work. Is there more GFXLIB documentation coming up?
|
|
 Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #52 on: Nov 16th, 2008, 12:24am » |
|
on Nov 15th, 2008, 03:19am, Michael Hutton wrote:| I've been making some simple plasmas |
|
They're great! Plasma 1.03 is especially impressive (and the closest I'll ever get to experiencing an acid trip).
on Nov 15th, 2008, 03:19am, Michael Hutton wrote:| At the moment I am using my own bit of code to do the palette rotation but I thought I might be able to use GFXLIB_****LUT1/2/3 but I wasn't quite sure how to implement them. |
|
Sorry, about the lack of documentation concerning these and other GFXLIB routines -- it'll come, eventually.
LUT1 takes an RGB word from a source bitmap (the one you want to plot), and extracts the individual RGB bytes from it, each of course being in the range 0 to 255 (I'm being verbose here for the benefit of others!). The extracted byte values are then used as indices for a single 256-byte lookup table, from which bytes are read and it is these bytes which are written to the destination bitmap (or DIB section). It's important to note that the three RGB components are indices for just one single table -- greater versatility would be had if each component indexed its own table (I'll probably implement this for a future LUT4).
Copy, paste and run this example program:
Code: M% = 2
HIMEM = LOMEM + M%*&FA000
MODE 8 : OFF
INSTALL @lib$+"GFXLIB"
PROCAutoInit32
REM. Reserve memory for a 640x512 32bpp bitmap
DIM bm% 4*640*512-1
REM. Reserve space for a 256-byte colour table
DIM table% 255
REM. Fill the colour table
FOR I%=0 TO 255
table%?I% = 255-I%
NEXT I%
REM. Redirect GFXLIB's output to addr pointed to by bm%
REM. (Normally, GFXLIB's output is to the DIB section/screen memory)
SYS GFXLIB_QuickSetDispVars, dispVars{}, bm%
REM. QuickSetDispVars can be used here because bitmap pointed to by bm%
REM. is the same dimensions as the program window
REM. Draw 100 bitmaps to the bitmap pointed to by bm%
REM. Note that the global variable demoBm32% points to a 64x64 32bpp bitmap
REM. set up when PROCAutoInit32 is called (it doesn't just appear out of thin air!)
FOR I%=1 TO 100
SYS GFXLIB_Plot, dispVars{}, demoBm32%, 64, 64, RND(640), RND(512)
NEXT I%
REM. Restore GFXLIB's output to the DIB section pointed to by dibSectionAddr%
SYS GFXLIB_QuickSetDispVars, dispVars{}, dibSectionAddr%
REPEAT
IF (TIME DIV 100) MOD 2=0 THEN
REM. Draw the bitmap (bm%) normally using BPlot
SYS GFXLIB_BPlot, dispVars{}, bm%, 640, 512, 0, 0
ELSE
REM. Draw the bitmap (bm%) using BPlotLUT1
SYS GFXLIB_BPlotLUT1, dispVars{}, bm%, table%, 640, 512, 0, 0
ENDIF
SYS "InvalidateRect", @hwnd%, 0, 0
PROCWait(4)
*REFRESH
UNTIL FALSE
After running, replace the line
Code:
with
Code:
LUT2 is similar, except that it uses the RGB components of the background pixels as indices into a 256-byte table, rather than the source bitmap pixels. LUT2 can be used for shadow effects, for example.
LUT3 relies on a 2D table (256*256 bytes) as the RGB components of both the background and source bitmap pixels are taken into account. LUT3 lends itself to various transparency effects, although, as with LUT1 and LUT2, the individual RGB components of the background and source pixels are indices for a single common colour table. Would be nice if they could each have their own table (a future LUT5, perhaps).
If you have the time and inclination, then copy, paste and run this proggy:
Code: M% = 2
HIMEM = LOMEM + M%*&FA000
MODE 8 : OFF
INSTALL @lib$+"GFXLIB"
PROCAutoInit32
DIM table% 256*256-1
opacity% = 25
f# = 1.0 - opacity%/100
FOR I%=0 TO 255
FOR J%=0 TO 255
table%?(256*I% + J%) = I% + f#*(J%-I%)
NEXT J%
NEXT I%
FOR I%=1 TO 100
SYS GFXLIB_PlotLUT3, dispVars{}, demoBm32%, table%, 64, 64, RND(640)-32, RND(512)-32
NEXT
SYS "InvalidateRect", @hwnd%, 0, 0
PROCWait(4)
*REFRESH
on Nov 15th, 2008, 03:19am, Michael Hutton wrote:| I love the Bplotscale(NC) functions I got some very 'nice' plasma effects in BASIC by drawing a 50x50 grid using PLOT and then scaling it up to full screen. The 'Blockyness' was quite good. |
|
Just in case anyone's wondering... the NC part of the routine name GFXLIB_BPlotScaleNC means "Not Clipped" or "No Clipping". It's a fast and rather dangerous routine! But if used carefully (as I'm sure you've done), it's a mighty fast bitmap scaler - almost as fast as straightforward GFXLIB_Plot.
on Nov 15th, 2008, 03:19am, Michael Hutton wrote:| I have found a good way (well, I think it's good) to make a blank bitmap which avoids all the CreateDC,CreateCompatibleBitmap, SelectObject calls (which I HATE by the way, as I always get lost (same as idiv/div - always gets me down... ;D). Just *SCREENSAVE a bit of the screen (I found you have to make it four times the x and y co-ordinates you want) |
|
I've found a good way of achieving the same thing -- that is simply to reserve a suitably sized area of memory using DIM (or whatever). Most of GFXLIB's aren't concerned with bitmap headers as most of the routines assume a 32bpp bitmap, and the width and height of the bitmap is - in most cases - specified when the routine is called.
So this bit of code from Plasma 1.03 ...
Code: REM Create blank bitmaps to store the plasma and the buffer bitmap
PRINT"Creating Blank Bitmap...";
plasma_file$="plasma.bmp"
OSCLI "SCREENSAVE """+plasma_file$+""" "+STR$0+","+STR$0+","+STR$(cx%*4)+","+STR$(cy%*4)
PROCLoadBMP(@dir$+plasma_file$, plasmaBM%, FALSE )
OSCLI "DEL """+plasma_file$+""""
PRINT"OK!"
can be replaced by
Code: DIM plasmaBM% 4*(cx%*cy% + cx%) +4
plasmaBM%=(plasmaBM%+3) AND -4
The additional cx% is required in the DIM declaration because your plasma routine has either a memory leak (poking data outside the 640x512 bitmap), or you're attempting to read data from a location outside the bitmap. I suspect that the former case is at foot here.
For those who don't know, the plasmaBM%=(plasmaBM%+3) AND -4 statement ensures that plasmaBM% points to a word-aligned address (always a good idea as non-aligned memory accesses can incur a speed penalty, on some systems). The +4 tacked on the end ensures there's sufficient room in case plasmaBM% does need to be incremented by at most 3 bytes.
on Nov 15th, 2008, 03:19am, Michael Hutton wrote:| Are there any transforming (ie rotation, sphere, cylinder stuff coming up?) |
|
I started coding coordinate rotation routines for GFXLIB a few weeks ago, with the idea of providing high-precision but slow-ish (FPU- based) routines, and a parallel set of routines based on fast fixed-point integers. I'll have to resume work on this, but at the moment, my 'batteries' are a bit flat, as it were.
on Nov 15th, 2008, 03:19am, Michael Hutton wrote:| I have tried a sort of cylinder but only can manage it aligned along the x-axis using Plot**row (can' remember the name sitting here!) and some sin/cos functions. It would be good to be able to wrap it 'properly'. |
|
I've got such a routine to do just that... but it's currently in BASIC! I think it's called HLineShift or something like that (horizontal line shift with wraparound (on same raster)).
on Nov 15th, 2008, 03:19am, Michael Hutton wrote:| Is there more GFXLIB documentation coming up? |
|
Yes, and I'm sorry I've been dragging my feet on this -- my batteries really are low! Just can't get motivated. I'll do some work on the docs this week -- certainly on the PlotLUT routines. Will try to provide plenty of examples.
Again, your plasmas look great (and not too nausea-inducing) and very slick. I look forward to seeing the shapes/patterns change in subsequent versions!
Regards,
David.
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: GFXLIB
« Reply #53 on: Nov 16th, 2008, 02:24am » |
|
Quote:I've found a good way of achieving the same thing --
|
|
Ah, yes. At the time I was looking for the whole bitmap including the header, but good point!
As with my 'plot' code, I always get mixed up with the addressing. Not good.
Thanks for the examples for LUT1 and LUT2, I think I see what is happening a bit more clearly. I think I will be able to use them. I was thinking that I might be able to get the graphics card to cycle the colour palette rather than me do it but I suppose that involves DirectX (Draw?) which I haven't really got into yet.
I have a working version of the moving plasma but I'll 'tidy' it up today before posting.
Michael
|
|
Logged
|
|
|
|
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
--
|
|
|
|
|
