Dingoonity.org

GCW Zero => Games & Homebrew => Topic started by: gameblabla on October 10, 2016, 10:15:28 pm

Title: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla 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. (http://boards.dingoonity.org/gcw-development/*needs-testing*-little-big-adventure-engine-(wip)/new/#new)
Virtual Jaguar : Here (http://boards.dingoonity.org/gcw-development/virtualjaguar-port-for-gcw0/msg159343/#new). 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.


Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: zear 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.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla 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 (http://boards.dingoonity.org/gcw-development/glshim-now-ported-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 ?
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: zephyrus 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!  :)
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: Ryvan 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.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla 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.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: Senor Quack 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.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla 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.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: congusbongus 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.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla 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
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: Senor Quack 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.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla 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 (https://github.com/gameblabla/supertuxkart-gcw)

Build the OPK by running pack.sh and see it yourself how well it runs.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: Senor Quack 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.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla 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.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: username 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
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on November 03, 2016, 04:00:47 am
So i tried SuperTuxKart using the BurningVideo software renderer.
It has some issues but even then it looks better than the OpenGL port.
I might publish it along with the OPK.

I also found that there's no LOD for the maps !
SuperTuxkart, rather than using the map function, simply instead loads it as a mesh.
And Irrlicht does not support LOD for meshes...

We might consider implementing hacks at the driver-side to easily go around this...
(if that's even possible)
Or maybe it is actually doing this and explains why it looks so bad. (and not much faster)

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
Thanks for the link dude.
I see that it uses Python 3 instead of the provided Python 2.7.
That means i will have to compile myself...
Also, i see you mention there's an OpenGL ES port but nothing on the page says so.
I think the Pandora port uses glshim but i'll have to check this.

That's not a problem tho, it supports OpenGL 1.4 so it can work with glshim.
I'm not sure it will actually run pretty fast, considering how bad our GPU is (just discovered this)
but i'll see if i can give it a try one day.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: Senor Quack on November 03, 2016, 05:29:38 pm
You keep saying our GPU is bad, but it's really not that bad. However, you just can't throw a game meant for PCs at it and expect it to run well.

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
Thanks for the link dude.
I see that it uses Python 3 instead of the provided Python 2.7.
That means i will have to compile myself...
Also, i see you mention there's an OpenGL ES port but nothing on the page says so.
I think the Pandora port uses glshim but i'll have to check this.

That's not a problem tho, it supports OpenGL 1.4 so it can work with glshim.
I'm not sure it will actually run pretty fast, considering how bad our GPU is (just discovered this)
but i'll see if i can give it a try one day.

Hey, cool a shooter, I love shooters. Congrats on nKaruga btw, looks fun.  Well, here's some ideas having not looked at the source code..

I am assuming that each bullet is rotated/translated individually using a matrix transform on the GPU side (most developers do it this way) and that means that there would be tons of API overhead from GL matrix uploads and individual draw calls, on top of the overhead of you using glshim.   Then, there's the overhead of Python itself which on GCW Zero is interpreted, not JIT.  You could convert the core rendering/math portion of the game to C and call that from within the outer Python.

Assuming the game does individual bullet draw calls, best thing would be to do all the matrix math on the CPU side in C and coalesce all those bullet draws into just a few glDrawArrays() calls. It sounds counterintuitive that it would be faster to have the CPU do all the transform math, but that game looks entirely 2D so one whole dimension of the matrix math doesn't need to be computed. Each vertex transformation works out to a simple (X,Y) * matrix_2_by_3[].  Together with fast cos/sin lookup table or routine (I have a very fast one if you need it), the CPU can handle those rotations/translations very quickly, way faster actually than it takes to send individual matrices and draw calls to the GPU.  Doing the vertex transforms on the CPU side allows you to send a huge array of pre-transformed vertices to the GPU in one draw call.  The only vertex transforms the GPU then ends up doing is the final perspective transform.

If any of the bullets are drawn using textures, you'd want to group their drawing together by texture so that they similarly could be transformed/drawn using just a single draw call, which also minimizes API calls to change texture and makes the GPU not swap shader programs in and out constantly (which occurs if you issue one draw call requiring texturing followed by one without, and vice versa). Same goes for grouping draw calls by blend mode (each change in blend mode can potentially require a different shader program to be loaded behind the scenes).

This is how I got rRootage working fullspeed, and that was a real chore even for a game originally written in C/C++.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: username on November 05, 2016, 06:02:49 pm
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
Thanks for the link dude.
I see that it uses Python 3 instead of the provided Python 2.7.
That means i will have to compile myself...
Also, i see you mention there's an OpenGL ES port but nothing on the page says so.
I think the Pandora port uses glshim but i'll have to check this.

That's not a problem tho, it supports OpenGL 1.4 so it can work with glshim.
I'm not sure it will actually run pretty fast, considering how bad our GPU is (just discovered this)
but i'll see if i can give it a try one day.
No issue, thanks for checking it out.

As for the OpenGL ES port, I guess it doesn't have one. Probably when the author asked me if the GCW Zero supported OpenGL ES he meant for glshim.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: Wesker on November 24, 2016, 11:50:22 pm
There's an open source reimplementation of the Alone in the Dark engine called Free in the Dark which may be a good request.

https://github.com/somaen/fitd-residualvm

This was created many years ago by a programmer called yaz0r, who also did a similar thing with an engine for the Little Big Adventure games, given that these share some development connections with the first Alone in the Dark game.

https://github.com/xesf/twin-e

But unlinke the TwinEngine which has been and still is actively developed by part of the Little Big Adventure community, the Free in the Dark engine is pretty much abandoned since years ago in a state supporting much of the first Alone in the Dark game (although it lacks some features and has several bugs which prevents game completion, despite what the readme says) and barely supporting other games in the series like Alone in the Dark 2 (playable up to a certain part of the beginning of the game) and Alone in the Dark 3 (barely playable, you can only go for a walk in the initial part of the game).

Some time ago it was added to the ResidualVM project in a attempt to breed it new life but it seems like nobody is interested in developing it any further. More recently someone ported it to the Dreamcast and did several bugfixes to it but it seems that fell through (and none of the supposed bugfixes were backported to the github).

http://www.youtube.com/watch?v=sE_7FkT0aDM

Maybe a conversion to the GCW Zero and some bugfixing/polishing to it could lead the engine into a much advanced state than it's now and that could also benefit the Windows build and other possible cross platform attempts.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on December 02, 2016, 12:42:53 am
TwinEngine seems entirely doable :
it only uses SDL libraries, which is great.
Sadly, i don't actually own that game but i'll give it a shot anyway.

Yeah, there's a dreamcast version of Free in the Dark by Corbin that's more complete than the original source
but i don't think it can be easily merged back, knowing her. (thankfully she changed her old habits)
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: zhongtiao1 on December 02, 2016, 05:37:04 pm
Yabause Sega saturn emulator or VirtualJag Atari Jaguar emulator

Jaguar: https://icculus.org/virtualjaguar/tarballs/virtualjaguar-2.1.2.tar.bz2

Saturn: https://github.com/yabause

Sent from my Q5 using Tapatalk 2
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on December 03, 2016, 01:45:13 am
I have ported a prelimineary version of twin-e, the lba engine here :
http://boards.dingoonity.org/gcw-development/*needs-testing*-little-big-adventure-engine-(wip)/new/#new (http://boards.dingoonity.org/gcw-development/*needs-testing*-little-big-adventure-engine-(wip)/new/#new)

Yabause Sega saturn emulator or VirtualJag Atari Jaguar emulator
Jaguar: https://icculus.org/virtualjaguar/tarballs/virtualjaguar-2.1.2.tar.bz2
Saturn: https://github.com/yabause
zhongtiao1, i told you about vj in the desmume thread : it is not portable
and this thing requires a hefty cpu.

As for yabause however, SpikeSpiegel made a libretro port of yabause here :
http://boards.dingoonity.org/gcw-development/(test-release)-retroarch-for-gcw0/msg139496/#msg139496 (http://boards.dingoonity.org/gcw-development/(test-release)-retroarch-for-gcw0/msg139496/#msg139496)

Mednafen also has a Sega Saturn core but right now it is very experimental.
I could try to compile it tho if you insist.

I have edited my first post to include all the requests i had.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on December 12, 2016, 05:46:50 am
I destroyed my GCW0 in the most odd way. (http://boards.dingoonity.org/gcw-help/i-destroyed-my-gcw0-with-software/msg158686/#new)
Because porting OpenGL stuff requires a console (they don't run on QEMU),
i can no longer take requests for OpenGL games.
Sorry.
EDIT: it's repaired now.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: Orion4874 on January 09, 2017, 03:28:30 am
Hey gameblabla, would you be able to take a look at porting the Sharp x68000 emulator PX68k? Someone had previously tried porting it but nothing was released. If your not familiar with this system it has a large library of great games.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on January 09, 2017, 09:56:45 pm
Hey gameblabla, would you be able to take a look at porting the Sharp x68000 emulator PX68k? Someone had previously tried porting it but nothing was released. If your not familiar with this system it has a large library of great games.
Yeah, it was David Knight who ported it and he said Px68k was way too slow on the GCW0 so that's why he has not released it.
I made an attempt before him but this failed as Px68k does not work on 64-bits operating system, making it a very difficult to test.
I think i will just ask him for da source.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: Orion4874 on January 10, 2017, 03:38:28 am
I haven't been around in a while so I'm sorry if anything I say comes off as ignorant. Trying to catch back up with the scene after a year and a half and I see you were actually able to port glishm to the Zero. Awesome work man, I know that opened up a lot of possibilities for the Pandora so hopefully it'll do the same for the Zero. Would that it any way help with giving this emu a boost in playability?
Even if you're not able to get this one working well enough to release I still want to tell you that all the work you've put in for the scene is greatly appreciated!
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on January 10, 2017, 05:05:32 am
I haven't been around in a while so I'm sorry if anything I say comes off as ignorant. Trying to catch back up with the scene after a year and a half and I see you were actually able to port glishm to the Zero. Awesome work man, I know that opened up a lot of possibilities for the Pandora so hopefully it'll do the same for the Zero. Would that it any way help with giving this emu a boost in playability?
Even if you're not able to get this one working well enough to release I still want to tell you that all the work you've put in for the scene is greatly appreciated!
Nope, because the emulator is not GPU-bound, in no way.
All the consoles before the 32-bits are CPU-dependant as far emulators are concerned because the graphics are really trivial to emulate, in most cases.
A GPU would help if the original console had internal 3D GPU (for example the PS1) but this isn't the case here :
the Sharp x68000 is just a powerful motorola cpu with basically a dumb framebuffer. (and some sprites capabilities, granted)
In that case, most of the overhead is on the CPU and GPU can't in no way significantly increase the framerate.

Also, the only good thing glshim brings is the ability to port OpenGL games, nothing else.
It's actually slower than using OpenGLES because it adds yet another layer and it can potentially slow down things.

This is more true on the GCW0, as its GPU is much weaker than the PowerVR found in the Pandora.
Add also to that the fact the gpu drivers in the firmware (etnaviv) are old and buggy and glshim doesn't actually
improve things much.

For example, Supertuxkart on glshim is actually slower than the software-renderer version on the GCW0,
if you can believe that.
Not only that but it also looks much worse than the software renderer version... lol
Hopefully etnaviv gets a KMS driver so all of that shit can be fixed.

You can try Supertuxkart here if you want to have an idea of how slow glshim is :
http://boards.dingoonity.org/gcw-development/supertuxkart-for-gcw0/msg160067/#new (http://boards.dingoonity.org/gcw-development/supertuxkart-for-gcw0/msg160067/#new)

Davy just contacted me today and he's ready to give me the source code.
Once i have it, i'll fix a few things before i release it to the public.

I appreciate your compliments, you're welcome
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: doglush on January 10, 2017, 11:38:12 pm
I hope it's the good place for this kind of request.
UAE4ALL2 ?
Because Uae4all is nice and well ported to GWCZero but doesn't support 68020 and AGA.
And the original uae4all isn't quite accurate (believe me)

Somebody interrested by this emulator ?
Thanks.

https://github.com/lubomyr/uae4all2
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: howie_k on January 11, 2017, 07:04:12 am
+1 for UAE4ALL2, as the version we currently have plays music too slowly - just listen to the intro music for Turrican 3.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on January 13, 2017, 03:46:43 am
Hmm. seems like they broke anything other than the Android version.
I need to take a closer look at it at some point
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: doglush on January 13, 2017, 04:45:50 pm
I saw different makefile and a version is working on Pandora.
But I'm not a coder... Maybe it's a lot more hard to port on GCW
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on January 13, 2017, 08:21:58 pm
I saw different makefile and a version is working on Pandora.
But I'm not a coder... Maybe it's a lot more hard to port on GCW
It shouldn't be hard to port.
The issue is that this source code has missing code !
Notably, it lacks the guichan header files.

I tried the pandora build but this does not suceed, same issue. I wonder how they managed to build it for the Pandora.
It's probably not that version
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: CREEPINGIRON on February 13, 2017, 05:43:15 pm
I know Goldeneye is a Nintendo 64 game but is it possible to make the ROM standalone with new controls?
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on February 13, 2017, 06:06:03 pm
I know Goldeneye is a Nintendo 64 game but is it possible to make the ROM standalone with new controls?
Goldeneye is a RARE game so it's not legally possible to make a standalone OPK.
Plus i don't think Mupen64Plus emulates that game very well...
A frontend for Mupen64Plus would be a better idea but nobody is currently working on it sadly.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: Durrsly on February 26, 2017, 05:26:37 pm
Would Xash3D be possible? I know there's a Pandora and Android versions, so could the Zero run it?
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on February 27, 2017, 12:22:48 pm
Would Xash3D be possible? I know there's a Pandora and Android versions, so could the Zero run it?
Yeah, it should. should...
The problem is that etnaviv is kind of crappy at the moment so i bet the game will not even boot (or look properly).
I'll wait until the next firmware gets released.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: CREEPINGIRON on June 25, 2017, 12:35:04 pm
Is NullPomino possible to port?

It's a great open source Tetris.

Download: https://nullpomino.en.uptodown.com/windows .
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on July 14, 2017, 02:13:59 am
Is NullPomino possible to port?

It's a great open source Tetris.

Download: https://nullpomino.en.uptodown.com/windows .
it's programmed in Java, and Java is slow as hell on the GCW-Zero. (because Java will probably never have a jit for MIPS)

It should be possible on the Pandora/Pyra though (Minecraft runs on it after all) but i don't have one.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: CREEPINGIRON on July 21, 2017, 07:01:22 am
What language should I look for in a Tetris game? There are tons of these and I just want to see one ported someday.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: Aeter on July 21, 2017, 05:40:15 pm
My guess would be something written in C or Python. And games using SDL library.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on July 22, 2017, 12:31:07 am
Yes, Aeter is correct. C/C++ are the way to go.
As far graphics is concerned, SDL is preferred. But OpenGL ES 1.x is also okay. (OpenGL 1.x might work too, depending on the game)

If it's in Python, it could work too but i'm not used to that language.
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: davidgilmour on July 30, 2017, 01:50:30 pm
What language should I look for in a Tetris game? There are tons of these and I just want to see one ported someday.
Best tetris game is Tengen Tetris in the arcade, petfectly playable with xmame on GCW
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: doglush on August 02, 2017, 09:09:48 pm
or fs-uae ? :)
https://fs-uae.net/download#source
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: davidgilmour on August 03, 2017, 12:17:44 pm
or fs-uae ? :)
https://fs-uae.net/download#source

Isn't this almost the same?
http://boards.dingoonity.org/gcw-releases/uae4all-release-1/
Title: Re: Request thread (NO SOURCE = NO PORT)
Post by: gameblabla on August 04, 2017, 01:25:56 am
Actually no, FS-UAE is based on WinUAE (i think) while UAE4ALL is based on a very old version of UAE  (but fast)
that is only capable of emulating the Amiga 500.

I actually don't know its dependencies but surely, there must be a reason why no one has attempted it.
It's fairly CPU-intensive too