Author |
Topic: GFXLIB (Read 2267 times) |
|
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.
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: GFXLIB
« Reply #69 on: May 18th, 2009, 11:13am » |
|
Only one suggestion - repaint the guitar! 
I like the background.
Michael
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #71 on: May 23rd, 2009, 6:49pm » |
|
GFXLIB.BBC file size now exceeds 1 MB (assembled code size 60 Kb).
With so many variables declared (albeit most of them local), there may be trouble ahead.
Sooner rather than later, I'm going to have to consider practically rewriting GFXLIB so that it can be distributed as a compact DLL + packaging. But I wonder if it would really be worth the tremendous effort involved?
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #72 on: May 23rd, 2009, 9:26pm » |
|
Quote:| With so many variables declared (albeit most of them local), there may be trouble ahead. |
|
What kind of trouble do you anticipate?
Quote:| Sooner rather than later, I'm going to have to consider practically rewriting GFXLIB so that it can be distributed as a compact DLL |
|
Have you considered less drastic solutions? For example you could arrange to assemble the code using CALL filename$ (which would mean the memory occupied by the 'source' would be required only transitorily) and even - with care - discard the memory used by your temporary variables.
By judicious use of these techniques it should be possible to reduce the memory 'footprint' of GFXLIB to little more than the 60 kB code size.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #73 on: May 23rd, 2009, 9:50pm » |
|
on May 23rd, 2009, 9:26pm, Richard Russell wrote:| What kind of trouble do you anticipate? |
|
You might remember that some time ago, in an early pre-release version GFXLIB, so many variables were declared that when the main program was compiled with the 'Abbreviate names' option set, one of the variables in the assembler section of the main program was renamed to (IIRC) esi or edi, which of course happens to be a register name! You did mention that well over a thousand variables would have to be declared before such 'collisions' (with names of registers) occurs, and you also asked why on earth I needed to declare so many variables in the first place. The number of variables was drastically reduced, but the numbers are creeping up again...
I was going to suggest (or had I already suggested?) that perhaps you could modify the relevant code in the compiler to not replace variables with register names.
on May 23rd, 2009, 9:26pm, Richard Russell wrote:What kind of trouble do you anticipate?
Have you considered less drastic solutions? For example you could arrange to assemble the code using CALL filename$ (which would mean the memory occupied by the 'source' would be required only transitorily) and even - with care - discard the memory used by your temporary variables. |
|
Yes, I started to jot down ideas (actually, I made a start on the code a few weeks ago) for a possible fully modulized GFXLIB II, whereby the user can install the routines he or she requires. There would be a core set of routines mostly for internal use by GFXLIB, and the rest can be chosen as and when.
Regards,
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #74 on: May 24th, 2009, 10:09am » |
|
Quote:| You might remember that some time ago, in an early pre-release version GFXLIB, so many variables were declared that when the main program was compiled with the 'Abbreviate names' option set, one of the variables in the assembler section of the main program was renamed to (IIRC) esi or edi |
|
Yes, I remember that, but I don't believe the cruncher can ever create one of the 32-bit extended register names (eax, ebx, ecx...) because, since they start with the valid hexdecimal character e (in *LOWERCASE mode), they are specifically disallowed.
The first valid register name created by the cruncher is 'GS' which is the 1273rd variable (I think). That really is a bug, because register names like SI and SP are already explicitly tested for and disallowed. I'll make a note to correct that if I ever release another version.
In the meanwhile I'm sure you can keep your number of label names below 1273 by sensible use of macros (with 'local' or 'private' labels as appropriate) or even using array elements as labels as documented on the Wiki.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #75 on: May 25th, 2009, 12:34am » |
|
on May 24th, 2009, 10:09am, Richard Russell wrote:| Yes, I remember that, but I don't believe the cruncher can ever create one of the 32-bit extended register names (eax, ebx, ecx...) because, since they start with the valid hexdecimal character e (in *LOWERCASE mode), they are specifically disallowed. |
|
Yes, right you are. I had tried to find the e-mail that I originally sent to you which mentioned the actual register name, but it appears that Hotmail has either deleted it from their system, or has made it unavailable to me (I doubt they actually erase any e-mails from their servers).
on May 24th, 2009, 10:09am, Richard Russell wrote:| In the meanwhile I'm sure you can keep your number of label names below 1273 by sensible use of macros (with 'local' or 'private' labels as appropriate) or even using array elements as labels as documented on the Wiki. |
|
Array elements as labels sounds like a good idea, so I'll consider going that route; I'll consult the Wiki.
David.
|
|
Logged
|
|
|
|
|
