Author |
Topic: GFXLIB (Read 2185 times) |
|
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
|
|
|
|
Michael Hutton
Guest
|
|
Re: GFXLIB
« Reply #46 on: Oct 28th, 2008, 07:53am » |
|
on Oct 27th, 2008, 11:32am, David Williams wrote:As for fld dword [ecx], well, no way is that completed in one cycle!
Please forgive my nitpicking
|
|
I know, I'm not sure I believe it also and I remember being quite surprised , but I wasn't going to argue. There are obviously qualifiers to the memory access opcodes, but I think I was right when it didn't seem to require adding any other cycles.
I will definitely go and check again, it's on another computer.
Don't thank me for the elegant code ! - it's a complete ripoff of SORTLIB which contains the beef of the QUICKSORT routine. I've only added the addressing of structures...
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #47 on: Oct 28th, 2008, 09:17am » |
|
Quote:| I will definitely go and check again, it's on another computer. |
|
The only way is to measure it. This paper gives some useful hints, including the use of CPUID as a 'serialising' instruction: http://pasta.east.isi.edu/algorithms/IntegerMath/Timers/rdtscpm1.pdf
Richard.
|
|
Logged
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: GFXLIB
« Reply #48 on: Oct 30th, 2008, 12:38pm » |
|
Thanks Richard, I had remembered something about 'a time stamp' or CPUID feature and was looking at for it again but that saves me a bit of reading.
I got the original timing from
http://www.packetstormsecurity.com/programming-tutorials/Assembly/fpuopcode.html
FLD Floating point load
operand 8087 287 387 486 Pentium
reg 17-22 17-22 14 4 1 FX
mem32 (38-56)+EA 38-56 20 3 1 FX
mem64 (40-60)+EA 40-60 25 3 1 FX
mem80 (53-65)+EA 53-65 44 6 3 NP
but I will try and use Richard's link..
Michael
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #49 on: Oct 30th, 2008, 2:45pm » |
|
Code:
operand 8087 287 387 486 Pentium
mem32 (38-56)+EA 38-56 20 3 1
mem64 (40-60)+EA 40-60 25 3 1
mem80 (53-65)+EA 53-65 44 6 3
Don't those timings exclude the memory fetch? Any memory access may incur an overhead, depending on where the data is (L1 cache, L2 cache, main memory) unless it has been 'prefetched'.
Richard.
|
|
Logged
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: GFXLIB
« Reply #50 on: Oct 30th, 2008, 11:05pm » |
|
Hmm, yes it seems so. Those must be timings from when the data is where exactly?
(Should I start a new topic OPCODE TIMINGS) in the assembler section?)
I spent last night using the timestamp instruction to time fld dword [mem], will post later. Have to go on ward round!
|
|
Logged
|
|
|
|
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
|
|
|
|
|
