Port Requests


I only ported ASCIIpOrtal from Cymon's game, wich is a great game. That github links looks nice, with plenty of simple things inside.
 
Last edited:
I have a re- request :)
Could some one take a look at OpenRA again?
It's been a while and things have improved on both Pandora and OpenRA side. If I recall correctly ptitseb was working on it... long ago ;)
 
I have a re- request :)
Could some one take a look at OpenRA again?
It's been a while and things have improved on both Pandora and OpenRA side. If I recall correctly ptitseb was working on it... long ago ;)
OpenRA still (probably) need OpenGL 2 and/or some GLES2 port. I have it on my todo, but that will have to wait after gl4es 1.1 or 1.2 at least (not completly sure of the detailled roadmap here).
 
OpenRA still (probably) need OpenGL 2 and/or some GLES2 port. I have it on my todo, but that will have to wait after gl4es 1.1 or 1.2 at least (not completly sure of the detailled roadmap here).
If you look at it from long distance, converting a game from GL1.x to GLES1.x is "just" a matter of converting the glBegin/glEnd, but if you get into the details you discover there's tons of details to cover to have something usable (have a look at gl4es' code to get how complex this realy is).
Converting a game from GL2.x to GLES2.x from long distance already looks very complex : translating shaders on the fly, support of GLES1 on GLES2 (yes while GL is always backward compatible, GLES never is. So to support GL2 games one have to support GL1 on GLES2 which itself is a long project on its own), add extentions to the mix and you already see what a mess this is going to go... And trust me, if you have a deeper look, the number of details to handle is just tantalizing...

PS: @ptitSeb, this wasnt for you obviously : you know all this way more than me :p
 
If you look at it from long distance, converting a game from GL1.x to GLES1.x is "just" a matter of converting the glBegin/glEnd, but if you get into the details you discover there's tons of details to cover to have something usable (have a look at gl4es' code to get how complex this realy is).
Converting a game from GL2.x to GLES2.x from long distance already looks very complex : translating shaders on the fly, support of GLES1 on GLES2 (yes while GL is always backward compatible, GLES never is. So to support GL2 games one have to support GL1 on GLES2 which itself is a long project on its own), add extentions to the mix and you already see what a mess this is going to go... And trust me, if you have a deeper look, the number of details to handle is just tantalizing...

PS: @ptitSeb, this wasnt for you obviously : you know all this way more than me :p
Yeah, the GL2.x to GLES2.0 version of gl4es iss very far away! So much things to do, so many details. But, step by step, something can probably be done. My plan is to first track every states of GL1.x (that gl4es v1.0 basically), that add an optionnal GLES2 backend and start emulating fixed pipeline in shaders (that's gl4es v2.0), along the way, adding support for GLES2 shader (that when port of OpenRA or Pioneer can be done, with hand-modification of shaders), and then, in a possible far far away future, put a GL2->GLES2 shader converter and so having GL2.1 emulation (that's gles v3.0).
 
Hi all :)

@EvilDragon : could you sell a possible Dreamcast port at your shop, like you did with Fruit'Y (in some nice little cases I told you about via PM... ;) ) ?

No worries, I'm publishing all Retroguru games for the DreamCast, and this one is already heavily being planned on.
However, they'll come in transparent jewel cases (like W&W).
Those little cases won't help as we'd need them in the CD factory so they can seal them.
 
more stuff

DestinationSol space 2d shooter https://github.com/MovingBlocks/DestinationSol

Aigilas Linux, Java but looks not demanding https://github.com/XBigTK13X/Aigilas
http://web.archive.org/web/20160619170539/http://presskit.simplepathstudios.com/sheet.php?p=aigilas

Munchoid same author
https://github.com/XBigTK13X/Munchoid

W6 war simulation c++ but for Haiku and with comments in French
http://lema.link-u.com/be/w6.html
https://github.com/TheNavigat/W6/tree/master/W6Haiku

SDLpal famous chinese game (seems to exist for many mobile devices, but seems npt to be in repo)
https://github.com/sdlpal/sdlpal
 
Last edited:
Not only it uses DirectX but it also makes use of a proprietary library : Luna. Only a binary blob for Intel x86 is provided for it.
I guess a replacement could be done since the header is available but good luck with that....

here seems to be a source archive
http://web.archive.org/web/20061202084448/http://www.twin-tail.jp:80/
http://web.archive.org/web/20061207113647/http://www.twin-tail.jp/luna_new.zip

here the original homepage
http://web.archive.org/web/20061105011953/http://luna.sumomo.ne.jp:80/

maybe then compileable with https://wiki.winehq.org/Winelib
 
Last edited:
Not sure if there is an issue

But it would be nice to have a new chromium with widevine for that Netflix goodness... I have done with android boot with Netflix app but it's a pain and the only reason I boot android.

Nice thing is the Pyra should be able to do it
 
It should be noted that the open source version of osu! is still under heavy development and is not the currently officially supported client you can download on the osu! website.
I also fail to find any reference to what the version requirement for the OpenGL renderer would be (either client). The new one is using shaders though and I don't see any ES code around.

Performance would also be questionable. opsu! was worth trying, but barely gets above 20 fps on the Pandora. That was Java. Not sure if Mono would perform much better.
The current stable client runs above 60 fps on a Z3735F Windows tablet, but a whole lot more. In case that's useful as a reference.

Maybe in the future, though.

For fast code, McOsu would be preferable (C++). But I noped out of suggesting that client since it requires OpenGL 3.
 
Back
Top