Port Requests


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).
 
I have been looking Ootake and it seems to use DirectX9 so I think I hve my answer XD.
 
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.
 
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.

Interesting, thank you for the infos! As you seems knowledgeable... how is the compatibility of these different clients, are they "drop-in" substitutes (compatible fileformats, interfaces etc)? Also, what makes osu! (or the other client variants) special / successful over the other earlier rhythm freeware /FOSS games (Stepmania, fretsonfire etc)? I'm still surprised by the size this freeware game's community achieved... can't currently really grasp what is the special thing here.
 
I'm not an expert at rhythm games or the exact history of osu in terms what made it so popular. I've just been casually playing it for around 8 years according to my account age there. People like clicking circles, I guess?
I mean, it is a different approach to a rhythm game so it stands out. The concept is taken from the Osu!/EBA DS games, but I don't remember any other clone that had taken off like osu! did.

There are also other game modes, which are all very solid a polished, but are actually way less popular. I don't have exact numbers to back that up as it turns out the play count is for all modes, but I keep seeing the same names in the top scores when it comes to osu!mania and getting into the top 50 there isn't that hard. Beatmaps made specifically for other modes are also created much less, but you can always play standard ones which are automatically converted.

Another thing I can think of is the fact that the community is active and keeps making new beatmaps. It's also easy to access individual songs. When I set up stepmania for my Pandora I didn't exactly struggle with finding songs, but it was hard finding something that wasn't already a few years old and not buried in a pack full of things I didn't want.
This goes mostly for anime-related or japanese songs. If you're not into that, you'll probably still find some stuff you like, but it'll be in the vast minority.


That's it for osu! itself. About the clients... they aim to be drop in substitutes, supporting the beatmaps formats and copying the UI looks. Online ranking is off-limits for them, though. iirc that will also be unavailable for unofficial builds of the osu! open source client.
It's been a while since I've last looked at opsu! and I'm not sure if the efforts are still going after the open source announcement of osu! itself. It wasn't a smooth polished experience, but it worked fine.
McOsu! aims to be a training client, mimicking osu! as accurately as possible while giving additional gameplay options and VR support (may sound weird at first, but it's actually really fun). Actually pretty smooth and polished in all it implements too, even though it's an alpha.
Both of these only support osu!standard beatmaps and also only implement that game mode as of now.
Replays aren't (yet) supported by either of them. McOsu! doesn't plan to store replays in the same format as osu!, though.

That's about it, I think. In the end I'm just a casual player of it, though I've been playing it a good bit more recently than I have a few years ago.
And yes, it's lovely to play with a touch screen and stylus. But as a fair warning, harder maps are actually not suited for that (or any handheld play for that matter).
 
Last edited:
Back
Top