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

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #15 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.

Senor Quack

  • *
  • Posts: 159
Re: Request thread (NO SOURCE = NO PORT)
« Reply #16 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++.
« Last Edit: November 03, 2016, 06:56:57 PM by Senor Quack »

username

Re: Request thread (NO SOURCE = NO PORT)
« Reply #17 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.

Wesker

Re: Request thread (NO SOURCE = NO PORT)
« Reply #18 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).

<a href="http://www.youtube.com/watch?v=sE_7FkT0aDM" target="_blank">http://www.youtube.com/watch?v=sE_7FkT0aDM</a>

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.

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #19 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)
« Last Edit: December 02, 2016, 12:44:49 AM by gameblabla »

zhongtiao1

Re: Request thread (NO SOURCE = NO PORT)
« Reply #20 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
« Last Edit: December 02, 2016, 05:39:10 PM by zhongtiao1 »

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #21 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

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

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.
« Last Edit: December 03, 2016, 01:54:44 AM by gameblabla »

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #22 on: December 12, 2016, 05:46:50 AM »
I destroyed my GCW0 in the most odd way.
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.
« Last Edit: December 13, 2016, 01:13:25 AM by gameblabla »

Orion4874

  • *
  • Posts: 229
Re: Request thread (NO SOURCE = NO PORT)
« Reply #23 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.

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #24 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.

Orion4874

  • *
  • Posts: 229
Re: Request thread (NO SOURCE = NO PORT)
« Reply #25 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!

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #26 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

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
« Last Edit: January 10, 2017, 05:10:13 AM by gameblabla »

doglush

Re: Request thread (NO SOURCE = NO PORT)
« Reply #27 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

howie_k

  • *
  • Posts: 136
Re: Request thread (NO SOURCE = NO PORT)
« Reply #28 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.

gameblabla (OP)

  • *
  • Posts: 394
Re: Request thread (NO SOURCE = NO PORT)
« Reply #29 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

 

Post a new topic