'Got Balls?' - little sprite tester...

Community Forums/Showcase/'Got Balls?' - little sprite tester...

Taron(Posted 2008) [#1]
I just made this little tester, inspired by MGE and our research to figure out what funky things happen on different machines. Only very little differences can screw up performances on "perfect" machines, while running perfect on "crappy" machines, while the other way around is even more shocking and I'm dealing with that for the past few weeks or rather months since I've started with Bmax.

However, I got a little carried away and wrote this, which I think is gonna be fun for all of you. It contains creation routines for 3d looking balls, pretending volume by 3d shading and procedural normal creation. (very cheap, but cute!)
I've added even a fake highlight, which is particularely cute, while naturally nowhere near perfect. However, it performs brilliantly on my machine and offers a few different toggle modes...(I keep writing toogle, too weird?!).

So, yeah, have fun with this one... hopefully it may even inspire a little bit?

I never know how good my programming is, so I'm always a little hesitant to impose with this stuff, but here's a list of things I find neat in there:

- procedural ball creation with soft edge antialiasing and lighting
- useful little vector type
- vector to degree conversion
- nice and simple framework (I think it's a great starting point!)
- neat trick I figured out to toggle ( toggle:~1 )
...there maybe a few more curious things in there, good and bad...

As for the testing, I'd be already just happy to read whether it ran smooth or not. I realized that fps reports are not always enough of a clue. Let me know, if vertical blank [on] is true to your desktop framerate (ordinarily 60 nowadays], please.

You may just change the amount_of_sprites in there and let me know at what point it stops performing fine?!

Thanks in advance and have fun with it! 8)




smilertoo(Posted 2008) [#2]
Nice, 400fps as well.


Taron(Posted 2008) [#3]
Thanks, Smiler, that was quick! I just did a tiny change to make sure you know if vertical blank is on or off when you read the fps.


Taron(Posted 2008) [#4]
If you'd like it a bit more interactive and prettier...



plash(Posted 2008) [#5]
Windowed: 61 FPS with vertical blank on, and 100-104 FPS with it off.
Fullscreen is the exact same.


MGE(Posted 2008) [#6]
Taron - See how this works under DirectX on your box: Just change the top lines to:

SuperStrict
' Framework brl.GLMax2D
' Import brl.StandardIO
'--------------------------------------------------------------'
'"Got Balls?"												   '
'A little benchmark routine for smoothness and consistency of  '
'frames per second (fps) on any system...	   (www.taron.de)  '
'--------------------------------------------------------------'
'(feel free to use my balls any time you like!)

'-------------------------------	set graphics
Graphics(800,600,0,60)
' SetGraphicsDriver GLMax2DDriver()
SetGraphicsDriver D3D7Max2DDriver()
AutoMidHandle(1)


You probably already know this, but for little projects, you don't need to use framework, import, etc. Sure it makes the exe bigger, but you can just write and go. ;)


Taron(Posted 2008) [#7]
SuperStrict
Framework brl.d3d7Max2D
Import brl.StandardIO
'--------------------------------------------------------------'
'"Got Balls?"												   '
'A little benchmark routine for smoothness and consistency of  '
'frames per second (fps) on any system...	   (www.taron.de)  '
'--------------------------------------------------------------'
'(feel free to use my balls any time you like!)

'-------------------------------	set graphics
Graphics(800,600,0,60)
SetGraphicsDriver D3D7Max2DDriver()
AutoMidHandle(1)


Framework has to be changed, too!
Runs fine, but at fullscreen it appears VB is always on and flip args are ignored?!?

Overall, I'd say it's a little more consistent with d3d7.


plash(Posted 2008) [#8]
you don't need to use framework, import, etc. Sure it makes the exe bigger, but you can just write and go. ;)
SuperStrict isn't super if you don't use Framework, imo.


Taron(Posted 2008) [#9]
I've developed a liking for it, too! It's easy and feels percise, not to mention that it trains a good habit! :)

For the tiniest quickies I also didn't care about frameworks, but I think by now it already becomes second nature to me.


MGE(Posted 2008) [#10]
"Framework has to be changed, too!"

Really? Are you saying it wouldn't compile without it?

"Runs fine, but at fullscreen it appears VB is always on and flip args are ignored?!?"

More evidence that something is very XFile like on that 8Core mystery machine you use. :) lol..


Taron(Posted 2008) [#11]
oh yes... totally Xfile... check out the space thread to see another testimony for wackiness, when it runs on some machines. It seems to ignore the VB altogether and go completely nutz fast!


Taron(Posted 2008) [#12]
BAAAAAAAAAAAAAD Revelations!

- timer and millisecs are entertaining but bad functions in BlitzMax!

Nowadays a majority of machines run monitors that have a 60Hz refresh rate.
NOW, 60Hz means within 1000 milliseconds it refreshes the screen 60 times. Per frame that means it take 16.6666666~ millisecs. But Blitzmax can't handle floating point delays and the timer acts on the same principle as the delays (i'm sure!). Meaning that there is no way to actually let anything wait for 16.666666~ millisecs and we have to rely on vertical blancs in order to get a solid cycle rhythm of 60Hz. If for what ever absurd reason the GFX board doesn't send any understandable vertical blank trigger... ...we're screwed! Maybe, and I have no idea how, it's possible to figure out actual clock-cycles for certain commands and then pick the right one to come up with our own time measuring?! This would have to prerun on every machine and spit back out the usuable command for creating delay cycles.
However, I'm pretty underwhelmed right now... in other words: WTF, hahaha! Sorry for the hard shorthand <lol>.

Speak to me! :}

Oh my god I have an idea!!! Oh dear...hopefully that works! I'll report back when I got it running!


Taron(Posted 2008) [#13]
Well, I did have a funny idea and it may be interesting at some point, but it would almost require to take care of all the cycles in the loop. I measured (approximately) the amount of increments that would happen inside of one millisecond. Then I took that number by how ever many fractional millisecs I want to wait and somehow needed to take it times 2, but ended up incredibly close to what I wanted. This precision then showed the trouble of having to take in account what else would happen within the loops in terms of operations. I think that's a little on the insane side and frankly believe it's something BlitzMakers should consider "fixing". There must be a better alternative to get a finer timer for such fractional millisecs. Or much rather, is there no way to forcefully aquire vertical blank triggers of GFX boards?


plash(Posted 2008) [#14]
For more accurate timing see here.

EDIT: Also see here, apparently the newer/unusual processors get a bit cocky with hires timers.


Taron(Posted 2008) [#15]
Ok, so I found out what the VB problem was and it's openGL related! Using directX prevents that from happening, while I believe to notice that it's perfectly erratic whether it runs faster or slower on than dx on different machine setups... absolutely wild!

HOWEVER, I'll continue posting on my space thread, because there's an update...


BlitzSupport(Posted 2008) [#16]
More timer reading! Hi-res timing on multi-processor systems is tricky:
http://msdn.microsoft.com/en-us/library/bb173458(VS.85).aspx

This article is worth going through to find out what a minefield it really is! It does come to the conclusion that the functions in the above article are the most reliable, but apparently some older CPUs don't support them, and of course they're not cross-platform:

http://www.geisswerks.com/ryan/FAQS/timing.html

EDIT: Cygnus has done the tricky bit:
High Resolution Timers


I found out what the VB problem was and it's openGL related! Using directX prevents that from happening


This might be down to driver settings possibly -- you can force apps to observe or ignore global settings in most drivers. (Eg. In the current Nvidia Control Panel it's under 3D Settings -> Manage 3D Settings -> Global Settings -> Vertical Sync.)


MGE(Posted 2008) [#17]
I was going to suggest high res timers too, but unfortuantely they are not supported on every cpu in exactly the same way. It might be more stable now and in the future, but in 2006 when I used them in my Visual Basic game engine, there were alot of machines that didn't support high res timers.


Sphinx(Posted 2008) [#18]
400 - 440 FPS with 'v' off
60 - 63 FPS with 'v' on


Taron(Posted 2008) [#19]
AH, very interesting! Thanks for the link to the highres timer... I'll play around with it a little bit...