Author |
Topic: GFXLIB (Read 2268 times) |
|
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.
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB (yet another 'example')
« Reply #32 on: Sep 21st, 2008, 10:05pm » |
|
http://www.bb4w-games.com/example41.zip
The point of this is to demonstrate one of a dozen-or-so new GFXLIB routines; in this case, GFXLIB_PlotScaleColourBlend.
There'll be a dedicated (albeit very incomplete) GFXLIB website up by the end of this month.
David.
|
|
|
|
81RED
Guest
|
|
Re: GFXLIB (yet another 'example')
« Reply #33 on: Sep 25th, 2008, 07:03am » |
|
on Sep 21st, 2008, 10:05pm, David Williams wrote:http://www.bb4w-games.com/example41.zip
The point of this is to demonstrate one of a dozen-or-so new GFXLIB routines; in this case, GFXLIB_PlotScaleColourBlend.
There'll be a dedicated (albeit very incomplete) GFXLIB website up by the end of this month.
David. |
|
Looks great as always, and that font looks strangely familiar. 
Simon
|
|
 Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB (yet another 'example')
« Reply #34 on: Sep 25th, 2008, 07:13am » |
|
on Sep 25th, 2008, 07:03am, Simon Mathiassen wrote:Looks great as always, and that font looks strangely familiar.
Simon |
|
I like that font 
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #35 on: Sep 25th, 2008, 08:34am » |
|
Quote:| There'll be a dedicated (albeit very incomplete) GFXLIB website up by the end of this month. |
|
Can I encourage you to write up your library (or at least provide a link to your own site) in the 'Third Party Libraries' section of the BB4W Wiki: http://bb4w.wikispaces.com/Libraries
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #36 on: Sep 25th, 2008, 12:50pm » |
|
on Sep 25th, 2008, 08:34am, Richard Russell wrote:Can I encourage you to write up your library (or at least provide a link to your own site) in the 'Third Party Libraries' section of the BB4W Wiki: http://bb4w.wikispaces.com/Libraries
Richard.
|
|
No encouragement is necessary -- I intend to do just as you suggested.
One potential issue that may be cause for grumbles, is the size of the library: it's currently 872Kb, and will probably be around 2Mb by the time I've finished. Having said that, there's a lot of repeated code segments outside time-critical sections across many of the routines, so some space can be saved there. If I were to re-write GFXLIB, I would have the user INSTALL the 'core library' (comprising a couple of essential common routines), and then the user could CALL library components as required, viz.
REM. Install core library
INSTALL @lib$ + "GFXLIB"
PROCInitGfxLib
REM. Install required library routines
CALL @lib$ + "gfxlib\plot"
CALL @lib$ + "gfxlib\plotscale"
CALL @lib$ + "gfxlib\boxblur3x3"
CALL @lib$ + "gfxlib\alphablend"
And so on.
Regards,
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #37 on: Sep 25th, 2008, 5:07pm » |
|
Quote:| One potential issue that may be cause for grumbles, is the size of the library: it's currently 872Kb |
|
I assume much of that is assembler source code. If there's little or no BASIC code how about converting the library into a DLL, which (containing only machine code) ought to be substantially smaller?
Given that (I believe) you already use a 'SYS' interface to your routines - rather than CALL for example - conversion to a DLL should be made easier.
The only area where you might perhaps have problems is the use of 'global' (i.e. BASIC) variables which would have to be reworked for a DLL that doesn't share the same address space.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #38 on: Sep 26th, 2008, 7:12pm » |
|
on Sep 25th, 2008, 5:07pm, Richard Russell wrote:I assume much of that is assembler source code. If there's little or no BASIC code how about converting the library into a DLL, which (containing only machine code) ought to be substantially smaller?
Given that (I believe) you already use a 'SYS' interface to your routines - rather than CALL for example - conversion to a DLL should be made easier.
The only area where you might perhaps have problems is the use of 'global' (i.e. BASIC) variables which would have to be reworked for a DLL that doesn't share the same address space.
Richard. |
|
When I started writing GFXLIB, I set up a jump table of routine addresses at the beginning of the code, then I *SAVEd the assembled code. When I *LOADed the code into memory and tried to execute one of the routines, it didn't work. I can't remember the reason for this, I think it was due to the addresses of the global variables changing, or maybe jumps were jumping to incorrect addresses. This version of GFXLIB employs relatively few global variables -- it relies on a single large variables block (varsblk). I'll have another crack at it at some point, but, really, it'll have to wait until I'm motivated to undertake the considerable work involved in making it work.
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #39 on: Sep 27th, 2008, 09:12am » |
|
Quote:| I *SAVEd the assembled code. When I *LOADed the code into memory and tried to execute one of the routines, it didn't work |
|
It's jolly difficult to write 'position independent' code for the x86 CPU family, and the overheads involved would adversely affect performance anyway. That's why you really need a relocatable object format (such as a DLL or other PE-file) in which all the cross-references and jump destinations are automatically adjusted by the loader.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
GFXLIB v1.1.0 released and website launched
« Reply #40 on: Oct 3rd, 2008, 7:10pm » |
|
New GFXLIB website:
http://www.bb4w-games.com/gfxlib/gfxlib.html
Version 1.1.00 is a major update, a lot of work has gone into it, and
whilst there's plenty of new routines to come, it won't be easy for
me to remain motivated to implement them if there's little evidence
of use (you can understand that, can't you?).
I've made a start on the GFXLIB Reference section (on the website),
but there's so much more to do. Meanwhile, there's plenty of
commented example programs (with listings also given in HTML form) to
study.
Some are bound to be offended by the size of the GFXLIB.BBC file --
currently 882Kb and growing. On a personal level though, it wouldn't
bother me if it was 5Mb.
To be done:
* Finish the documentation of current routines
* Write a simple tutorial
* More fully-commented example programs
* Add bitmap rotation routines
* Improve font drawing routines
* Add line, circle and polygon plotters (will need help with these)
* Add bitmap blurring routines
* Possibly polygon texturing routines
I'm also happy to accept routines from anyone who can contribute.
Or, if you're not able to program in assembly language (I barely
can), then send me a working algorithm in BASIC and I'll probably be
able to convert it to assembly language.
Regards,
David.
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #41 on: Oct 15th, 2008, 2:23pm » |
|
Quote:| No encouragement is necessary -- I intend to do just as you suggested. |
|
I don't want to hurry you more than you're comfortable with, but I notice that GFXLIB still isn't listed in the Libraries page on the Wiki:
http://bb4w.wikispaces.com/Libraries
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #42 on: Oct 16th, 2008, 5:53pm » |
|
on Oct 15th, 2008, 2:23pm, Richard Russell wrote:I don't want to hurry you more than you're comfortable with, but I notice that GFXLIB still isn't listed in the Libraries page on the Wiki:
http://bb4w.wikispaces.com/Libraries
Richard. |
|
Done. 
Regards,
David.
|
|
Logged
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: GFXLIB
« Reply #43 on: Oct 26th, 2008, 07:02am » |
|
David,
I have made a routine to sort an array of structures by a 4 byte float key. It is whittled down to the bear essentials and is fast! (well, I think so anyway).
It will only accept one sort key parameter and you need to pass the structure as the first parameter.
http://tech.groups.yahoo.com/group/bb4w/files/Libraries/SORTSAF4LIB.bbc
Let me know if you think it is useful at all.
Michael
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #44 on: Oct 27th, 2008, 11:32am » |
|
on Oct 26th, 2008, 07:02am, Michael Hutton wrote:David,
I have made a routine to sort an array of structures by a 4 byte float key. It is whittled down to the bear essentials and is fast! (well, I think so anyway).
It will only accept one sort key parameter and you need to pass the structure as the first parameter.
http://tech.groups.yahoo.com/group/bb4w/files/Libraries/SORTSAF4LIB.bbc
Let me know if you think it is useful at all.
Michael |
|
Well, great work I'm sure, and beautiful-looking assembly language to boot, but it's not immediately useful to me because I don't use four-byte floats (although I had to use them of course during my brief adventure with D3DLIB).
I was interested in the instruction timings/clock cycles you neatly gave alongside most of the assembler instructions, but are you sure they're correct (even for the specified Pentium processor)?
For instance, aren't instruction pairs like
add eax,9
shl edx,3
fetched 'simulatenously' into the two separate pipelines (U and V), effectively having both instructions executed in 1 cycle?
Similarly for this pair:
mov edx, ecx
inc ebx
I don't think memory accesses are completed in one cycle either:
mov esi, [ebx]
mov edi, [ebp+7]
As for fld dword [ecx], well, no way is that completed in one cycle!
Please forgive my nitpicking
Regards,
David.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #45 on: Oct 27th, 2008, 2:47pm » |
|
Quote:| For instance, aren't instruction pairs like add eax,9 : shl edx,3 fetched 'simulatenously' |
|
I'm not sure that's such a good example, because since both those instructions affect the flags it's necessary for the CPU to ensure that they are effectively executed in the specified sequence (of course that doesn't necessarily imply more than one clock cycle).
Quote:| Similarly for this pair: mov edx, ecx : inc ebx |
|
That's a better example, because they are genuinely independent. Having said that, 'inc ebx' isn't a particularly fast instruction on some modern processors (because of the need to preserve the carry flag) - 'add ebx,1' may execute faster despite requiring more bytes.
Richard.
|
|
Logged
|
|
|
|
|
