Getting my LED display working fast.

[Pixel_Outlaw]

I didn't;t plan on pulling out OpenGL for this comp but I may have to.

Currently I am using a 2d array to hold the intensity values of my LED lights. There are 16 different levels of brightness. At the start of the main loop I clear the light buffer array element by element using a for loop. (The canvas must not retain light patterns from the prior loop). I then update all of my objects and they draw their patterns to the light buffer array using ints for intensity. After all objects have updated I then draw the light graphics by looping through the light buffer. This seems to be fairly slow, not crippling but still leads to a choppy result. I have the feeling that the bottleneck lies in drawing 100x16 (1600) 8x8 sprites and setting the color using setcolor(r,g,b) for each one. Thoughts?

PS I also have a lookup array for the 16 levels' r,g,b values to save on computation cycles.

EDIT
I now clear the LED light buffer array index by index after I draw a light so that helps but it is still slow.

[hellfire]

I read your post three times and I still have no clue what you are doing.
A piece of code would've been much easier to understand.
What is that "light buffer array" about, why does it use ints when there are only 16 levels and how do you draw the sprites?

[Pixel_Outlaw]

The "light buffer array" is just a 2d array (100 elements by 16 elements) used to represent the sprite color values for each light. You are right, I changed it from an int array to a byte array forgot that numbers will be 0-16 which easily fits within the byte limits. I'm drawing sprites by calling the drawimage command. I'd like to do this with the native Blitzmax library if possible but if I need to go to OpenGL I can. The code will just bloat more for all of those image conversion and mapping and drawing commands. Does that help any?

Code: [Select]

Function interpolate_color3:color(r:Float, g:Float, b:Float, r2:Float, g2:Float, b2:Float, r3:Float, g3:Float, b3:Float, p:Float)
Local c:color = New color
'p is the decimal percent along the gradient
If p < 0.5
p= p /.5
Local result_red:Float = r + ((r2 - r) * p)
Local result_green:Float = g + ((g2 - g) * p)
Local result_blue:Float = b + ((b2 - b) * p)
c.set_rgb(result_red, result_green, result_blue)
Return c
EndIf
If p
p=p/1.0
' we now have to subtract .0.5 from p since we nove to the next gradient!
Local result_red:Float = r2 + ((r3 - r2) * p)
Local result_green:Float = g2 + ((g3 - g2) * p)
Local result_blue:Float = b2 + ((b3 - b2) * p)
c.set_rgb(result_red, result_green, result_blue)
Return c
  EndIf

EndFunction


' fill the intensity lookup table

For Local p:Float = 0 To 15
color_lookup[p] = interpolate_color3(0, 0, 0, 20, 70, 255, 128, 255, 255, Float(p) / 15)
Next



' fill the buffer
For Local x:Int = 0 To 99
For Local y:Int = 0 To 15
buffer[x, y] = 0
Next
Next

Global T:Int =0

While not KeyDown(KEY_ESCAPE)
Cls
update_game()
t:+1
If t=50
Local E:enemy = New enemy
e.x=96
e.y=rand(1,13)
e.timer=0
listaddlast(enemies,e)
t=0
End If


For Local x:Int = 0 To 99
For Local y:Int = 0 To 15
'is there any color there? check before drawing a sprite
If buffer[x,y]
SetColor(color_lookup[buffer[x, y]].r,color_lookup[buffer[x, y]].g,color_lookup[buffer[x, y]].b)
Drawoval(x * 8, y * 8,8,8)
setcolor(255,255,255)
DrawImage(light, x * 8, y * 8, 1)
EndIf
' clear that pixel after drawing
buffer[x,y]=rand(0,5)
Next
Next

Flip
Wend


[Pixel_Outlaw]

Just solved the bottleneck.\

I ended up drawing circle shapes then applying an sprite overlay that had all 1600 light shines on top of the circles. This formed acceptable performance at 60 frames per second while maintaining the detailed light reflection/shading of each bulb.

[hellfire]

Good to hear you already sorted it out.
In contrast to drawImage, the drawOval function appears to be very slow for some reason, so instead you could simply use an image, too.

[Pixel_Outlaw]

 

Thanks, I noticed that drawrect is actually very fast so I may use that with some form of masking to get the round lights. All hard to explain with words.

I thought the divide and conquer rule was usually faster but it seems that it is faster to draw a single large sprite in this case than 1600 smaller sprites. Then again could be all of the setcolor commands.

[zawran]

It is not the drawing that is the problem, but the setcolor since its a state change. And state changes slows things down. You might get a speed increase if you batch the same colored objects together so that you limit the state changes to just a few instead of possibly changing it for each light.

[Shockwave]

Is it possible to use something like gldisplaylists in blitzmax?

[ninogenio]

i think so shockwave,

ive never used it but i think it has the full opengl library inplemented, i think it would require quite a fundemental change to p.o's engine to render things in gl though.

its a shame you arent yousing freebasic/ptc for this p.o as right now i have 7500 double buffered led's totally unoptimzed with a full byte range of contrast running at fully interactive rates with quite a few effects.

[Pixel_Outlaw]

Yeah, I was considering using OpenGL for this but I want to have some sprite commands too and I am sort of frusterated with all of the extra code generated to texturemap quads. I may look into it after this project because I know there is some AMAZING speed to be gained.