comp scene test.

[Shockwave]

Maybe change the integer definitions to uintegers.. That should yield a few more fps..

Do you have to allocate and deallocate the buffer each time you call the sub?
Maybe you could allocate it on startup and then deallocate it on exit..
That pointer stuff and the rgb conversion would definately benefit from being #defined

Looking good mate, there's still a good bit of fps to come from this though I am thinking.. It should go around 50 - 70 with ultra optimisation.

You could create an indexed colour palette too with a huge overflow area, you could get rid of 480,000 if, then checks then...

and also the rgb conversion...

The mind boggles

[ninogenio]

using uints and moving the alloc dealloc stuff out of the sub has me up another 5fps, i must be really rusty as this is stuff i just couldnt see.

also using a pallet buffer with more ellements than 255 is a great idea im going to try it.

one thing i dont get though is about the pointer stuff being #defined i just cant see how it would work/go any quicker with that. also what do you mean about rgb conversions? each int only holds a single byte worth of data on the bottom bits so no conversion is neccessary.

[Shockwave]

Glad to see that your fps is creeping up

The biggie here is going to be having a colour table to index and dispensing with all those if then checks.

About the rgb conversion, sorry about that. You have provided a sub, not your whole program (heaven knows why!), I have to guess what you do with the data later on.

That can be disregarded though because you'll be using an indexed palette instead, full framerate awaits you...

About #define..

I don't know why it speeds things up.
It seems to help though.

[hellfire]

I find it rather strange to discard the center-element in an averaging-filter.
Running a filter multiple times is less efficient than using a bigger filter-kernel once; you can't expect a 800x600-image to stay in the cache.
As pointed out earlier, you're cheaper off by performing separate horizontal/vertical passes.

[ninogenio]

@hellfire i would like to be able to do this in one pass as your right doing multiple passes is killing the performance but i dont know how.when you say a bigger filter-kernel what is meant by this? to use a bigger buffer?

also when you say that id be cheaper to do separate horizontal/verical passes does that mean just seperate them into diffrent loops?

[hellfire]

when you say that id be cheaper to do separate horizontal/verical passes does that mean just seperate them into diffrent loops?

A digital filter is nothing else than a matrix applied to an input-vector (in this case a piece of your image).
Let's assume two simple 1d matrices.

A horizontal one:

Code: [Select]

1 4 13 28 36 28 13 4 1
And a vertical one:

Code: [Select]

1
 4
13
28
36
28
13
 4
 1
Both do the same except that one takes a vertical piece of your image as input vector and the other one a horizontal piece.
You can multiply both matrices (just expanding both to 2d-layout by adding zeros) which results in a perfect 2d averaging matrix:

Code: [Select]

00 00 00 01 01 01 00 00 00
00 01 02 03 04 03 02 01 00
00 02 07 10 13 10 07 02 00
01 03 10 19 28 19 10 03 01
01 04 13 28 36 28 13 04 01
01 03 10 19 28 19 10 03 01
00 02 07 10 13 10 07 02 00
00 01 02 03 04 03 02 01 00
00 00 00 01 01 01 00 00 00

The 2d matrix, however, has 9*9= 81 coefficients while the 1d matrices just have a total of 18 coefficients.
So applying both 1d-filters sequentially is obviously faster and yields the same result.

[ninogenio]

ahh i get it  cheers hellfire.

thats simple and brilliant, i will try to get it going in practise.

[ninogenio]

something like this maybe hellfire.

Code: [Select]

Dim Shared As Integer sz = 50
Dim Shared As Integer kernelSize
KernelSize = 1 + sz * 2
Dim Shared As Integer kernel( KernelSize )
Dim Shared As Integer i

For I = 1 To Sz
    Dim As Integer szi = sz - i
    kernel( sz + i ) = (Szi) * (Szi)
    kernel( szi ) = (Szi) * (Szi)
Next
kernel( Sz ) = Sz * Sz

Dim Shared As Integer Ptr B2
B2 = CAllocate( 800*600 * SizeOf( Integer ) )

Sub Smooth2( TempBuffer As Integer Ptr , ByVal ScrWidth As Integer , ByVal ScrHeight As Integer )
   

    Dim As Integer sum,cr,cg,cb,k
    Dim As Integer pixel,re,ri,x,y,ym,riw
    Dim As Integer iw = 800

    Dim As Integer wh = 800*600

    Dim As Integer b( wh )
    sum = 0

    memcpy( @b( 0 ) , @TempBuffer[ 0 ] , 800 * 600 * SizeOf( Integer ) )
    Dim As Integer Ptr Temp
   
    For y = 0 To 599
        Temp = B2 + y*800
        For x = 0 To 799
            cb = 0
            sum = 0
            ri = x - Sz
            For i = 0 To kernelSize
                re = ri + i
                If ( re >= 0 And re < 800 ) Then
                    re += y*800
                    cb += b( re ) * Kernel( i )
                    sum += kernel( i )
                EndIf
            Next
            *Temp = ( cb / sum )
            Temp += 1
        Next
    Next
   
    Dim FCol As Integer
    Dim Temp2 As Integer Ptr
    Dim Temp3 As Integer Ptr
    For y = 0 To 599
      ym = y - sz
      riw = ym * iw
      Temp = B2 + riw
      Temp3 = TempBuffer + y*800
      For X = 0 To 799
        cb = 0
        sum = 0
        ri = ym
        Temp2 = Temp + X
        For i = 0 To kernelSize
            If ( ri < 600 And ri >= 0 ) Then
                cb += *Temp2 * kernel( i )
                sum += kernel( i )
            EndIf
            ri += 1
            Temp2 += iw
        Next
        FCol = *Temp3+( cb / sum )*3
        If FCol > 255 Then FCol = 255
        If FCol <0 Then FCol =0
       *Temp3 = FCol shl 16
        Temp3 += 1
      Next
  Next

End Sub

this produces an excellent and correct glow but its very slow(about 1-2 fps).

[hellfire]

its very slow (about 1-2 fps)

Code: [Select]

For i = 0 To kernelSize
  re = ri + i
  If ( re >= 0 And re < 800 ) Then
    re += y*800
    cb += b( re ) * Kernel( i )
    sum += kernel( i )
  EndIf
Next
*Temp = ( cb / sum )


For large filter-radii I wouldn't apply a gaussian at full resolution.
Downsample the image with a simple 2x2 box-filter to half the resolution, apply the gaussian (with half the radius) and upsample with a bilinear filter (which is very simple since only the "middle" colours are missing).

About the gaussian itself you shouldn't test each input-sample if it's inside the image boundaries.
Split each scanline into three sections: left, center and right.
On the left side (which is as wide as your filter-radius), samples can only be outside on the left side.
On the right side, samples can only be outside on the right side.
In the center region, all samples are inside the image boundaries, there's no need to test anything and "sum" stays constant!
You can now prescale your filter-kernel so that "sum" is a power of two (or accordingly bigger/smaller if you have intensity-scaling to do anyways) and the division can be replaced by a shift.

If you don't skip outside-samples (which changes "sum") but map these to the "boundary" sample (clamping), you can use the shifting-approach for the left/right-sections, too.
Let's assume your filter has a radius "r" and "kernel" ranges from 0 .. 2*r (inclusive) and kernel[r] corresponds to the center element.
When processing the left section, the number of outside samples decreases with each iteration:
For the first output-pixel, samples [0..r-1] are outside (access b(0) instead), sample [r..r*2] access b(0..r).
For the second output-pixel, samples [0..r-2] are outside, sample [r-1..r*2] access b(0..r+1) - and so on.
So you just have to keep track of the weight for b(0) which starts with sum(kernel[0..r]) (since you know the sum of the complete kernel this is for free, too) and decreases by kernel(x).
The right side works just the other way round. Use the same approach for the vertical pass with top/center/bottom.
Depending on the required precision you can process multiple samples at once (integers are 32bits wide).

Notice that you kernel function (pink) approximates a gaussian (green) rather well, but overestimates the center significantly:

(more of the unprocessed signal passes, less lowpass, more ringing).

[ninogenio]

wow thanks hellfire there is a lot too go through there but ill give it all a go k+

[ninogenio]

i never noticed that it was so off at the centre! looks like i have a bit more work todo iv attached the exe with this new function.

i may have some questions about splitting the scanlines into three sections as im not too sure about that i will have a go at it tomorrow though.

[ninogenio]

right i have spent the last few days trying loads of stuff out,

i managed to get the full gaussian blur up to about 10 fps, so what i ended up doing was coding a new box filter with a simple kernel that blurrs the image in two passes one vertical and one horizontal, im now getting 45 fps because i now draw everything in a 400*300 buffer. blurr that and then upsample to a 800*600.

the box filter doesnt look as nice as the gaussian but really i couldnt see the gaussian running at full frame rates. i must thank you though hellfire as iv learned loads from trying out all this stuff, i might even have a go at gaussian in shaders after the comp. 

[hellfire]

Well done, ninogenio! Looks great and runs in full framerate here.
Sometimes one of the triangles goes black.

[ninogenio]

cheers mate im glad you like it so far.

yeah there is a bug in my normals that needs fixing ill get on with developing it for the comp now .

[Shockwave]

It's a pleasure to see this running at a good framerate

Nice work Nino and fair play to Hellfire for the great information.

[ninogenio]

It's a pleasure to see this running at a good framerate

your telling me mate, i was really starting to stress about the deadline coming and not having even half of the demo done lol.

it was really just last night it all came together.

[Clyde]

Great Job Nino
It runs reasonably well on my system.
Btw, it is still a little bit too one colour. Or maybe thats the way its mean to be, in that case, I'll get my coat...

Cheers,
Clyde.

[ninogenio]

yeah i would have loved to be able to change the leds color at anytime but in keeping with the rules i stuck to a byte range of red for each led.