Code:
'$include: 'tinyptc.bi'
const SCR_WIDTH% = 640*1
const SCR_HEIGHT% = 480*1
const SCR_SIZE% = SCR_WIDTH*SCR_HEIGHT'
if( ptc_open( "my stuff", SCR_WIDTH, SCR_HEIGHT ) = 0 ) then
end -1
end if
DIm buffer( 0 to SCR_SIZE-1 )
t! = Timer
Do
k$ = Inkey$
frames = frames + 1
For a=0 to 1000
x = (SCR_WIDTH-1) * Rnd
y = (SCR_HEIGHT-1) * RND
Red = 255*Rnd
Green = 255*Rnd
Blue = 255*Rnd
buffer(y*SCR_WIDTH + x) = Red+Green*256+Blue*65536
Next
ptc_update @buffer( 0)
locate 1,1
If (timer-t!) > 0 Then print frames / (timer-t!)
If (timer-t!) > 1 Then t! = Timer: frames = 0
Loop while k$ = ""
ptc_close
If I minimize one of the windows, i easily get 100FPS..
Why is print so slow?
EDIT: If I focus on the Text window, and not the graphics window, i get fluid FPS, around 100, if I focus on the gfx window, it still says ~100FPS, but it only draws stuff about once every second...
Windows, i guess.. all printing is done using the Win32 api, nothing complex being done there.
While the gfx window has the focus, the console one will wait until Windows decides to update it, the priotity is probably very low, as the gfx part is taking 100% of CPU time - console windows for apps that create non-console windows are normally used for debugging only.
Btw, you don't need a console open when working with TinyPTC, i hacked it to pass the keycodes down to inkey$. Extended codes won't work tho.
Setting the window's title showing the FPS like mandbrot.bas does would be better - and compiling as a gui app with "-s gui".
Btw, it's red shl 16 + green shl 8 + blue.
Meaning?
shl is?
And what bit depth is tinyptc anyways...
TinyPTC is designed to work best in 32bpp mode, but the vanilla TinyPTC has converters that convert to any decent bitdepth. I dunno about the FB implementation...were the MMX modules converted too?
shl = "shift left" it's a cpu instruction, that tacks a zero on the end of a binary number and lops off the beginning. Shifting by one is a fast way of multiplying by 2. "shl" is what you use in x86 assembly. shr shifts right and divides.
x shl 8 = x * 2^8
x shr 8 = int(x / 2^8)
01000101 shl 1 = 10001010
Only that. FB uses SAR/SAL. :*) So much the better.
And v1c: Inline Functions?
SAR and SAL? What's the 'a' stand for?
And didn't QB just use shifts anyway for multiplying by a power of two?
Zire, add this line somewhere in the beginning of your program...
Don't ask me why, but it works on my stuff!
Quote:SAR and SAL? What's the 'a' stand for?
And didn't QB just use shifts anyway for multiplying by a power of two?
Shift = Unsigned shift
SAR/SAL = signed shift
Frankly, I like FB's implementation that shifts should use signed shifts as opposed to delphi that uses unsigned ones even on unsigned ints.
I don't know about QB's compiler. It prolly does.
Sar = Shirft Arithmetic Right