QB Graphics for FB, preview release with source code

[relsoft]

FLIP is the culprit. Try to pset w/o flipping.

[barok]

i tried fb without flip again, and the results.... were about 4000 pixels more than the optimized qb code. the qb code used a ylut and poked directly to the screen

fb: 16000

running primitives test 8 seems to give 147,000+ psets a second... it puzzles me why i can't achieve this. :???:

::EDIT::

i just changed the screen mode to screen 12. I promptly achieved 50000+ psets a sec. Much better than screen 13, but still nowhere as good as sterling's tests. His code seems to be the same as mine for this test, with the exception that he uses sdl timer and i use the TIMER function...

::EDIT2::

Last edit, i promise... I changed sterling's primitivestest8.bas for screen 13... pset went from 147000 to 500,000 psets a second... I gotta study the code i guess.

::LastEdit::

I know what was slowing down my code now... it seemed that a small coversion was slowing it. i put the fps = str$(count / (timer - t!)) outside of the loop and the fps more than tripled from 50,000+ to 170,000+. I find that kind of startling...

hmmm.... weird... i mimicked sterling's code. I did 10000 psets then flipped it on the screen then looped. I reached 500,000+ psets per sec that way. That seems... awkward... and ironic... the very thing that slowed it down to a grinding half the first time speeds it up from 150,000 to 500,000.

I'm going to bed after this... I quickly created a small particle engine in fb. handles 10000 particles with ease, and looks like it can handle a helluva lot more as well. qb choked around 2500. Qb showed slowdown at merely 1500.

http://quickhost.qbtk.com/download.php?id=363

[Sterling Christensen]

Barok: Another thing that was slowing it down is this:

Code:

fps = str$(count / (timer - t!))
locate 1,1
gfx_Print fps

Flip was the cluprit like Rel said, but the above also takes A LOT longer than a pset.

[barok]

yeah, flip did slow it down big time, but i still don't really see how one command other than flip could slow it down by 100,000 pixels either.

[Sterling Christensen]

yeah, flip did slow it down big time, but i still don't really see how one command other than flip could slow it down by 100,000 pixels either.

Ok, it's like this (get ready for a weird analogy):
You invented a new kind of machine gun, and want to show how fast it can pump out bullets. So lets say you propose to run it for 10 seconds, and then find and count the bullets.

But no. Instead, I take your gun and do this:
1. fire a single bullet
2. run to a chalk board and draw a tally, then run back to the gun
3. repeat steps 1 to 2 until 10 seconds have elapsed
4. count the tallies on the board

And then I say, "but I still don't really see how just one step (step #2) could slow it down so much." The answer is it's because it's one whopper of a step compared to how quickly the machine gun can do one bullet, that's why. When you pset, one pixel is overwritten. When you gfx_Print to the screen, it draws Width*Height pixels. In Screen 12 Height is 16 and Width is 8*Len(Text$).

To continue the analogy, it would be a little better to stop it and draw a tally every 5 bullets (which would divide time spent running/drawing by 5). The longer you let it run in between interruptions, the closer you come to seeing how fast it really is.

EDIT: Also, in the code you posted, you had Int(Rnd*240) for y. The screen is 200 pixels high is screen 13. That means about 17% of the psets aren't really drawing anything because they're offscreen, which is probably affecting the measurement.

[barok]

eh, i'm not gonna argue. Just that it works, i get 800,000 pixels psetted a sec so i'm happy.