Author |
Topic: GFXLIB (Read 2281 times) |
|
David Williams
Developer
member is offline
meh
Gender: 
Posts: 452
|
 |
Re: GFXLIB
« Reply #87 on: Jun 8th, 2009, 4:05pm » |
|
on Jun 8th, 2009, 09:10am, Richard Russell wrote:| Later: I've modified the Intel code to work with 32-bpp input and output. On my PC it's taking 2.2ms for a 640x480 image. Are you interested in it... ? |
|
In one word: Yes !
I am definately interested in it, thank you.
Now...
I recently knocked-up an MMX version of a supposedly optimised '50%' alpha blender (simply averages
the RGB32 colour values of corresponding foreground and background pixels). Here's the inner loop
from the non-MMX version:
Code: mov edx, [edi + 4*esi] ; load RGB32 pixel from source bitmap
mov ebx, [ecx + 4*esi] ; load RGB32 pixel from dest addr
and edx, &FEFEFE
and ebx, &FEFEFE
shr edx, 1
shr ebx, 1
add edx, ebx
mov [ecx + 4*esi], edx ; write RGB32 pixel to destination bitmap buffer
Here's my MMX version, operating on four pixels per iteration of the inner X-loop:
Code: .GFXLIB_MMXBPlotAvgNC__xloop
mov ebx, ecx
shl ebx, 4
movq mm1, [edi + ebx + 0] ; load 2 pxls from bg \
movq mm2, [esi + ebx + 0] ; load 2 pxls from srcBm \
; ; > 4 pixels
movq mm3, [edi + ebx + 8] ; load 2 pxls from bg /
movq mm4, [esi + ebx + 8] ; load 2 pxls from srcBm /
pand mm1, mm0
pand mm2, mm0
pand mm3, mm0
pand mm4, mm0
psrld mm1, 1
psrld mm2, 1
psrld mm3, 1
psrld mm4, 1
paddd mm1, mm2
paddd mm3, mm4
movq [edi + ebx + 0], mm1
movq [edi + ebx + 8], mm3
dec ecx
jge GFXLIB_MMXBPlotAvgNC__xloop
To my amazement, it's really no faster (or just marginally so) than the non-MMX version.
I was expecting something approaching a 2x speed improvement. :-(
David.
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #88 on: Jun 8th, 2009, 5:35pm » |
|
Quote:| To my amazement, it's really no faster (or just marginally so) than the non-MMX version. |
|
I'm amazed that you were amazed! Your code really takes no advantage of the MMX features at all (e.g. parallel operation on up to 4 independent values, automatic clipping of results etc.). Really all you're doing is using 64-bit wide registers rather than 32-bit wide registers.
In addition to this, the operations you are performing (basically just an AND and a SHIFT) are so simple the likelihood is that the speed is determined largely by the bottleneck of getting the data out of and into memory, and not by the processing. Since exactly the same amount of data is transferred in each case, it's not surprising the speed is similar.
(Incidentally I assume you ensured your data was always QWORD-aligned; if it isn't the MMX method will be substantially slower than it otherwise would be).
Quote:| I am definately interested in it, thank you. |
|
Here's my alphablending code. I would hope and expect it to be substantially faster than a non-MMX version:
Code: ;
; eax = pointer to array of 32-bit ARGB pixels ('foreground')
; ebx = pointer to array of 32-bit xRGB pixels ('background')
; ecx = pixel count DIV 2
;
.roundf dd &00800080 : dd &00000080
;
.blend
mov esi, eax ; foreground pointer
mov edi, ebx ; background pointer
movq mm4, [roundf] ; mm4 = 0000 0080 0080 0080 (rounding factor)
pxor mm5, mm5 ; mm5 = 0000 0000 0000 0000
.blendloop
movq mm6, [esi] ; mm6 = a2r2 g2b2 a1r1 g1b1 (foreground)
movq mm7, [edi] ; mm7 = xxR2 G2B2 xxR1 G1B1 (background)
movq mm0, mm6 ; mm0 = xxxx xxxx a1r1 g1b1
movq mm2, mm7 ; mm2 = xxxx xxxx xxR1 G1B1
punpcklbw mm0, mm5 ; mm0 = 00a1 00r1 00g1 00b1 (p1)
punpcklbw mm2, mm5 ; mm2 = 00xx 00R1 00G1 00B1 (q1)
movq mm1, mm0 ; mm1 = 00a1 xxxx xxxx xxxx
punpckhwd mm1, mm1 ; mm1 = 00a1 00a1 xxxx xxxx
punpckhdq mm1, mm1 ; mm1 = 00a1 00a1 00a1 00a1
psubw mm0, mm2 ; mm0 = p1 - q1
psllw mm2, 8 ; mm2 = q1 * 256
paddw mm2, mm4 ; mm2 = q1 * 256 + 128
pmullw mm0, mm1 ; mm0 = (p1 - q1) * a1
paddw mm2, mm0 ; mm2 = (p1 - q1) * a1 + q1 * 256 + 128
psrlw mm2, 8 ; mm2 = xxxx 00R1 00G1 00B1
psrlq mm6, 32 ; mm6 >>= 32 for second pixel
psrlq mm7, 32 ; mm7 >>= 32 for second pixel
movq mm0, mm6 ; mm0 = xxxx xxxx a2r2 g2b2
movq mm3, mm7 ; mm3 = xxxx xxxx xxR2 G2B2
punpcklbw mm0, mm5 ; mm0 = 00a2 00r2 00g2 00b2 (p2)
punpcklbw mm3, mm5 ; mm3 = 00xx 00R2 00G2 00B2 (q2)
movq mm1, mm0 ; mm1 = 00a2 xxxx xxxx xxxx
punpckhwd mm1, mm1 ; mm1 = 00a2 00a2 xxxx xxxx
punpckhdq mm1, mm1 ; mm1 = 00a2 00a2 00a2 00a2
psubw mm0, mm3 ; mm0 = p2 - q2
psllw mm3, 8 ; mm3 = q2 * 256
paddw mm3, mm4 ; mm3 = q2 * 256 + 128
pmullw mm0, mm1 ; mm0 = (p2 - q2) * a2
paddw mm3, mm0 ; mm3 = (p2 - q2) * a2 + q2 * 256 + 128
psrlw mm3, 8 ; mm3 = xxxx 00R2 00G2 00B2
packuswb mm2, mm3 ; mm2 = xxR2 G2B2 xxR1 G1B1 (result)
movq [edi], mm2 ; save result
mov byte [edi+3],0 ; zero 'alpha' of pixel 1 (if necessary)
mov byte [edi+7],0 ; zero 'alpha' of pixel 2 (if necessary)
add esi, 8 ; next pixel-pair (foreground)
add edi, 8 ; next pixel-pair (background)
loop blendloop
emms
ret
I haven't done any extensive 'pairing' optimisation so there's a possibility it could be made more efficient.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #89 on: Jun 9th, 2009, 06:24am » |
|
on Jun 8th, 2009, 5:35pm, Richard Russell wrote:| I'm amazed that you were amazed! Your code really takes no advantage of the MMX features at all (e.g. parallel operation on up to 4 independent values, automatic clipping of results etc.). Really all you're doing is using 64-bit wide registers rather than 32-bit wide registers. |
|
I thought I was operating on two pixels in parallel (four pixels per iteration of the inner loop); the operations on the second pixel of each pair being almost 'free'.
on Jun 8th, 2009, 5:35pm, Richard Russell wrote:| (Incidentally I assume you ensured your data was always QWORD-aligned; if it isn't the MMX method will be substantially slower than it otherwise would be). |
|
No, I didn't! But I sure as heck do now. I've modified GFXLIB's bitmap loading routine to ensure that the start address of the data is divisible by 8. I notice that the DIB section ('screen memory') base address always seems to be QWORD-aligned, too. So, all data is now QWORD-aligned.
on Jun 8th, 2009, 5:35pm, Richard Russell wrote:| Here's my alphablending code. I would hope and expect it to be substantially faster than a non-MMX version: |
|
Beautiful... thanks. I've done some timing and frame rate tests involving your MMX routine, a more recent non-MMX routine that I had believed was fast and not far from being optimal, and a what-I-thought-was the stinky old GFXLIB alphablend routine (GFXLIB_BPlotAlphaBlend2). The results are surprising and a bit puzzling.
Here are the timing results of alphablending two 640x512 32bpp bitmaps, 1000 blends (times given in seconds):
Your MMX routine: 2.4
New supposedly fast non-MMX routine: 5.6
'Old' GFXLIB_BPlotAlphaBlend2 routine: 3.0
So, MMX wins. But... it doesn't seem to be that much faster than GFXLIB_BPlotAlphaBlend2.
Compare the code from the inner loop of the new non-MMX alphablend routine with that of the old GFXLIB_BPlotAlphaBlend2:
New non-MMX
Code: ._esp dd 0 ; will be temporarily stashing ESP in here
.blend2
; EAX = fg
; EBX = bg
; ECX = pixel count
mov [_esp], esp ; naughty ;-)
mov esp, eax ; ESP = fg
.blend2_lp
mov esi, [esp + 4*ecx - 4] ; fg pxl (ARGB)
mov edi, [ebx + 4*ecx - 4] ; bg pxl (xRGB)
mov ebp, esi ; extract alpha value from src ARGB pxl
; EBP is shifted (>> 24) later (aids pipelining ?)
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
shr ebp, 24
adc ebp, 0
;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
mov [ebx + 4*ecx - 4], eax ; write alpha-blended pixel
loop blend2_lp
mov esp, [_esp]
ret
Old GFXLIB_BPlotAlphaBlend2
Code: .GFXLIB_BPlotAlphaBlend2__xloop
movzx edx, BYTE [edi + 4*esi + 3] ; load alpha mask byte
neg edx
add edx, 255
imul edx, (1.0/255.0)*(2^20) ; = mulfac
movzx eax, BYTE [edi + 4*esi + 2] ; load src bmp Red byte
movzx ebx, BYTE [ecx + 4*esi + 2] ; load dst bmp Red byte
sub ebx, eax ; (dst - src)
imul ebx, edx ; mulfac*(dst - src)
shr ebx, 20 ; (mulfac*(dst - src)) >> 20
add eax, ebx
mov BYTE [ecx + 4*esi + 2], al
movzx eax, BYTE [edi + 4*esi + 1] ; load src bmp Green byte
movzx ebx, BYTE [ecx + 4*esi + 1] ; load dst bmp Green byte
sub ebx, eax ; (dst - src)
imul ebx, edx ; mulfac*(dst - src)
shr ebx, 20 ; (mulfac*(dst - src)) >> 20
add eax, ebx
mov BYTE [ecx + 4*esi + 1], al
movzx eax, BYTE [edi + 4*esi + 0] ; load src bmp Blue byte
movzx ebx, BYTE [ecx + 4*esi + 0] ; load dst bmp Blue byte
sub ebx, eax ; (dst - src)
imul ebx, edx ; mulfac*(dst - src)
shr ebx, 20 ; (mulfac*(dst - src)) >> 20
add eax, ebx
mov BYTE [ecx + 4*esi + 0], al
dec esi ; X -= 1
jge GFXLIB_BPlotAlphaBlend2__xloop ; loop if X >= 0
How could GFXLIB_BPlotAlphaBlend2 possibly be faster than the new non-MMX routine? I'd like to know where the bottleneck lies with the new non-MMX routine.
BPlotAlphaBlend2 has 10 memory accesses (7 reads, 3 writes) per pixel.
New non-MMX has just 3 memory accesses (2 reads, 1 write) per pixel.
BPlotAlphaBlend2 has 4 multiply instructions (IMUL) per pixel. New non-MMX has 2.
Both routines have roughly the same number of instructions (26) in the inner loop.
ADC
The ADC instruction in the non-MMX routine is quite an execution speed killer, it would seem. Removing the ADC ebp,0 instruction (which is probably largely superfluous) lops off an incredible 2 seconds! So the new league table is as follows:
Your MMX routine: 2.4
'Old' GFXLIB_BPlotAlphaBlend2 routine: 3.0
New non-MMX routine (without ADC instruction): 3.5
New non-MMX routine: 5.6
Still, GFXLIB_BPlotAlphaBlend2 is the faster non-MMX routine.
Timing and frame rate test programs (executables)
The frame rate test programs are largely identical, except a different alphablending routine is used in each case.
Richard's MMX routine (averages 226 fps on my PC):
http://www.bb4w-games.com/138519651/alphablend_mmx.zip (1 MB)
'Old' GFXLIB_BPlotAlphaBlend2 routine (averages 206 fps on my PC):
http://www.bb4w-games.com/138519651/alphablend_bplotalphablend2.zip (1 MB)
New non-MMX routine (averages 127 fps on my PC):
http://www.bb4w-games.com/138519651/alphablend_non-mmx.zip (1 MB)
New non-MMX routine without ADC instruction (averages 174 fps on my PC):
http://www.bb4w-games.com/138519651/alphablend_non-mmx_no-adc.zip (1 MB)
Timing tests:
http://www.bb4w-games.com/138519651/alphablend_timingtest_2.zip (1 MB)
By the way, I've been repeatedly referring to the 'New' non-MMX routine -- I don't intend to replace BPlotAlphaBlend2 with it until I can figure out (or someone else can tell me) where the bottleneck lies with it. Just to reiterate, New non-MMX *should* be faster than BPlotAlphaBlend2, but it isn't.
Anyway, Richard, your MMX-powered alphablending routine would be a fine and very welcome addition to GFXLIB (if I may !?).
Thanks again.
David.
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GFXLIB
« Reply #90 on: Jun 9th, 2009, 08:52am » |
|
Quote:| I thought I was operating on two pixels in parallel |
|
Because of the processor's superscalar architecture, it's entirely possible your non-MMX version was processing "two pixels in parallel" too. Anyway, as I said, they may both have been memory-bandwidth bound, in which case the speed would be much the same.
Quote:| The ADC instruction in the non-MMX routine is quite an execution speed killer, it would seem. |
|
As I expect you appreciate, it's not that ADC is particularly slow but it's because of the dependencies it introduces. You have to think of the effect of the instruction not on its own, but in the context of the instructions which surround it.
In this particular case the main significance is that since adc ebp,0 depends on the state of the carry flag, and since the preceding shr ebp,24 affects the carry flag, the two instructions are forced to be serialised and run on the same execution unit.
I expect that, when you remove the ADC, it gives the processor more opportunity to take advantage of out-of-order execution, and of scheduling instructions on the different execution units. Therefore the speed improvement is disproportionate to the time taken by the ADC in isolation.
It's for this kind of reason that modern compilers can sometimes beat 'hand assembly' for speed. They understand (better than the average human programmer!) the internal architecture of the CPU, and when it can be of benefit to change the sequence of instructions to improve performance even if the clarity of the code suffers.
Whether a similar issue explains the 'anomalous' speed difference between your two non-MMX versions I can't say, but it may do.
Quote:| Anyway, Richard, your MMX-powered alphablending routine would be a fine and very welcome addition to GFXLIB (if I may !?). |
|
Of course you may, with the appropriate grovelling acknowledgement!!
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #91 on: Jan 1st, 2010, 6:57pm » |
|
http://www.bb4w-games.com/bb4wprogs/superposealphamapdemo.zip
This demo employs a few new(-ish) GFXLIB routines:
* Richard's MMXAlphaBlend
* PlotBlendLD (LD = Luminosity-Dependent)
* MMXScale2X -- fast 2x scaling of a bitmap
* SuperposeAlphaMap -- Superposes (or should that be Superimposes?) an alpha map (or mask) over a bitmap
* BoxBlur3x3
This is all rather burdensome for the CPU, and I'm sure a similar effect can be achieved much more efficiently by other means, but really the point of the demo is to er... demonstrate SuperposeAlphaMap.
Regards,
David.
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #93 on: Jan 9th, 2010, 8:38pm » |
|
Another day, another GFXLIB routine.
This one's called PlotRearrangeInvertRGB.
(Yikes !)
It rearranges the RGB colour components of every non-black pixel in a given bitmap, and then inverts the specified RGB components, then plots the pixel.
Code:SYS GFXLIB_PlotRearrangeInvertRGB%, dispVars{}, bmAddr, bmW, bmH, x, y, rgbRearrangementCode, rgbInversionFlags
The RGB rearrangement parameter is an integer in the range 0 to 5:
0. RGB (no rearrangement)
1. RBG
2. GRB
3. GBR
4. BRG
5. BGR
The RGB inversion flags parameter:
bit 0 ---> invert Red value
bit 1 ---> invert Green value
bit 2 ---> invert Blue value
So supplying a value of 1 for the inversion flags parameter will result in the red channel being inverted, 6 would result in both green and blue channels being inverted, etc.
Here's a demo of the routine (the above colour-transforming operation is applied in real-time in this program):
http://www.bb4w-games.com/bb4wprogs/plotrearrangeinvertrgb_demo.zip
Below is the original, unadulterated 64x64 ball bitmap (from the demo):
I may soon post a question in the Assembly Language section on what is the fastest possible way of rearranging and/or inverting RGB components of a pixel, because I'm probably doing it in one of the slowest ways.
Regards,
David.
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #95 on: Feb 6th, 2010, 10:01am » |
|
Thought I'd post this as it looks quite pretty (and uses not much CPU bandwidth):
http://www.bb4w-games.com/bb4wprogs/plotpixellist3_ex4.zip
Yes, OK, the Bézier curves are precalculated, but only because if they had to be calcluated in real time (in BASIC), the CPU usage would shoot right up (to ~50% on my laptop). The actual plotting of the curves takes next-to-no time.
What's supposed to be being demonstrated here is a new (but not terribly exciting) GFXLIB routine PlotPixelList3, which is faster and more flexible than the first two.
Interested folks might like to keep an eye on this page over the coming weeks:
http://www.bb4w-games.com/gfxlib2/gfxlib2page.html
Regards,
David.
|
|
|
|
81RED
Guest
|
|
Re: GFXLIB
« Reply #96 on: Feb 6th, 2010, 10:34am » |
|
on Feb 6th, 2010, 10:01am, David Williams wrote:
Yay!
Any benefits to be gained from recoding my stuff to use the new version (other than smaller code, which does not bother me), or is that better left off until my next project actually happens?
Simon
P.S. Weren't you supposed to be in rehab? 
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #97 on: Feb 6th, 2010, 11:29am » |
|
on Feb 6th, 2010, 10:34am, Simon Mathiassen wrote:Yay!
Any benefits to be gained from recoding my stuff to use the new version (other than smaller code, which does not bother me), or is that better left off until my next project actually happens?
|
|
Not really. The routines may have been 'modularized', but they haven't (yet) been optimized or improved in any other way.
A multicore version of the 'workhorse' routine BPlot - the one you'd normally use to draw backgrounds - may be in the pipeline. Whilst I doubt that four cores would necessarily translate to "four times faster" (which would be nice), BPlot (and Plot, as it happens) are such frequently used routines that it may be worthwhile trying to produce multicore/multithreading versions of them. The skills of Michael Hutton and/or Richard may (or rather, will) be indispensable here.
(Not that I would ever take either of them for granted, let me just say.)
on Feb 6th, 2010, 10:34am, Simon Mathiassen wrote:| P.S. Weren't you supposed to be in rehab? |
|
I evidently appear to be slipping.
Regards,
David.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #98 on: Feb 11th, 2010, 9:49pm » |
|
Here is a simple demo of a new routine called DrawTileMap:
(Use the arrow keys to move around)
http://www.bb4w-games.com/bb4wprogs/tilemapdemo1.zip
Using DrawTileMap is simplicity itself. First you need a set of tile bitmaps (all of the same dimensions - 64x64 is quite typical). Then you create a tile map using a map editor (a simple one will ship with GFXLIB 2). Then once you've installed and initialised GFXLIB 2, DrawTileMap and TileMapFunctions, and loaded the tile map with PROCLoadTileMap, you draw the portion of the map you wish to display using:
Code:SYS GFXLIB_DrawTileMap%, dispVars{}, mapInfo{}, x%, y%
Simple as that.
Something to look forward to, right?
Regards,
David.
PS. There will be a number of routines for converting between screen and map world coordinates, and routines intended for the purposes of collision detection. In fact, the following routines are already in place (with lots more to come):
Code:GFXLIB_TMConvertScrCoordsToWorldCoords% | *mapInfoStruc{}, scrX%, scrY%, *worldX%, *worldY%
GFXLIB_TMConvertWorldCoordsToScrCoords% | *mapInfoStruc{}, worldX%, worldY%, *scrX%, *scrY%
GFXLIB_TMConvertScrCoordsToWorldCoordsF64% | *mapInfoStruc{}, *scrX#, *scrY#, *worldX%, *worldY%
GFXLIB_TMConvertWorldCoordsToScrCoordsF64% | *mapInfoStruc{}, *worldX#, *worldY#, *scrX%, *scrY%
GFXLIB_TMGetTileIndexAtWorldPos% | *mapInfoStruc{}, worldX%, worldY% (returns tile index in EAX)
GFXLIB_TMGetTileIndexAtScrPos% | *mapInfoStruc{}, scrX%, scrY% (returns tile index in EAX)
GFXLIB_TMGetPixelAtWorldPos% | *mapInfoStruc{}, worldX%, worldY% (returns 32-bit ARGB pixel in EAX)
GFXLIB_TMGetPixelAlphaValueAtWorldPos% | *mapInfoStruc{}, worldX%, worldY% (returns 8-bit alpha value in EAX)
GFXLIB_TMTestPixelAlphaBitAtWorldPos% | *mapInfoStruc{}, worldX%, worldY%, testBit% (returns 0 or 1 in EAX)
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: GFXLIB
« Reply #99 on: Feb 12th, 2010, 02:12am » |
|
Very nifty piece of work!
My question is: What do the * mean in
*mapInfoStruc{}, *worldX#, *worldY#, *scrX%, *scrY%
I presume they are not C++ pointers?! Or is this a new type of BB4W addressing mode I haven't come accross?
Michael
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: GFXLIB
« Reply #100 on: Feb 12th, 2010, 02:49am » |
|
on Feb 12th, 2010, 02:12am, Michael Hutton wrote:My question is: What do the * mean in
*mapInfoStruc{}, *worldX#, *worldY#, *scrX%, *scrY%
I presume they are not C++ pointers?! Or is this a new type of BB4W addressing mode I haven't come accross?
|
|
Actually, I don't think it was correct of me to prefix mapInfoStruc{} with an asterisk.
Yes, an asterisk indicates that the parameter is a pointer to a memory location that contains (or is to contain) either an integer or a 64-bit float.
I realise that 32-bit floats can be supplied 'directly' using FN_f4, but it's probably not suitable for heavy use within a game loop.
By the way, those comments are really just notes to myself. I don't normally use asterisks to indicate pointer variables! I might from now on, though.
Regards,
David.
|
|
Logged
|
|
|
|
Richard Russell
Guest
|
|
Re: GFXLIB
« Reply #101 on: Feb 12th, 2010, 08:11am » |
|
on Feb 12th, 2010, 02:49am, David Williams wrote:| I don't normally use asterisks to indicate pointer variables! I might from now on, though. |
|
Is there a particular reason why you don't use ^, to reflect the syntax you'd use if calling the routine from BASIC?
Richard.
|
|
Logged
|
|
|
|
|
