GLBasic forum

Main forum => Bug Reports => Topic started by: Qube on 2011-Jan-03

Title: iPad slow 3D Speed
Post by: Qube on 2011-Jan-03
Tested with latest iOS + XCode + GLB versions.

The simple one spinning cube below works at 60FPS on iPhone & iPhone mode on the iPad but when compiled for iPad alone the frame rate drops to a mere 35FPS.

Code (glbasic) Select

SETSCREEN 1024, 768, 1
LIMITFPS 60

GLOBAL colWhite =RGB(255,255,255)

X_AUTONORMALS 1

CreateCube(1, 3, colWhite)

LOCAL angle#
LOCAL timeThen% = GETTIMERALL()
LOCAL timeNow%  = GETTIMERALL()
LOCAL FPSCounter%
LOCAL FPS%


WHILE TRUE
timeNow = GETTIMERALL()
IF timeNow >= timeThen + 1000
FPS = FPSCounter
timeThen = timeNow
FPSCounter = 0
ENDIF

X_MAKE3D 1, 40, 65
X_CAMERA 0, 0, 0, 0, 0, 40
X_CULLMODE 1
X_SPOT_LT 1, colWhite, 0, 0, 0, 0, 0, 40, 50

X_MOVEMENT 0, 0, 17
X_SCALING 1, 1, 1
X_ROTATION angle, -1, 0, -1
X_DRAWOBJ 1,  0

X_MAKE2D
PRINT FPS, 0,0

INC angle
INC FPSCounter

SHOWSCREEN
WEND

FUNCTION CreateCube: num, size, col
X_OBJSTART num
// Front Face
X_OBJADDVERTEX  size, -size,  size, 1, 0, col
X_OBJADDVERTEX -size, -size,  size, 0, 0, col
X_OBJADDVERTEX  size,  size,  size, 1, 1, col
X_OBJADDVERTEX -size,  size,  size, 0, 1, col
X_OBJNEWGROUP
// Back Face
X_OBJADDVERTEX -size,  size, -size, 1, 1, col
X_OBJADDVERTEX -size, -size, -size, 1, 0, col
X_OBJADDVERTEX  size,  size, -size, 0, 1, col
X_OBJADDVERTEX  size, -size, -size, 0, 0, col
X_OBJNEWGROUP
// Top Face
X_OBJADDVERTEX -size,  size,  size, 0, 0, col
X_OBJADDVERTEX -size,  size, -size, 0, 1, col
X_OBJADDVERTEX  size,  size,  size, 1, 0, col
X_OBJADDVERTEX  size,  size, -size, 1, 1, col
X_OBJNEWGROUP
// Bottom Face
X_OBJADDVERTEX  size, -size, -size, 0, 1, col
X_OBJADDVERTEX -size, -size, -size, 1, 1, col
X_OBJADDVERTEX  size, -size,  size, 0, 0, col
X_OBJADDVERTEX -size, -size,  size, 1, 0, col
X_OBJNEWGROUP
// Right face
X_OBJADDVERTEX  size,  size, -size, 1, 1, col
X_OBJADDVERTEX  size, -size, -size, 1, 0, col
X_OBJADDVERTEX  size,  size,  size, 0, 1, col
X_OBJADDVERTEX  size, -size,  size, 0, 0, col
X_OBJNEWGROUP
// Left Face
X_OBJADDVERTEX -size, -size,  size, 1, 0, col
X_OBJADDVERTEX -size, -size, -size, 0, 0, col
X_OBJADDVERTEX -size,  size,  size, 1, 1, col
X_OBJADDVERTEX -size,  size, -size, 0, 1, col
X_OBJNEWGROUP
X_OBJEND

ENDFUNCTION
Title: Re: iPad slow 3D Speed
Post by: matchy on 2011-Jan-03
Removing X_MAKE2D (and replacing PRINT for X_PRINT fps debug) will reach ~60fps.

Here is a demo with 1 cube @57fps & 12 cubes @44 on OS 4.2 on iPad .
Title: Re: iPad slow 3D Speed
Post by: Leginus on 2011-Jan-03
Sounds like an improvement.  Just out of interest, if you dont print any 2d how does it run?
e.g. store fps value to a variable on mouse press and then show at the fps to screen on exit.

Title: Re: iPad slow 3D Speed
Post by: Slydog on 2011-Jan-03
So, going between 2D and 3D each frame is a major speed issue?
So, all my HUD, GUI, and FONT code should be rewritten to use 3D polys (dynamic models) instead of 2D polyvectors? 
Not a big problem, just never got that far yet (testing on iDevice!).
[Edit] Dang, then I have to figure out how far to place those polys from the camera to achieve 1 to 1 pixel.
[Edit2] Dang2, then rotate them to be always facing the camera!  Hmm, must be an easier way!  Like parent them to the camera's rotation matrix or something?
Title: Re: iPad slow 3D Speed
Post by: matchy on 2011-Jan-03
2D is needed and, although I don't think there is an alternative for X_MAKE2D, I could guess you could try try raw inline c++ opengl for now. I just discovered this and hopping that X_MAKE2D could be improved.
Title: Re: iPad slow 3D Speed
Post by: Qube on 2011-Jan-04
1 cube at 57fps, 12 cubes at 44fps - Lets be honest here, that is a pitiful amount of polygons for it to be running at 44fps. Compile the same thing for the iPhone and you'll easily get 60fps with plenty of room to spare. In my own tests I can easily get 10k+ polygons at 60fps on the iPhone 3GS and thats without trying to find what the limit is.

Fact is, using GLB on the iPad for 3D is unusable as it struggles with even a few cubes whereas the SAME thing works perfect on the iPhone even 10, 20 times the amount.

Something is not right here. Fact is, 1 cube appears to be the limit with GLB and iPad in 3D before frame rate starts to drop. No matter how you work it, that's not right, is it?
Title: Re: iPad slow 3D Speed
Post by: matchy on 2011-Jan-04
Thanks for watching my test app and video (somewhat controversial) demo that I created especially for you guys to pick the obvious at.  :whistle:

As there could be something that I missed, I wish others would do their own tests because maybe my code or technique could be an issue.  :zzz:
Let's hope the source producer/s can look in to this.  8)
Title: Re: iPad slow 3D Speed
Post by: Leginus on 2011-Jan-04
it was a good video, but i didnt reply on twitter cos i didnt think it was appropriate  :whistle:
Title: Re: iPad slow 3D Speed
Post by: Slydog on 2011-Jan-04
It's almost like every polygon is resetting the material (an extra draw call per polygon), or something.
Doesn't GLBasic for the iPad use the exact same OpenGL calls as the iPhone?
Have some OpenGL routines been rewritten for the iPad?
It's beyond the argument that the iPad has a higher resolution.
Title: Re: iPad slow 3D Speed
Post by: ampos on 2011-Jan-04
Not sure about the ipad, but 3GS has the same exact graphic chipset as Iphone4.

If iPad has the 3D gfx chip of 3G (old) iphone, it has to deal with as many as 5.1x pixels for the same cube. So the limitation could be in iPad hardware that has to move 5x more pixels. Just try to move 5x more cubes on a 3G to check.
Title: Re: iPad slow 3D Speed
Post by: matchy on 2011-Jan-04
60fps on iPod Touch 2G with 70 cubes.
Title: Re: iPad slow 3D Speed
Post by: Qube on 2011-Jan-04
Quote from: matchy on 2011-Jan-04
60fps on iPod Touch 2G with 70 cubes.

I rest my case  =D

GLB works really well in 3D on the iPhone but crawls on the iPad. It is not a limitation of the iPad as you can see many examples in the appstore of 3D iPad games running at good frame rates. Have you tried a skybox on the iPad, instant FPS death :o

Something is wrong with GLB, iPad and 3D.
Title: Re: iPad slow 3D Speed
Post by: matchy on 2011-Jan-05
Qube. That's not the only thing. Perform your own test data as that test was for ampos and stopping pointing out the obvious.
Yes, we know the iPad 3D is slow but help in debugging and troubleshooting. You have no "case" when no-one has release 60fps GLB iPad app so stop sounding like you are right.
Title: Re: iPad slow 3D Speed
Post by: Qube on 2011-Jan-05
Quote from: matchy on 2011-Jan-05
Qube. That's not the only thing. Perform your own test data as that test was for ampos and stopping pointing out the obvious.
Yes, we know the iPad 3D is slow but help in debugging and troubleshooting. You have no "case" when no-one has release 60fps GLB iPad app so stop sounding like you are right.

How much more evidence do you need? I'm not out to dis GLB, I love it but there is something wrong with the 3D side on the iPad, it is shockingly slow. Prove me wrong. I've already posted two examples but if it'll please you I'll begrudegly spend more time doing more examples.  :( - you yourself posted that the iPhone can do 70 cubes at 60fps yet attack me for quoting it. Please be adult about this, it needs sorting.

Ok, to help in bugging the iPad issue then today I'll do some more examples which show there is a problem with the iPad 3D speed.
Title: Re: iPad slow 3D Speed
Post by: Kitty Hello on 2011-Jan-05
ok, we all calm better down now.

I can truly understand that you are upset with the speed of the iPad implementation. The bad thing is - it's exactly the very same code as the iPhone code. Not a single byte changed.
If 3D is slow, please try to figure out why - I don't have the time to test that in detail ATM. So sorry.
Title: Re: iPad slow 3D Speed
Post by: Qube on 2011-Jan-06
I've tried everything I can think of and nothing I do gains any real speed +/- a couple of FPS.

So far using three spinning cubes based on my example in this thread and with x_print for the FPS instead I've switched around portrait, landscape, no x_print, cull modes, smoothing, normals, no lights or ambient lights, shorter / longer camera and 3D ranges.

It's so frustrating that the iPhone side is flying along, yet the iPad side is really dragging it's heals :S - The 2D side zooms along happily so it's confusing as to why the 3D doesn't.  I understand that you say it's the exact same code as the iPhone and that you don't have the time at the moment to look properly at it, we're all busy busy :)

Never mind, twas real good fun using GLB up to this point but I guess I'll have to find something else for 3D projects  :'(
Title: Re: iPad slow 3D Speed
Post by: Slydog on 2011-Jan-06
I wonder if using the iXors3D wrapper would speed things up any?
I assume it handles the OpenGL ES code, so it should be well polished.
Although iXors3D isn't free I don't think.

Or, if somebody has the skills, they could create a GLBasic project that calls OpenGL directly, bypassing GLBasic's commands.
Try spinning 70 cubes that way on the iPad.
Title: Re: iPad slow 3D Speed
Post by: bigsofty on 2011-Jan-06
Maybe some OpenGLEs 2.0 could be added to the iPad 3D engine to give it a boost?

IXors is very fast but I have yet to try it on the iPad only the iPod so far.

Cheers,


Ian
Title: Re: iPad slow 3D Speed
Post by: Qube on 2011-Jan-07
Can you use iXors3D via GLB while developing in Windows? or do you have to keep transferring compiles to OSX for compiling and testing on the iPad as that would be one hell of a long process all the time, lol.

I wouldn't mind purchasing a license for both Xors3D and iXors3D providing I can develop and test directly from GLB and do iPad compiles as and when (like you can in GLB by itself with it's native engine).
Title: Re: iPad slow 3D Speed
Post by: Slydog on 2011-Jan-07
iXors3D is for iPhone only, so it wont run on Windows, but Xors3D will.

So, when wrappers are finished for both, you may be able to create another wrapper that wraps both of the iXors3D and Xors3D wrappers together that detects what platform you are running / compiling on, and calls the appropriate library.

But since the libraries don't have the exact same features (and maybe even the calls may differ) you would have to program to the lowest common denominator to ensure your calls work on both platforms.