[garbear]

Thanks for testing! I think it's safe to say that my experiment with VideoPlayer has failed. This was my expectation all along. VideoPlayer is inherently built for synchronization - not realtime. It has multiple stages - input, demuxing, decoding and displaying. Each with its own possibility to buffer, each with its own delay.

Now that 100% of RetroPlayer has been merged into VideoPlayer, I can start building a low-latency player from scratch, using parts of VideoPlayer as the building blocks while keeping the code size absolutely minimal. I must say, as far as failures go, this was a pretty successful one

I'm uploading a new build if anyone wants to test Montellese's new feature - On windows, controllers will power off on exit. This will be my last VideoPlayer-based build until the new RetroPlayer is ready.

[EMK0]

maybe you already know, your latest build has no download links

[garbear]

That's because it's still building I finished writing the new RetroPlayer a few hours ago! OSX is ready now, but the windows build is stuck in a long Jenkins queue.

The new RetroPlayer is much improved. It is currently quite simple, supporting just Play and Pause. However, starting from scratch allowed me to design an extendable system that can scale to the ultimate player we all desire. The player has been abstracted at such a level as to allow fully-reversible playback (rewind, seek). Currently a bunch of TODOs, but now that the design is finalized, only thing left is to implement it

[MrTarantula]

I have a build ready for Ubuntu 14.04 x64, The link is in the Linux Testing thread, but I'll post it here too.

https://goo.gl/jfkG3v

[flipside101]

New OE builds

https://openelec.freestylephenoms.com/retroplayer/

You must remove a couple addons, you can do this via the kodi GUI or via SSH

Please remove game.libretro, peripheral.joystick, and peripheral.steamcontroller

Code:

rm -rf /storage/.kodi/addons/game.libretro
rm -rf /storage/.kodi/addons/peripheral.joystick
rm -rf /storage/.kodi/addons/peripheral.steamcontroller

These add-ons have now been built into the system because it isn't possible to track their versions while using them as an installable add-on.

@irusak I don't suppose you have a plan to produce libreelec builds of this do you. I've just moved over and have retroarch running but would love to get rp back

Sent from my SGP512

[cabbresson]

[/quote]
@irusak I don't suppose you have a plan to produce libreelec builds of this do you. I've just moved over and have retroarch running but would love to get rp back

Sent from my SGP512
[/quote]
+1

[lrusak]

I've been rebasing my commits the whole time, I just haven't produced anything useable as of yet. Hopefully soon.

You can follow the progress here, https://github.com/lrusak/LibreELEC.tv/c...er-kodi-17

[flipside101]

Loving your work

Sent from my SGP512

[EMK0]

That's because it's still building I finished writing the new RetroPlayer a few hours ago! OSX is ready now, but the windows build is stuck in a long Jenkins queue.

The new RetroPlayer is much improved. It is currently quite simple, supporting just Play and Pause. However, starting from scratch allowed me to design an extendable system that can scale to the ultimate player we all desire. The player has been abstracted at such a level as to allow fully-reversible playback (rewind, seek). Currently a bunch of TODOs, but now that the design is finalized, only thing left is to implement it

Oh sorry, anyways just tested it out wow big improvement games are running a lot smoother few things i notice

the sound is not 100% correct it has random crackling/clicking in all the emulators i played with, maybe they still are not running at full speed and this is why we get sound glitches?

and i was testing with retroarch side by side problem with Kodi right now if you focus on another window it still is taking gamepad inputs
since it does that i can run a game at the same time on both and control both what i notice is most of the lag is gone but i still feel like retroarch is still a bit more responsive but it could just be my imagination
i would have to record a video to see if there really is any difference in input lag

i will do a debug log test when i have time this is just what i noticed playing around with it a bit.

[garbear]

Testing side-by-side with retroarch is a good idea. I've had "controller input not ignored" as an issue for so long, but now I see this as a feature

The crackling/clicking is probably due to timing errors. I scale audio to avoid resampling (e.g. 32040.5 hz -> 32000 hz) and also scale video likewise. Maybe Kodi's VSync timing is throwing things off. I'll look into it

[garbear]

I fixed broken .zip support. Files in zips still require a libretro core with VFS support, but compatible clients can play them now. New builds up later today

[the_bo]

Awesome work Garbear always look forward to your posts.

I'm looking forward to the official retroplayer release. Have fingers crossed if you could make it into krypton release in time, i know thats a bit hoping Maybe with kodi's RERO cycle is there possibility?

Kodi is gonna be a beast of a mediacenter with retroplayer.

Keep up great work man.

[garbear]

Krypton has my controller support, which is enough for one release. we don't want to introduce too much code too fast.

At the time, controller support was over 2/3 of the entire RetroPlayer patch, so ATM RetroPlayer is more merged than not. By the time the new RetroPlayer is finished, it'll probably be 50/50 with the controller stuff.

To whet your appetite, the new RetroPlayer has an API for nonlinear seeking. Before, you could rewind or seek in reverse. Cool. But once you did, the frames were lost and you had to play forward again.

With nonlinear seeking, you can rewind, play a bit, and then seek forward to recover the frames and "undo" the rewind. This means that accidentally rewinding isn't the end of the world, as long as you don't play forward past where you were at, you can seek to the spot from before you rewound.

Th effect is recursive. So if you play 60s, rewind 60s, play 30s, rewind 30s, then you can seek to two alternate timelines. Seeking forward < 30s will recover gameplay from the second run. Seeking 31s will recover gameplay from the first run.

I've also abstracted savestate compression. The size of the state of an entire game consol's hardware can be huge. savestate differences are incredibly low entropy. With efficient huffman encoding, we could easily have seek buffers on the order of minutes. Combined with nonlinear seeking, this could make for some interesting gameplay strategies.

[lrusak]

New LibreELEC Retroplayer builds!

So these new builds are based on LibreELEC master and garbear's latest work from here

These new builds aren't quite functionally on par with the old builds as garbear has been working on refactoring retroplayer into the latest Kodi codebase.

So if you want to play games stay on the old builds. I will leave them there until we are functionally on par.

We always appreciate testers though and it's a good way to test both the new retroplayer Kodi and the current state of LibreELEC master.

Builds are still located here, https://openelec.freestylephenoms.com/retroplayer/
I will soon be moving my builds to http://lrusak.libreelec.tv/

More builds will be coming soon, for now Generic and RPi2 builds are all I am providing.

Happy Testing!

[garbear]

Thanks for the LibreELEC builds. On my part, I've fully implemented rewind & reverse seeking again. New builds will be up shortly.

Rewind relies on save states internally. Now it's simply a matter of writing these save states to the hard drive. The next build will contain save state support. It'll be simple, because there's no game database. Prolly just write a save state to the ROM's filename + .sav. How do other emulators do automatic savestates?