[mcobit]

Yes, I’ve read that. But as long as he does not release his work, we might have to live with what we got.
Apart from some simple optimisations all of that is over my head.

If somebody else is actually able to reimplement this, it would be really nice.
But that’s not me.

[mcobit]

Good to hear that it works. This version is compiled with all neon etc. flags so it probably won’t run on a raspberry pi 1. But as the pi 2 has the cpupower to decode the videostream in software it should run fine on that.
I can upload my sources if it is desired, so it could be incorporated into the retropieimage. Would be a bit hard to get it set up with all the different files etc. but might work.

The DaphneLoader cannot be used on the pi unfortunately, but copying the files from your Desktop machine should do the trick.

Edit: Reencoding the videofile(s) to lower bitrate and/or resolution could bring a potential speedup and might not be so heavy on sdcard-readspeed.
Also I could try to use tremor instead of vorbis to read the audiofiles.

Also, there seems to be a newer revision of libmpeg2 as the one used in vldp2. That one seems to have some arm optimisations. Will try to include that tomorrow to see if it can bring more speed and will not be so heavy on the cpu.

[mcobit]

I am sorry, forgot to include the library.
Please redownload and try again!

http://141.2.136.155/daphne-RPI2.tar.bz2

[mcobit]

No. All software decoded. The library should be next to the binary daphne. Did you use the run.sh script?

Have a look if I set the LD_LIBRARY_PATH correctly in it.

It should point to the current directory.

You could also use
LD_LIBRARY_PATH=. SDL1_VIDEODRIVER=dispmanx ./daphne yourgame vldp -framefile yourframefile.txt

[mcobit]

If anyone wants to give it a go:
http://141.2.136.155/daphne-RPI2.tar.bz2

Use the following syntax to run a game:

chmod +x run.sh
./run.sh yourgame /full/path/to/your/framefile.txt

See if it works.
You need to have the dispmanx SDL installed.

[mcobit]

OK, OpenGL acceleration is out of the question for now as it needs OpenGL 2.0 what is not supported by glshim.

But the SDL version runs good on the Pi2 with dispmanx SDL.

[mcobit]

Probably I could try to convert the OpenGL scaling code to GLES or just use some wrapper. Won’t take the decoding work off of the cpu though.
Tried GPWorld and it works fine until you start driving. then it will freeze when you reach a certain speed and play again when it slows down. Looks like the Hardware struggles to decode at faster than original speed.
Will try to get some other game running this evening and rebuild with some more agressive optimisationflags.

Also, if I use resolutions smaller than 1920×1080 the screen will not be in the middle but cut off at the top. But maybe this is just a problem with my setup. Need to get a Pi setup just for developing I think. Using dispmanx-sdl driver to scale up 640×480 to fullscreen in the videohardware could also lead to more performance.

But I’ll check that when I got it more stable.

[mcobit]

I got a first version compiled and working on a pi 2. Video is smooth but it crashes from time to time and the inpit doesn’t seem to be responsive all the time. Need to test some more.

Too bad that he got it running already but won’t release a version for the pi.
I don’t have the knowledge to add a lot to the code. I just hacked it up to get it compiled.

[mcobit]

That should very well be possible. I did an arm port some years ago for the OpenPandora.
Not of 1.0 though but 0.9something.
It needs some cpu power to decode the mpeg2 stream though what will be hard for a Pi 1 but pretty manageable on a Pi 2.
If someone can get it to use the hw decoder with the screen overlays it should be easy even for a Pi 1 to decode the video.

You still need to get the vudeofiles and framefiles from the Windows version though as the frontend is written in delphi if I remember correctly and can not easily be ported to arm architecture.

I think I’ll give it a go sometime.

[Author]

Posts