Sprite3D() - Improvements / Questions

netmaestro · Post by **netmaestro** » Tue Jan 03, 2006 7:23 am

PB does 550 sprites before degrading fps below screen refresh, for blitz around 600. Not too different. I don't know how fair the comparison is, though. Often the author of something like this will have a "favourite" going in. Not saying that's the case here, no evidence of partiality so far.

Shannara · Post by **Shannara** » Wed Jan 04, 2006 1:11 am

Blade wrote:
Code: Select all
SpriteColor3D(#mysprite,r,g,b)
could be very useful, but if we had the chance to modify the color of the four single corners, thanks to the hardware gourad-shading much more nice effects could be added.
Give the same color to the four corners to have a solid color.

And don't forget that with R G B there is a fouth channel: A (for alpha!)

Heh, this was requested before

Im hoping it'll show up in PB4

THCM · Post by **THCM** » Thu Jan 05, 2006 1:56 pm

I get about 6000 sprites using 1280x1024x32 with 60hz.

xperience2003 · Post by **xperience2003** » Thu Jan 05, 2006 2:07 pm

i get
blitz 80 fps, 1050 sprites
pb 72 fps, 1050 sprites

..pb-version isn't smooth

athlon 2k+ , radeon9550

Trond · Post by **Trond** » Thu Jan 05, 2006 5:58 pm

Blitz 300 sprites: 19 fps.
PB 300 sprites: 58 fps.

The Blitz version looks like this:

The PB version looks like this (for some reason the screencapture didn't catch the text):

I'll let the pictures speak for themselves and don't say anything that can be used for saying that I am taking every opportunity to criticize PB and its function set.

Edit: By the way, here's a screenshot from the unmodified (just fetched it from SmartUpdate) Sprite3D.pb example. Aren't those pink areas supposed to be transparent? (From file: TransparentSpriteColor(0, 255, 0, 255) ; Our pink is transparent

)

What are your thoughts on the above proposed commands/functions?

Personally I'd rather see that the existing commands works before adding new ones.

blueznl · Post by **blueznl** » Thu Jan 05, 2006 9:54 pm

blitz: 0 sprites

memory access violation

pb: 1600 sprites (are those sprites supposed to be b&w?)

trond, what kind of hardware do you have?

coma · Post by **coma** » Fri Jan 06, 2006 12:59 am

blueznl wrote:blitz: 0 sprites memory access violation

pb: 1600 sprites (are those sprites supposed to be b&w?)

trond, what kind of hardware do you have?

try to resize balloon.bmp to 128x128, it should work with blitz.

I made a little test with purebasic and directx :

dxspeedtest

speedtest & speedtest2 are the same, except that I use software vertex processing in the second one.

unfortunately it's not possible to turn vsync on/off during the execution (or I don't know how, with dx9).

(sorry for the big dll

)

aaron · Post by **aaron** » Fri Jan 06, 2006 3:37 am

coma wrote:I made a little test with purebasic and directx :

vsync on, full screen:

Speedtest ran at 75fps until 590 sprites, then it started to lag occasionaly (like 1 or 2 times a second it would slow down, then pop back up to 75)

Speedtest2 ran at 75fps until 580 sprites.

Very close.... I have a NVidia MX440 with a P4-HT @ 2.6GHz. For reference, the original blitz basic version ran up to 750 sprites before the lag started. Interestingly enough, turning off vsync (as can be done in the blitz version) got rid of the lag, although tearing could then be seen. It seems that the sprite code runs about 30% slower in the purebasic version versus the blitz basic version. Is that a good trade off for a smaller EXE? Well... not in my opinion, particularly for games.

Lets see how PB4 does.

coma · Post by **coma** » Fri Jan 06, 2006 3:59 am

I only put speedtest2.exe because I think that hardware vertexprocessing doesn't work with all the gfx cards (the proper way would be to do a test of hardware capabilities :roll: )
there's not a big difference between the two versions in a such program (not the case when there's 3d meshs with a lot of vertices).
but the goal is not to compare my two versions

Trond · Post by **Trond** » Fri Jan 06, 2006 3:15 pm

blueznl wrote:trond, what kind of hardware do you have?

A ProSavageDDR (and I can't upgrade because it's a laptop).

If I resize the balloon to 128x128 it looks like this (and it behaves strange like laaaag fastfastfast laaaaaaglaaaag fastfast):

blueznl · Post by **blueznl** » Fri Jan 06, 2006 5:18 pm

hate to say it, but laptop hardware is, euh, rather... weird

i'm not expecting anything on laptop hardware, to be honest, and i guess fred's not going out of his way to support all sorts of exotic hardware

(don't say: but other programs work! sometimes following the rules may result in code that doesn't run on all hardware / software platforms, as those hard / software implementations do not entirely follow the rules themselves... one language may work, another one may not)

Steve Elliott · Post by **Steve Elliott** » Sat Jan 07, 2006 11:49 am

Some good suggestions syntax error, 3d sprites are very useful.

But if this is implemented I just hope the exe's don't end up the size of Blitz BASIC!

Shannara · Post by **Shannara** » Sun May 14, 2006 8:00 pm

Heya Fred, are there any plans on implimenting any of these commands?

Joakim Christiansen · Post by **Joakim Christiansen** » Sun May 14, 2006 8:31 pm

Shannara wrote:Heya Fred, are there any plans on implimenting any of these commands?

It would rock!

Lyon · Post by **Lyon** » Sun May 14, 2006 9:13 pm

I made a little test with purebasic and directx :

dxspeedtest

speedtest & speedtest2 are the same, except that I use software vertex processing in the second one.

WOW!!! This is AMAZING. On my POS system, I get 1100 sprites with test 1 before it starts to take a FPS hit and nice and smooth with 1100 sprites. Please make this into an easy to use third-party solution for 2D stuff we can use with PB.

Specs:
Celery 1GHz
512MB RAM
Geforce FX 5200 128MB