Author |
Topic: GFXLIB (Read 2305 times) |
|
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
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #76 on: May 25th, 2009, 12:42am » |
|
A quick demo of a new routine called PlotBMColumn (plots a single 1-pixel-wide column of pixels from a bitmap):
http://www.bb4w-games.com/138519651/gfxlib_vplot_demo.zip (500 Kb)
If it seems a bit sluggish then bear in mind that the BB4W interpreter is doing a lot of work!
This routine will form the basis of several other routines.
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #77 on: May 28th, 2009, 02:48am » |
|
GFXLIB's alpha blending routines are set to become a hell of a lot faster thanks to this sweet bit of
code I recently discovered on Avery Lee's VirtualDub site (http://tinyurl.com/obqpyt):
Code:unsigned blend2(unsigned src, unsigned dst) {
unsigned alpha = src >> 24;
alpha += (alpha > 0);
unsigned srb = src & 0xff00ff;
unsigned sg = src & 0x00ff00;
unsigned drb = dst & 0xff00ff;
unsigned dg = dst & 0x00ff00;
unsigned orb = (drb + (((srb - drb) * alpha + 0x800080) >> 8)) & 0xff00ff;
unsigned og = (dg + (((sg - dg ) * alpha + 0x008000) >> 8)) & 0x00ff00;
return orb+og;
}
It works very well, and my ASM implementation of the above code is a big improvement over how
GFXLIB's routines currently perform the task (although here the code is modified to work with
a constant alpha value, rather than a per-pixel one as is done in the original code):
Code: .blend
;REM. ESP+4 -> src pxl (RGB32)
;REM. ESP+8 -> dst pxl (RGB32)
;REM. ESP+12 -> alpha (0-255)
mov ebp, [esp + 12] ; alpha value (0 to 255)
mov esi, [esp + 4] ; src pxl &xxRRGGBB
mov edi, [esp + 8] ; dest pxl &xxRRGGBB
mov eax, esi ; copy ESI
and eax, &FF00FF ; EAX = srb
and esi, &00FF00 ; ESI = sg
mov edx, edi ; copy EDI
and edi, &FF00FF ; EDI = drb
and edx, &00FF00 ; EDX = dg
;REM. EAX = srb
;REM. ESI = sg
;REM. EDI = drb
;REM. EDX = dg
sub eax, edi ; srb - drb
sub esi, edx ; sg - dg
imul eax, ebp ; (srb - drb)*alpha
imul esi, ebp ; (sg - dg)*alpha
add eax, &800080 ; (srb - drb)*alpha + &800080
add esi, &008000 ; (sg - dg)*alpha + &008000
shr eax, 8 ; ((srb - drb)*alpha + &800080) >> 8
shr esi, 8 ; ((sg - dg)*alpha + &008000) >> 8
add eax, edi ; drb + ((srb - drb)*alpha + &800080) >> 8
add esi, edx ; dg + ((sg - dg)*alpha + &008000) >> 8
and eax, &FF00FF ; (drb + ((srb - drb)*alpha + &800080) >> 8) AND &FF00FF
and esi, &00FF00 ; (dg + ((sg - dg)*alpha + &008000) >> 8) AND &00FF00
add eax, esi
ret 12
If anyone can spot any optimisations that can be made, perhaps shaving off an instruction or two,
then please let me know!
Regards,
David.
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #79 on: Jun 3rd, 2009, 08:21am » |
|
Quote:
Very nice.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #81 on: Jun 6th, 2009, 8:01pm » |
|
Another day, another new routine for an already bloated GFXLIB. This one's called GFXLIB_RotateScaleTile:
http://www.bb4w-games.com/138519651/rotatescaletile.zip
It uses a quite fast method of rotating a bitmap, although my code is far from optimal. Still, this
demo averages only 16% CPU load on my laptop which is rather good in my opinion.
David.
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: GFXLIB
« Reply #82 on: Jun 7th, 2009, 6:41pm » |
|
Another great routine! When is the next version of GFXLIB coming out?
Michael
|
|
Logged
|
|
|
|
|
