The max texture is definitely much larger than 512x256.. I'd guess it's at least 4096x4096 or probably much higher. Normally you wouldn't use textures that large for anything but a texture atlas holding many many smaller textures.
None of the textures are this big as far as i know but maybe i have missed something...
As for your problem with smaller downscaled textures: I've used textures as small as 4x16, so that's definitely not your problem. Are you being sure to use strict power-of-two dimensions (assuming you're using GLES1)?
Well, i'm pretty sure but maybe i am missing something...
I'm using Mogrify (ImagaMagick) to downscale the textures.
I first did a resize 25%, then again a resize to 50%.
However, the last command will make the game crash when it will attempt to load the textures.
Strange indeed...
That's not a huge surprise, most OpenGL PC games, especially if they are using fixed function GL1 and you're converting calls via glshim, I would expect to run very poorly. Waaaay too much API overhead, not enough attention paid to optimization.
You're right but still, considering how well it runs on the Pandora (no less than 12 FPS),
i would have expected it to run at least on par with a Pandora Gigahertz.
Right now, it's not even close to a CC.
Still, i agree it is poorly optimised : it does not even have fog and it doesn't have a draw distance limit either...
I wonder how ptitseb managed to have good speed on the Pandora...
All the options are all the way down already...
I will publish the source code, the binary along with the data required soon on my repo.
EDIT: I had not seen your edit to your post. I will inspect the physics yeah.
It's using bullet btw.
EDIT2: i have modified the physics so it updates less often and passed single-precision-constant to the compiler
but there was little difference.
It's clear that the bottleneck was the GPU.
I looked at glshim and realised the compiler did not optimised it so i did and there was a small increase in performance.
Still not enough to make a difference.
But more annoying than the overall slowness are the graphical glitches :
there seems to be depth issues as sometimes, i am only able to see my kart against the blank background.
I guess this game is too much for the poor vivante...
I still wonder how ptitseb managed to make it run doable on the pandora...
EDIT3:
I downloaded the PND just to see what ptitseb did to Supertuxkart.
Unless i'm proven wrong, ptitseb did not touch the game's source code.
Instead, he simply used his glshim's fork to auto-downscale the textures.
The data folder is exactly the same as the official release.
I can't say he put a lot of effort into this release...
So i used his glshim's fork and modified it so it could work on the GCW0.
After i got it to work, i tested it with SuperTuxKart and apart from fixing the texture size issue,
it did not improve the speed or rendering issues.
This is very disappointing...
So i forced irrlicht to set all textures to Nearest instead of Linear.
This improved the speed a bit and in my opinion, actually looks better.
But it is still way too slow... the game in the overworld runs at 4~6 FPS and it never goes beyond 11 FPS.
Either the Vivante isn't a very fast GPU or the current user-space Etna_viv driver is slow/non-compliant...
Sure, the game is poorly optimised but still...
Here is the source :
https://github.com/gameblabla/supertuxkart-gcwBuild the OPK by running pack.sh and see it yourself how well it runs.