Video Preview in EmulationStation

Nismo

@fieldofcows new system coming...

Game boy:

Do you like it?

fieldofcows

@Nismo Haha! Yes! Do you ever stop?

Nismo

@fieldofcows said in Video Preview in EmulationStation:

Do you ever stop?

Not for now... he he. Keep the ball rolling...

fieldofcows

@Nismo said in Video Preview in EmulationStation:

Not for now... he he. Keep the ball rolling...

My thoughts exactly. I'm enjoying working on ES and am quite keen to implement some of the big features that people are after along with some of my own. This thread is not the time or place and supporting your theme is my priority at the moment but it would be nice if some of the changes we are working on gain momentum and get pulled into general use.

Nismo

@fieldofcows yes, i'm with you, you did a few fixes apart from theming. When are you planning to lauch the Rpi build?

fieldofcows

@Nismo I built it last night and was just in the process of setting up a fresh image on and SD card to test it and write up some instructions when I noticed how late it was so I went to bed :) It's not far away...

I'm not sure the best or proper way to distribute this ES version. Should I just publish a binary as a release in GitHub that is compatible with a retropie image like I have done for Windows or should I provide build instructions? Anyone?

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.