Author Topic: Request thread (NO SOURCE = NO PORT)  (Read 2334 times)

gameblabla (OP)

  • *
  • Posts: 394
Request thread (NO SOURCE = NO PORT)
« on: October 10, 2016, 10:15:28 PM »
The OpenPandora boards has a huge thread like this :
Why not combine all the port requests in one single thread instead ?

The rules are simple :
Want to have your favorite game ported to the GCW0 ?
Request it here !

I have to remind you though : Without some source code, a port isn't possible.
Additionally, it should support rendering to OpenGL/OpenGLES1/2 or have some kind of a software fallback.

Hopefully i'll able to discover some unknown gems here !

Requested things
Done
Twin-E (LBA1 Engine) : Doable but i don't own the game sadly... You can find my progress here.
Virtual Jaguar : Here. Worms runs pretty smoothly on it.

Failed attempts
SuperTuxKart : this one is problematic as it is a huge game and doesn't run very well on the poor vivante.
I have a working software renderer version tho but it is very big and i can't release it yet.

Haven't looked at it yet
Free in the Dark : It's fairly incomplete so i have not attempted a port yet.
pyTouhou : Like Senor Quack said, it is probably not going to run smoothly...  Plus, it requires Python 3.
Yabause : there's an SDL port by Ptitseb but even on the Pandora, it's very slow. No point in doing that.
a libretro port was compiled tho if you want to give it a try.


« Last Edit: December 31, 2016, 10:45:34 PM by gameblabla »

zear

  • * Moderator
  • Posts: 2377
Re: Request thread (NO SOURCE = NO PORT)
« Reply #1 on: October 11, 2016, 07:54:38 PM »
Why not combine all the port requests in one single thread instead ?

Because it will teach people they can demand content from developers,
while the latter end up producing low quality ports to satisfy the requests.

You can keep this thread as a personal list of port requests, but I won't sticky it or make it official.

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #2 on: October 12, 2016, 04:24:19 AM »
Because it will teach people they can demand content from developers,
while the latter end up producing low quality ports to satisfy the requests.
Why are you so sad zear ?
The GCW0 needs more software anyway : right now, it has a reputation of having no games for it.

Also, i have ported glshim to the gcw0 (thanks lunixbochs) so now you can request OpenGL-only games
as well.

Not sure what OpenGL game i should port first tho... Maybe you can give me an idea ?

zephyrus

Re: Request thread (NO SOURCE = NO PORT)
« Reply #3 on: October 12, 2016, 09:19:51 AM »
Thank you gameblabla for all your support for gcw! I don't know why the moderators here are in so bad mood, it's not very friendly if someone's constantly been adviced to stop posting his ports (even if they say it not directly). This is a forum, not the official release channel for the gcw. Many very exciting ports and original games were posted here and even if some of them do not work perfectly, they are important for such open source device. If you don't feel the same its yours but please don't demotivate other devs.

For the port request: Gameblabla you mentioned it already in another thread, Supertuxcar would be very exciting!  :)

Ryvan

Re: Request thread (NO SOURCE = NO PORT)
« Reply #4 on: October 12, 2016, 05:44:06 PM »
Why not combine all the port requests in one single thread instead ?

Because it will teach people they can demand content from developers,
while the latter end up producing low quality ports to satisfy the requests.

You can keep this thread as a personal list of port requests, but I won't sticky it or make it official.

That logic makes no sense. Anyone can demand as much as they want (in any thread, really), but that doesn't mean they'll ever get it. Low quality ports are better than -no ports at all- considering that the Zero is very much a niche device and if the devs can be influenced to do things they don't want to do by people telling them what to do, then they have issues.

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #5 on: October 13, 2016, 04:06:25 AM »
Ok, so i started to work on Supertuxkart and it is more difficult than i thought...
I'm using version 0.8.1 btw as later versions requires OpenGL 2.x, which cannot be used with glshim. (yet)
Unlike Lugaru though, i can use gdb on it so that makes things a bit easier.
But the issue is that the graphics engine, Irrlicht, expects the target to support X11.
I had disabled X11 support but this doesn't work as it can't initiliaze the Display.

I'm not giving up yet though, Irrlicht also apparently supports SDL too so i'm now trying to build against SDL.
We'll see how it goes...

EDIT: GUYS, I GOT SUPERTUXKART TO BOOT WITH GRAPHICS !
At first, it was not working but after i linked it to EGL and libpreload, i got it to boot with graphics.
Unfortunely, there is still a lot to do before i can get it to work properly :
- The main startup screen is almost completely white.
Not a problem though since it can be disabled.
- The models (characters) are not rendered properly or at all.
Everything else is properly rendered though.
- This game was designed for much higher resolutions like 800x600 : The GCW0 has a resolution of 320x240.
As a result, everything in the menu is cramped up.
- The game crashes after skipping the story mode introduction and picking your character.
Just kidding, it's much worse than that actually : it REBOOTS the console !

So here are my plans :
- Render the game at 640x480 and downscale using the IPU. It should look better and much less cramped.
- Once i have done that, i will then be able to use the menu and lower all the graphical details down to 0.
- Hope and pray downgrading the graphics will make everything stable. If not, well...
I will have to wait for the next firmware update.

EDIT2: So i made further progress...
After disabling all the special effects and animations, the game no longer crashes.
Unfortunely, there are still lots of graphical glitches...
In particular, a lot of things are invisible.
In addition to that, it is also very slow.
I also had to downscale the textures so the game could boot otherwise it would get stuck in a loop.

I will experiment with TinyGLES and see if it can be used for SuperTuxKart.

EDIT3: TinyGLES by lunixbochs doesn't work on the GCW0.
Trying to fix a crash leads to another one... I hope Johnny can give me his TinyGLES version so i can
have an idea how well it works, even though it only supports 16-bits textures.

I'm stuck with the game for now, i might release the broken version though.
« Last Edit: October 13, 2016, 06:21:51 AM by gameblabla »

Senor Quack

  • *
  • Posts: 159
Re: Request thread (NO SOURCE = NO PORT)
« Reply #6 on: October 13, 2016, 07:43:57 PM »
So here are my plans :
- Render the game at 640x480 and downscale using the IPU. It should look better and much less cramped.

Only use the IPU for non-OpenGL games:

The GPU's texture unit will do bilinear scaling for you. All that should be necessary is to specify GL_LINEAR texture filtering mode for those textures that are hard to read.  You probably wouldn't want to specify it for all the textures, just the GUI/font textures, as it incurs a performance penalty.  This penalty would likely be very small, though, compared to rendering the entire GL scene to a 640x480 viewport and then downscaling with IPU.  More about texture filtering:  http://www.learnopengles.com/android-lesson-six-an-introduction-to-texture-filtering/

About your white-texture bug: If you are using OpenGLES1, you might try resizing the image file for that texture to power-of-two dimensions, i.e. 1024x512, 512x256, etc. GLES1 can be picky about non power-of-two texture dimensions. GLES2 usually doesn't have this problem, though it is platform-dependent (vivante does support NPOT textures on GLES2, but I can't recall its behavior under GLES1)

Another tip: Games meant for PC resolutions usually have higher-resolution textures than is necessary for display on a 320x240 screen. Not only do these take up more RAM than is necessary, they also can reduce performance quite a bit, as they make the texture cache/prefetch ineffective. If you are porting such a game, it is best to see if someone else has already ported it and made a low-res version of the textures, or make your own low-res versions. You can also just leave the image files alone and resize the images on-the-fly in RAM before they get loaded as a GL texture proper. It is also an excellent opportunity to fix the problem you have with GUI textures: you use Imagemagick or Photoshop/Gimp to downscale the textures and save them at an lower resolution optimal for your target platform preferrably 1:1 texture<->onscreen resolution. Then, you can leave GL texture filtering off, and get the best of all worlds.
« Last Edit: October 13, 2016, 08:37:23 PM by Senor Quack »

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #7 on: October 14, 2016, 12:44:56 AM »
Thanks senquack !
I have decided to do it from scratch this time around with my own Makefile.
I tested it on my desktop at 320x240 and with some modifications,
the game now works better at 320x240.

They were indeed a few textures that do not have a proper resolution so i fixed them.

I also discovered that Irrlicht, the graphics engine to SuperTuxKart before they switched to Antartica,
has a software renderer !
It's much slower of course and not as compliant but at least, it will help me with my testing.

I have not tested my new version on my GCW0 yet tho, maybe it will work better this time with the downscaled textures.

EDIT:
In OpenGL mode, the white texture issue is gone after i downscaled most of the textures.
Unfortunely... There are still lots and lots of graphical glitches, disappearing polygons...
Even after i heavily downgraded the textures, it still complains about the size of some textures :
Quote
glActiveTexture: texture > GL_TEXTURE_MAX
glActiveTexture: texture > GL_TEXTURE_MAX
glActiveTexture: texture > GL_TEXTURE_MAX
glActiveTexture: texture > GL_TEXTURE_MAX
What's the biggest texture allowed on the GCW0 anyway ?
If it's smaller than 512x256 then we're holding a record gentlemen : it's now worse than a PSP !
Did i mention it is very slow ?

Now with the software renderer, it is a bit different.
It looks just like on my desktop, it looks better than the OpenGL renderer.
The hilarious thing is that it is almost as fast as the opengl renderer, despite it not being very fast.

I will try to downscale some textures (yet again...) but other than that, i don't know what i should do.
« Last Edit: October 14, 2016, 01:08:08 AM by gameblabla »

congusbongus

  • *
  • Posts: 74
    • congusbongusgames
Re: Request thread (NO SOURCE = NO PORT)
« Reply #8 on: October 14, 2016, 01:12:05 AM »
Did you start with the pandora port? I would think most of the graphics issues are solved there.

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #9 on: October 14, 2016, 01:28:18 AM »
Did you start with the pandora port? I would think most of the graphics issues are solved there.
No, i didn't because i could not find the Pandora specific source code. (or patches for that matter)
All i know about the Pandora port is that ptitseb solved the memory usage issue by downscaling textures on the fly.
But again, i do not know where the source is.

Also, it seems that it you downscale your textures too much, it will crash the EGL context. (libEGL)
Not sure why...

EDIT: Also etna_viv occasionally complains about this :
Code: [Select]
etna_pipe_transfer_map:159: unsupported tiling 3 for reading
« Last Edit: October 14, 2016, 01:43:02 AM by gameblabla »

Senor Quack

  • *
  • Posts: 159
Re: Request thread (NO SOURCE = NO PORT)
« Reply #10 on: October 14, 2016, 01:41:06 AM »
What's the biggest texture allowed on the GCW0 anyway ?
If it's smaller than 512x256 then we're holding a record gentlemen : it's now worse than a PSP !

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. 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)?

Did i mention it is very slow ?

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.

Have you looked at whether or not the game is using double (64-bit) float math instead of 32-bit float math? That's often something seen on PC games.. 32-bit float is faster on embedded CPUs like ours. You also have to be careful of float literals in the source code: as an example, the floating point literal '1.5' will be assumed to be a double, so any expressions involving it would be done with double temporaries, where if it is '1.5f' it is a faster 32-bit. Usually 64-bit float math is overkill for a game.  You can use the gcc parameter '-fsingle-precision-constant' to make gcc assume these unadorned literals are floats instead of doubles.

Also, you can look at how often physics is updated. I've increased performance in several games by reducing it from, say 60 times a second, to 30, without noticeably affecting gameplay.  Once you decrease past a certain threshold, though, you can get strange behavior like tunneling through walls, etc.
« Last Edit: October 14, 2016, 01:48:21 AM by Senor Quack »

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #11 on: October 14, 2016, 01:57:47 AM »
Quote
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...

Quote
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-gcw

Build the OPK by running pack.sh and see it yourself how well it runs.
« Last Edit: October 14, 2016, 07:42:05 AM by gameblabla »

Senor Quack

  • *
  • Posts: 159
Re: Request thread (NO SOURCE = NO PORT)
« Reply #12 on: October 14, 2016, 05:55:46 PM »
I noticed it's using 'billboards' in places, that is something I don't believe is supported in Etnaviv.. I had to disable them in Neverball. Search anywhere 'addBillboard' is used.

Also, you can try disabling rendering of the skybox background. In Neverball, that added a decent FPS improvement. Fortunately, Neverball had a simple static background it painted beneath it so it didn't just look like black empty space.

But, I would not expect good performance if your game is not rendering natively in GLES2 and is using appropriately sized textures, preferrably mipmap'd ones where appropriate.. And even then, I wouldn't expect good performance if it is not batching as many draw calls together as possible and was not originally coded with an eye towards performance.

It could also be a case of the models/terrain being too complex, containing a huge amount of vertices which is no problem for a PC, but terrible for embedded devices. This was the case for quite a few of the maps in Neverball: Someone making a map with curved surfaces and wanted it to look perfect, so modeled the curves with thousands of individual polygons so that FPS tanked when run on GCW.  I had to remove 1 or 2 dozen maps from the final release because they were unplayable, like 2-8 FPS.. but the majority of the maps ran at smooth 60fps, the rest still playable. That gives you an idea of how complexity of the models/terrain can impact speed.  And Neverball is a game that renders natively in GLES2, written by a computer graphics professor who understands how to write efficient GL code.

This is a pretty relevant post on the Pandora boards regarding this and TuxKart: https://pyra-handheld.com/boards/threads/supertuxkart-on-pandora-1ghz.68776/page-2#post-1165827

Are you trying to use glshim still? Does irrlicht support GLES2?  Our GPU, like any modern embedded or PC GPU, is a shader device, so GLES1, especially with a GL1 compatibility shim, would not give the best performance.

Looks like TuxKart has now moved into HDR rendering territory, further and further away from stuff we could hope to run efficiently: https://github.com/supertuxkart/stk-code/issues/2288  so I guess STK is some new stuff in TuxKart for fancy rendering?  Someone here has been fighting with an Android port and mentions some useful stuff: https://sourceforge.net/p/supertuxkart/mailman/message/34891035/     Further down in that thread, someone mentions a GLES port but I dunno if it works on GLES2.0 or is limited to 3.0: https://github.com/supertuxkart/stk-code/tree/gles

11-pass rendering? Oh maaaan post processing would kill performance for us.
« Last Edit: October 14, 2016, 07:21:40 PM by Senor Quack »

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #13 on: October 15, 2016, 05:45:02 AM »
Thanks again, senquack.
I have to mention though that i'm not using the latest versions with the Antartica engine,
only version 0.81 with the Irrlicht engine as i knew it would not run smoothly on the GCW0 (or at all/)

The lod thing for objects was useful, plus he said that they have low-poly versions of objects so i'm using them now.
I also disabled billboards but i do not notice a huge improvement...
Disabling the skybox did not do much either.

Unfortunely, the game simply tries to push too much polygons at once and that causes slowdowns and depth
issues on the Vivante.
The cutscenes, which are small maps, are running smoothly on the GCW0 in comparaison to in-game.
They still do suffer from depth issues however.
There is simply no LOD mechanism for the maps themselves and that's a huge problem.
Maybe the PowerVR driver does not draw polygons if they are too far from the camera
cause i don't know how it would be smooth on a Pandora.

I have created an optimising branch where i threw all of my shit at it (i certainly don't want to push that to master)
and it is running a little better.
Still not running great... even after disabling all the post-processing stuff.
« Last Edit: October 15, 2016, 05:47:46 AM by gameblabla »

username

Re: Request thread (NO SOURCE = NO PORT)
« Reply #14 on: November 03, 2016, 01:10:06 AM »
Here's a (hopefully) reasonable request: https://pytouhou.linkmauve.fr/

I talked a bit with the author and it should be possible. It uses Python and OpenGL ES 2.0, but it might run too slow and the font might need to be changed to a more readable one if it's too small.

There's an OpenPandora port, too, here: https://repo.openpandora.org/?page=detail&app=pytouhou

 

Post a new topic
Post a new topic