Video Preview in EmulationStation

Nismo

@fieldofcows I think it's more easy for noobs a binary release instead of needing to compile...

When more people can test it more easy to find bugs and solve... i whould like as stable version as possible.

But let people say their opinion.

Zigurana

@fieldofcows
There is also the possibility of setting up a module in the retropie expermental settings, which would allow users to install the latest version from github, by cloning into it and building it on their pi's. All automated, just takes an hour or so. See this for an example.
This way, you do not need to keep building binaries for the pi, and people always get the latest and greatest. (Although it's nice to be able to fall back on older versions as well, esp for more experimental branches).

Nismo

Thi is definitively better, almost for Rpi users.

cyrax3

@Nismo said in Video Preview in EmulationStation:

Thi is definitively better, almost for Rpi users.

not only for rpi user but also for a noob windows users like me...i'm not able to compile a sotware and a "downloadable .exe" is the best thing. you are the only ones who have progressed to this fronted (windows version)

herb_fargus

@Zigurana what would really be ideal is if we stopped creating multiple forks and focused on integrating singular features that can be tested to be included in the retropie fork- lots of people have had great ideas and made some great improvements between you with kids mode, jacobfk20 with gridview and this one with video support, along with a few other features on the way. Jools has been amicable to accepting good tested code and perhaps it would be good to start submitting some clean pull requests for testing and inclusion.

fieldofcows

@herb_fargus said in Video Preview in EmulationStation:

what would really be ideal is if we stopped creating multiple forks and focused on integrating singular features that can be tested to be included in the retropie fork

I don't see any harm in creating forks so long as the purpose isn't to compete with the forked repository but instead to provide a space to collaborate on major feature development. I am reliant on others to make suggestions, test, provide themes, etc. in order to make the video feature work so forking the repository provides me with a useful tool to achieve that. Once we have got to a stage where the code is tested and stable I fully intend to submit this back to the retropie fork.

Zigurana

I agree with the sentiment that forks are fine for the experimental testing stage, for instance: I had the child-friendly stable for about 9 months, only to have it blow up in my face because of a use case I had not anticipated. At that point I was glad I had not yet taken the time to polish it down into a PR which, if accepted, would have impacted many more people.

But I agree with you both, delivering back to the Retropie branch should be the end goal. Its reassuring to see Buzz come around to that point of view.

herb_fargus

@fieldofcows yes, I misspoke, thanks for clarifying. Not anything wrong with creating forks as that's what the code is for, but once aloshi left ES has become very fragmented so there are lots of great ideas without a central home or maintainer to combine all the good ideas. Hopefully retropie can be the home for some of them and I agree its good to have a separate fork for testing new features. I appreciate that you're willing to put in the work to help push some of it upstream

fieldofcows

@herb_fargus What your post has reminded me of that I have to be careful to separate out the different bits of functionality I have been working on, being mindful of the ultimate merge back into the parent. What hasn't helped is that I'm new to git and used to a subversion workflow, naively committing everything to master. I'm going to try to sort that out.

Zigurana

@fieldofcows I feel your pain, as I am climbing the same learning curve. My current way of working is to branch off from Retropie-master for each new feature. Then I'll push to my own remote during development. Once all is in good shape and functional (which will take many commits), I will not just merge into my master or create a PR.
Rather, I am planning to rebase to my master (with the --interactive flag) squashing all commits as much as possible. This should then create a single clean delivery-commit which can be the basis for a PR to be considered by the Retropie team.
At least, that's my plan atm :-).

dankcushions

@fieldofcows said in Video Preview in EmulationStation:

@herb_fargus What your post has reminded me of that I have to be careful to separate out the different bits of functionality I have been working on, being mindful of the ultimate merge back into the parent. What hasn't helped is that I'm new to git and used to a subversion workflow, naively committing everything to master. I'm going to try to sort that out.

yeah this is crucial. you also should consider only distributing versions that have these singular features on, so that the community are testing that rather than everything you've added (which likely won't be accepted in the one PR)

Nismo

@cyrax3 said in Video Preview in EmulationStation:

@Nismo said in Video Preview in EmulationStation:

Thi is definitively better, almost for Rpi users.

not only for rpi user but also for a noob windows users like me...i'm not able to compile a sotware and a "downloadable .exe" is the best thing. you are the only ones who have progressed to this fronted (windows version)

This feature is only for retropie, not compatible with windows, that's because i said "almost for Rpi".

Nismo

@herb_fargus said in Video Preview in EmulationStation:

@Zigurana what would really be ideal is if we stopped creating multiple forks and focused on integrating singular features that can be tested to be included in the retropie fork- lots of people have had great ideas and made some great improvements between you with kids mode, jacobfk20 with gridview and this one with video support, along with a few other features on the way. Jools has been amicable to accepting good tested code and perhaps it would be good to start submitting some clean pull requests for testing and inclusion.

I'm with you, having a main fork with all features from the developers whould be great, but the problems comes when, while fieldofcows is trying to keep cross-platform compatibility, jacobfk20 is only focused in linux compatibility, like he said:

This version of ES will not run on Windows, but it will run on ANY linux distro. I could make it run on Windows but will have to omit some features.

Source: https://retropie.org.uk/forum/topic/3121/emulationstation-mod/7

So for some developers can be a pain to implement cross-platform compatibility. Emulationstation is a nice cross-platform frontend and whould be nice to keep it that way.

Regards.

Nismo

@fieldofcows I finally succeeded in reproducing the issue of relative path!!! (yes still not working well on beta 7), and why some paths are changed and some paths not.

Ok let's start, i have only one game in my gamelist:

<?xml version="1.0"?>
<gameList>
  <game>
     <path>./Contra.zip</path>
     <name>Contra</name>
     <image>~/.emulationstation/downloaded_images/nes/Contra-image.png</image>
     <video>~/.emulationstation/Videos/Contra.mp4</video>
     <marquee>~/.emulationstation/Marquees/Contra.png</marquee>
  </game>
</gameList>

If ES find both videos and marquees the path changes but still relative and ok:

<image>~/.emulationstation/downloaded_images/nes/Contra-image.png</image>
<video>./Videos/Contra.mp4</video>
<marquee>./Marquees/Contra.png</marquee>

If ES doesn't find video but find marquee:

<image>~/.emulationstation/downloaded_images/nes/Contra-image.png</image>
<video>Z:/EMU//.emulationstation/roms/nes/Videos/Contra.mp4</video>
<marquee>./Marquees/Contra.png</marquee>

If ES find video but not marquee:

<image>~/.emulationstation/downloaded_images/nes/Contra-image.png</image>
<video>./Videos/Contra.mp4</video>
<marquee>Z:/EMU//.emulationstation/roms/nes/Marquees/Contra.png</marquee>

If doesn't find both of them:

<image>~/.emulationstation/downloaded_images/nes/Contra-image.png</image>
<video>Z:/EMU//.emulationstation/roms/nes/Videos/Contra.mp4</video>
<marquee>Z:/EMU//.emulationstation/roms/nes/Marquees/Contra.png</marquee>

So i hope this help you to find what's the problem. Yes still double back slash issue :(

Regards.

tronkyfran

@Nismo I have a theme on a half way since some time, and its very similar to yours in concept, hope you dont mind. In any case it will take a long time to finish because its 3d and all that, so maybe youll forget about this!! xD

Nismo

@tronkyfran Of course no problem mate, when more themes coming for this fork, will be better.

And the theme is not only my theme, like i said before it's a port from the original oldroom theme for attract mode: http://forum.attractmode.org/index.php?topic=926.0

Credits to Spinelli (psd file), Cobra83 and bundangdon for some backgrounds, credits to litzoid for system art. (All is in the readme file included in the theme)

I put a lot of work in this theme, i pick some backgrounds from there (of course under permission of all creators and litzoid too) and i added a lot of things that not there, reflections, more stuff, figures, cartridges, etc.

And placing all the image files and videos is a pain, he he he, and edit a lot of xml files, you know.

The theme originally only have a few systems, about 4 or 5 , the rest it's original from me (i have 14 systems now), and i share my work there to contribute the project.

Anyway is your theme compatible with this version?, my theme doesn't work on "vanilla" version of emulationstation.

Good look with your theme, i whould like to see some screens... XD

Regards.

fieldofcows

@Nismo said in Video Preview in EmulationStation:

my theme doesn't work on "vanilla" version of emulationstation.

I'm working on that :) I have spent some time splitting just the video view out into a separate branch. When that is done and tested I'll submit a pull request to the retropie EmulationStation fork and see what happens.

Don't worry @Nismo, I'll maintain a development branch with all the new bits we've been working on and not just the video for your Windows platform.

Rion

@fieldofcows Just because I think you're doing such a great job and it's Friday im sending you a virtual Beer!

fieldofcows

@Rion said in Video Preview in EmulationStation:

@fieldofcows Just because I think you're doing such a great job and it's Friday im sending you a virtual Beer!

Haha! Received with thanks. I'll drink it later - after work :D

fieldofcows

@Nismo said in Video Preview in EmulationStation:

I finally succeeded in reproducing the issue of relative path!!!

I've now reproduced it to thanks to your info. This is a pre-existing issue in ES and not related to the video view changes. I think my experimental metadata patch should fix this. I'll put together a fix and pull it into my Windows dev branch and give you a new build when it's done.