A Beautiful accident! Weird, take a look..

[Rattrapmax6]

tnx can't wait :bounce:

:bounce: http://forum.qbasicnews.com/viewtopic.ph...2e1a3a8295 :wink:

[Mitthrawnuruodo]

Hey you learned 3D...nice!

Ummm...the wormholes were...interesting....

:o That beautiful accident..... :o .... :o it made my mind thrown into loops from seeing 1 pixel being shot around the screen at 500000 fps.... :o

[Rattrapmax6]

Hey you learned 3D...nice!

Ummm...the wormholes were...interesting....

:o That beautiful accident..... :o .... :o it made my mind thrown into loops from seeing 1 pixel being shot around the screen at 500000 fps.... :o

3D? yeah, most of it, or enough to better under stand OGL.. might just learn all of it if I can... ... lil stuck on applying full 3d rots on x and y, (z seems fine).. my "A Beautiful Accident" was a revert attempt of that, still its my fav gfx demo yet!!!

[dumbledore]

lol, i got another 500,000 fps on my computer with this code instead: (again making the input thing faster)

Code:

declare sub exitthread()

dim shared F as integer,T!
SCREEN 19, 32, 2,'1 'I can't run gfxlib in full screen :(

'mangleberry pie    :D
#DEFINE Pi 3.14 '15926535897932

x! = 150
y! = 150
z! = 150

Dim shared tSin(360) as Single, tCos(360) as Single

For i = 0 to 360
tSin(i) = SIN(i * (Pi/180))
tCos(i) = COS(i * (Pi/180))
Next

centx = 400
centy = 300
LENS = 256 ' centz

ax = 0
ay = 0
az = 0
threadcreate @Exitthread,0
T! = TIMER
DO
   cx! = tCos(ax)
   sx! = tSin(ax)
   cy! = tCos(ay)
   sy! = tSin(ay)
   cz! = tCos(az)
   sz! = tSin(az)
  

   ny! = (y! * cx!)-(z! * sx!)
   nz! = (z! * cx!)+(y! * sx!)
   y! = ny!
   z! = nz!
   nz! = (z! * cy!)-(x! * sy!)
   nx! = (x! * cy!)+(z! * sy!)
   x! = nx!
   nx! = (x! * cz!)-(y! * sz!)
   ny! = (y! * cz!)+(x! * sz!)
  
   ax += 1
   If ax > 360 then ax -= 360
  
   ay += 1
   If ay > 360 then ay -= 360
  
   az += 1
   If az > 360 then az -= 360
  
   PSET (centx + nx!, centy - ny!), RGB(z!, z!, z! )
   F += 1
LOOP

sub exitthread()
   do
      do:sleep 10:loop until multikey(&h1C) or multikey(1)
      endtime!=TIMER
      locate 1,1
      PRINT "Average FPS:"; F / (endtime! - T!)
   loop until multikey(1)
   end
end sub

total fps was over 3,300,000

[dimsheep]

about that lookup table stuff... to keep it simple, this applies to anything from the pentium on (copied from "cache consciousness" by chris russ):

Try not to use Look Up Tables unless
they are very small: In the old days,
the processors were slow, so it was
worth precomputing things. Now,
often the time spent to look up data
(and push other meaningful data out
of the L1 and L2 caches) is longer than
the time spent recomputing the data.
This is not always true, but you'd be
surprised. However, anything that
reduces the apparent size of L1 can
have a big impact on the execution
speed of your processor.

however, i don't think this applies to qb, because the code that qb generates is so awfully slow that it's still faster to use lookup tables. just my estimate.

[Dr_Davenstein]

Well, that's not a QB program... it was a demo-thing that rattra made in FB. Lut's do still speed programs up though, even in C/C++. I mean, if you had a really old QB program, probably something that was coded before 1990, you would different kinds of lut's to make it run faster. Such as a lut to calculate the pixel position in a buffer when it only requires integer mul's to calculate. That would be a waste, and maybe even slower to look up. With the trig functions though... I haven't seen a program yet that doesn't run faster by looking those up.

[dimsheep]

oh, i forgot for a moment that we were talking about an fb program. but...

With the trig functions though... I haven't seen a program yet that doesn't run faster by looking those up.

the fpu has fsin/fcos instructions. i'd say using those can be faster than looking up data.

[keeling]

But it hasn't been... that's the point of all of this. On every machine that has tried it there has been an amazing jump in the fps when lut have been used.

And doesn't it make sense? With the trig functions you have to (simplified)

1) look up the value of the variable
2) do the command (which I assume is either a truncated Taylor expansion or a lut with interpolation) on that value
3) use it

But with a lut you
1) look up the value
2) use it

The biggest step is gone. I read the paper and there are few items I am a little cautious about. There are a few details left out (how big is big for example).

Theory is a great guide for experimenters, but it is always experimentation that shapes theory. In another example it maybe true that on chip trig will be faster but here we have to score one for the experimenters!

[Rattrapmax6]

:rotfl: lol, know Dr_D is calling me "Rattra", go figure, no worries, heh heh..

Um, Dimsheep, why not try it insted of talk bout it, put it to the test... it is open source BTW.. :wink:

[1000101]

THe original code I got ~330K pixels per second (FPS), my version gets ~1.4M pixels per second (FPS).

With the pset lines commented in both, mine gets ~8.4M pixels per second and the original gets ~726K pixels per second.

This should defeat any "LUTs are slower" arguement, especially since mine is huge (32K).

Code:

Option Explicit

'' Speaking of precompute, let's precompute everything

Const Accuracy        =    8191                            '' More accurate the degrees and it's aligned
Const Pi                =    3.15926535897932            '' Do we need more accuracy?
Const Deg2Rad        =    Pi / 180                        '' Degrees to Radians multiplier
Const Deg2Byte        =    360 / ( Accuracy + 1 )    '' Accuracy bits to degrees multiplier
Const Byte2Rad        =    Deg2Byte / Deg2Rad        '' Accuracy bits to radians multiplier

Const CentX            =    400                            '' Centre of screen (X)
Const CentY            =    300                            '' Centre of screen (Y)
Const LENS            =    256                            '' Centre of screen (Z)


Dim tSin( 0 To Accuracy ) As Single                '' -+_ I like to force
Dim tCos( 0 To Accuracy ) As Single                '' -+  all ranges.

'' Define everything explicitly!

Dim I As Integer

Dim aX As Integer
Dim aY As Integer
Dim aZ As Integer

Dim X As Single
Dim Y As Single
Dim Z As Single

Dim cX As Single
Dim cY As Single
Dim cZ As Single

Dim sX As Single
Dim sY As Single
Dim sZ As Single

Dim nX As Single
Dim nY As Single
Dim nZ As Single

Dim T As Single
Dim F As Integer


For i = 0 To Accuracy
   tSin( i ) = Sin( i * Byte2Rad )
   tCos( i ) = Cos( i * Byte2Rad )
Next


SCREEN 19, 32, 2, 1

X = 150
Y = 150
Z = 150

ax = 0
ay = 0
az = 0
T = Timer
Do

   '' Use LUTs
   cX = tCos( aX )
   sX = tSin( aX )
   cY = tCos( aY )
   sY = tSin( aY )
   cZ = tCos( aZ )
   sZ = tSin( aZ )

    '' v3cz0r math
   nY = ( Y * cX ) - ( Z * sX )
   nZ = ( Z * cX ) + ( Y * sX )
   Y = nY
   Z = nZ
   nZ = ( Z * cY ) - ( X * sY )
   nX = ( X * cY ) + ( Z * sY )
   X = nX
   nX = ( X * cZ ) - ( Y * sZ )
   nY = ( Y * cZ ) + ( X * sZ )

   aY = ( aY + 1 ) And Accuracy
   aX = ( aX + 1 ) And Accuracy
   aZ = ( aZ + 1 ) And Accuracy

    '' Display it
   PSet ( CentX + nX , CentY - nY! ), RGB( Z, Z, Z )

    '' Inc frames
   F += 1

Loop Until ( Multikey( 1 ) )

Screen 0

Print "Average PPS:"; F / ( Timer - T )

End