RetroFE forums

General Category => Announcements => Topic started by: Pieter Hulshoff on December 07, 2016, 10:36:24 AM

Title: RetroFE development
Post by: Pieter Hulshoff on December 07, 2016, 10:36:24 AM
I have created an issue list on bitbucket: https://bitbucket.org/phulshof/retrofe/issues?status=new&status=open
You can find all the feature requests there, and I will update it as features get added and/or as feature requests come in. :)
Title: Re: New features
Post by: JonahUK on December 10, 2016, 05:00:16 PM
Would love to see per system themes at some point without using workarounds such as two or three tier menus :)
Title: Re: New features
Post by: Pieter Hulshoff on December 10, 2016, 05:23:55 PM
Per system themes already work, unless you mean per menu item themes so each system can look differently on the main menu.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: JonahUK on December 10, 2016, 07:02:37 PM
Lol, yes, per menu item is what I meant :)
Title: Re: New features
Post by: Tom Acunzo on December 22, 2016, 12:37:12 AM
I just pushed out the RetroFE MacOS build to my fork (http://"https://bitbucket.org/RetroPrime/retrofe")!

I noticed that you recently added new changes to yours. I guess I have to sync what's changed between the two builds? I'm new to bitbucket so any tips would be appreciated before I issue a PR.

Notes:
* I updated the README.md. Linking URLs outside seems broken, leaving out quotes makes links internal.
* The RetroFE brew formula isn't live. So brew install won't be active yet.
* I assigned 0.7.20 in the Version.cpp. Is this about right?
* I patched png files with pngcrush (see readme)
* I used the icon (http://"http://www.retrofe.com/forum/index.php?topic=278.msg1482#msg1482") from fan art.

I found a bug in RetroFE that I also confirmed with emp.
RetroFE will crash during the routine exit / quit if a Dualshock 3 controller is still mounted via usb or with bluetooth. I don't know if this will happen with other controllers but it's easy to test.
Title: Re: New features
Post by: Pieter Hulshoff on December 22, 2016, 09:13:48 AM
Normal procedure is to merge my latest code with your branch, double check, and then do a pull request. Version 0.7.20 is fine, but for the future I'd prefer it if you leave the version numbering to me. :)

I'm aware of the crash, but I haven't been able to reproduce it yet, so I haven't been able to debug the problem yet either. It's on the todo list though, but if you feel like debugging it before I have time, please feel free. :) I'd appreciate the help in this regard.
Title: Re: New features
Post by: Tom Acunzo on December 22, 2016, 10:30:31 AM
Noted. ;D  I merged your changes with mine and RetroFE ran well locally. I pushed them back to my fork to keep things in sync. I have a couple brew tests before creating the pull request. I'll keep you posted.
Title: Re: New features
Post by: Pieter Hulshoff on December 22, 2016, 11:43:42 AM
Thanks. :) Looking forward to seeing your work. I'm hoping to get some people to test on Windows soon; I'm not 100% sure all changes I made will compile under Windows.
Title: Re: New features
Post by: Tom Acunzo on December 22, 2016, 10:51:16 PM
I'm happy to contribute! The more platforms the merrier right? I just sent you a PR.  8)

We need some test users from the community. Maybe as people introduce themselves they can specify their platform of choice. There are definitely some unknowns out there for each platform.

Nothing major but I was checking the RetroFE logs and I notice some output about missing directories / files that may have something to do with an out of sync Package/Environment/* in bitbucket.

I ran out of time to investigate but one that stood out to me was:
/meta/hyperlist/ was in bitbucket but I didn't see /meta/mamelist in there. You see messages in the logs.

grep not log.txt
[2016-12-22 07:36:11] [INFO] [Configuration] Could not open /usr/local/Cellar/retrofe/0.7.20/collections/Main/info.conf"
[2016-12-22 07:36:13] [ERROR] [CollectionInfoBuilder] Could not read directory "/usr/local/Cellar/retrofe/0.7.20/meta/mamelist"
[2016-12-22 07:36:18] [INFO] [CollectionInfoBuilder] Could not read directory "/usr/local/Cellar/retrofe/0.7.20/collections/Main/roms". Ignore if this is a menu.

Perhaps that's an empty folder in need a of file or dot file?

I also recall messages about missing layout.xml inside of collections/layout. Would a layout folder be inside collections? I wasn't able to reproduce that so it might have been a fluke of an older build. Unsure.  :-\
Title: Re: New features
Post by: Pieter Hulshoff on December 23, 2016, 07:35:45 AM
I think those messages should be (changed to) INFO messages. Those are optional files that do not need to be there.

Thank you for the changes by the way. It's great that RetroFE will also be working on MAC-OS. :) Next step is to have someone do a Windows build to make sure everything still compiles on that OS; I may need to change some code in the hierarchical rom directory support for that.
Title: Re: New features
Post by: Agent47 on December 23, 2016, 03:01:50 PM
I tried doing a windows build last night and ran into a cmake error when generating the VS project. I'm gonna give it another go to make sure I didn't do anything dumb last night (it was late). I've compiled it in the past w/o issue so not sure if I just messed something up this time or if something has changed.
Title: Re: New features
Post by: Pieter Hulshoff on December 23, 2016, 04:40:36 PM
Changes were made, so I'm very interested in the error messages. I do not have a Windows compile environment.
Title: Re: New features
Post by: Agent47 on December 23, 2016, 04:59:39 PM
I'll have to confirm later but I believe the error was that gstreamer_gstappsink_INCLUDE_DIR was set to notfound or something along those lines.
Title: Re: New features
Post by: Pieter Hulshoff on December 23, 2016, 05:58:32 PM
That doesn't sound like something I touched recently. 😀

Which code did you compile exactly?
Title: Re: New features
Post by: Tom Acunzo on December 23, 2016, 11:34:11 PM
I'll have to confirm later but I believe the error was that gstreamer_gstappsink_INCLUDE_DIR was set to notfound or something along those lines.

Hi Agent try updating: retrofe\RetroFE\CMake\FindGStreamer.cmake
on line 46
SET(GSTREAMER_INCLUDE_DIRS ${GSTREAMER_gst_INCLUDE_DIR} ${GSTREAMER_gstconfig_INCLUDE_DIR} ${GSTREAMER_gstappsink_INCLUDE_DIR})

to
SET(GSTREAMER_INCLUDE_DIRS ${GSTREAMER_gst_INCLUDE_DIR} ${GSTREAMER_gstconfig_INCLUDE_DIR})

Let me know how it goes. If all is well. I'll just have to check how that change impacts the Mac build.
Title: Re: New features
Post by: Agent47 on December 24, 2016, 12:06:48 AM
I didn't see your response until I logged in just now to report, but I got it to generate the project properly by adding the correct path to the list of PATHS on line 11. That seems to have worked.

Update: VS project files were generated correctly and was able to build it in VS w/o any errors but the exe will not run. No errors when attempting to run RFE via cmd line. Also tried creating a new collection and that did nothing as well.
Title: Re: New features
Post by: Pieter Hulshoff on December 24, 2016, 08:39:58 AM
Any useful information in the log.txt perhaps?
Title: Re: New features
Post by: FrankyRizzo on December 28, 2016, 04:25:29 PM
Im not sure if I missed any version updates.  Did you ever have a chance to fix the include lists?  So whatever order the games are in the include list is the order they appear when scrolling through games in retrofe?  It wasn't working in the last version I was using and with the website update and moving of the forums I figured you had enough on your plate hahaha. 
Title: Re: New features
Post by: Pieter Hulshoff on December 28, 2016, 04:33:13 PM
It's fixed in bit bucket, but there's no official release yet. I plan to do a few more fixes, and I am waiting for the Windows compile to make sure everything works under all Operating Systems.
Title: Re: New features
Post by: FrankyRizzo on December 28, 2016, 04:44:44 PM
Awesome thanks for the update. 
Title: Re: New features
Post by: Pieter Hulshoff on December 31, 2016, 09:03:44 PM
Just got confirmation that the Windows build doesn't run. We're trying to sort it out.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Tom Acunzo on January 01, 2017, 07:29:35 AM
If Windows does not compile.

In: retrofe\RetroFE\CMake\FindGStreamer.cmake

Remove blocks for: (Only affects Mac)
GSTREAMER_gstappsink_INCLUDE_DIR

Compare that file to my fork if need be. Note I'm still testing other build files like CMakeLists.txt on Mavericks. MacOS Sierra builds fine without GSTREAMER_gstappsink_INCLUDE_DIR.

Happy New Years btw  ;D
Title: Re: New features
Post by: Pieter Hulshoff on January 01, 2017, 10:01:29 AM
We'll figure this out before 0.7.20 is ready. 2 people managed to compile it under Windows, but it crashes without info. We may need some trial and error or running it in a debugger here. I may need to install my own Windows compile environment sometime...

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: KMetalMind on January 01, 2017, 11:56:35 AM
I´ll take a look if I find some time too :) Could it be a specific VS problem?
Title: Re: New features
Post by: Pieter Hulshoff on January 01, 2017, 12:32:17 PM
I fear it's in one of the latest changes. My suspicion points towards the hierarchical rom directory support I added. I'm using some functions there of which I'm not 100% sure they work cross platform.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: KMetalMind on January 01, 2017, 10:11:12 PM
It seems it has something to do with the Mac build too  :o I´ve tested it and retroFE works on Windows up until last 2016/12/21 commit. If I try the first 2016/12/22 change (initial Mac build), I get the cmake error you have been already discussing. Fixing only the cmake files using the changes from the last RetroPrime fix, but not changing anything else, gets the "retroFE stopped working" error on Windows.

I will do more tests on next days if you need them  ;)
Title: Re: New features
Post by: Pieter Hulshoff on January 01, 2017, 10:48:10 PM
Please do. If it's not in a change I made I'm working rather blindly until I have my own debug environment under Windows. I'm working on that.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Tom Acunzo on January 02, 2017, 03:27:53 PM
Does retrofe.exe quit immediately at the command prompt for Windows or if you click it?

I appreciate that more of you are testing things out for windows. Sorry guys with the holidays I haven't had time to look further into this but if RetroFE is exiting quietly upon start, it sounds much like what happened to me when I 1st tried to figure out RetroFE for Mac on the original code base.

As a quick sanity check try setting or even unsetting RETROFE_PATH environment variable to where your RetroFE Base folder is before starting retrofe up. If it works then a minor tweak is probably needed in the configuration initialization checks.

The configuration assigns an absolute path by 1st checking: if ENV is set, or a hidden Text File is read, or get path relative to Executable.

Long story short see original: Source/Database/Configuration.cpp (https://bitbucket.org/phulshof/retrofe/src/be2fa76e7e24e1d851b1cfc9b05d2fc8ddf2eeea/RetroFE/Source/Database/Configuration.cpp?fileviewer=file-view-default)

RetroFE quietly exits on Configuration path initialize failures if it can't find the environment var RETROFE_PATH or if can't access the base folder relative to executable. Mac doesn't have /proc/[pid#]/exe for proc pid path. So it would fail to start for me.

So I added changes (https://bitbucket.org/phulshof/retrofe/diff/RetroFE/Source/Database/Configuration.cpp?diff1=be2fa76e7e24e1d851b1cfc9b05d2fc8ddf2eeea&diff2=49b7ec089980&at=default) to fix how mac get's the path relative to the executable but it also supports the legacy RETROFE_PATH check. Do people really depend on this? The trouble is if you mouse click RetroFE as an app/GUI and not run from the command line your version of OS may need to load RETROFE_PATH by other means than shell. As a workaround I included a hidden file option in users HOME/.retrofe, untested in Windows. The .retrofe file is a text file with only the "base folder path" stored, no var name, no spaces, as noted in the Readme.md / Overview.

That's assuming something is up with the Configuration for Windows. Maybe we should drop these optional checks. I just don't know the history behind RETROFE_PATH.


Title: Re: New features
Post by: KMetalMind on January 03, 2017, 05:18:12 PM
I haven´t had enough time yet to do more detailed tests, but you are on the right track, Tom: If I start retroFE from the commandline, it just quits silently (it doesn´t even start the log). I have tested a quick change on configuration.cpp, on intialize, based on your first changes. After commenting the new lines on that specific part of the code, it correctly executes  ;D

Code: [Select]
void Configuration::initialize()
{
    const char *environment = std::getenv("RETROFE_PATH");
    std::string environmentStr;
//    std::string home_load = std::getenv("HOME") + std::string("/.retrofe");
//    std::ifstream retrofe_path(home_load.c_str());
    if (environment != NULL)
    {
        environmentStr = environment;
        absolutePath = environment;
    }
//    else if (retrofe_path.is_open())
//    {
//    std::getline( retrofe_path, absolutePath );
//    retrofe_path.close();
//    }
    else

So thanks for the explanation!  ;)
Title: Re: New features
Post by: Tom Acunzo on January 03, 2017, 06:22:04 PM
I'm glad it works. But that code block is an older commit than this (https://bitbucket.org/phulshof/retrofe/src/f30ed5576f69b4f1f448f51adf0a80c357ae5ad4/RetroFE/Source/Database/Configuration.cpp?at=default&fileviewer=file-view-default):

Code: [Select]
void Configuration::initialize()
{
    const char *environment = std::getenv("RETROFE_PATH");
    std::string home_load = std::getenv("HOME") + std::string("/.retrofe");
    std::ifstream retrofe_path(home_load.c_str());
    // Check Environment for path
    if (environment != NULL)
    {
        absolutePath = environment;
    }
    // Or check for home based flat file works on linux/mac
    else if (retrofe_path && std::getline( retrofe_path, absolutePath ))
    {
    retrofe_path.close();
    }
    // Or check executable for path

This should pass if no .retrofe file was made at least. Can you check? Thanks for the help.
Title: Re: New features
Post by: KMetalMind on January 04, 2017, 06:18:05 PM
Thanks to all of you who make the hard work! With my knowledge I can just do some basic tests ;) It still doesn´t work, but I think we are really close. I´ve isolated the line which makes retroFE crash on Windows, and it´s just this one:

Code: [Select]
std::string home_load = std::getenv("HOME") + std::string("/.retrofe");
Any ideas?
Title: Re: New features
Post by: Agent47 on January 04, 2017, 10:30:33 PM
The "HOME" environment variable will return a null value on Windows. Concatenating the "HOMEDRIVE" and "HOMEPATH" environment variables will return the home dir.
Title: Re: New features
Post by: Pieter Hulshoff on January 04, 2017, 11:46:14 PM
I managed to do a compile and run under Windows tonight. I'll update the bit bucket files soon. I haven't been able to include /MT in the scripts yet.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Tom Acunzo on January 05, 2017, 12:37:52 AM
Great find guys! Thanks
Title: Re: New features
Post by: Pieter Hulshoff on January 06, 2017, 12:43:51 PM
Ok, bit bucket is updated, and I've confirmed that with all the updates (including the instructions) I can now directly compile and run the setup on Windows 7 and Linux. Tom, can you have a look if I didn't destroy anything for MacOS?
If everything works we can get back to adding features and fixing bugs. :)
Title: Re: New features
Post by: Pieter Hulshoff on January 06, 2017, 01:56:18 PM
It looks like the crash on exit when a controller is connected is caused by the call to SDL_JoystickClose. It's completely unclear to me why this would be, because the pointer itself is valid, and the joystick is working just fine. I've disabled this part of the code, since it's only called when exiting RetroFE. This does not appear to give any new problems, but let me know if you encounter any. :) The new code is in bit bucket, and will be included in the next release.
Title: Re: New features
Post by: Tom Acunzo on January 06, 2017, 08:40:46 PM
I just gave it a whirl on Mac...

I loaded the Sega game. After I quit with esc. The game fires right back up without me selecting it. I quit again. The game starts back up in a loop. It's as though all the key presses from hitting spacebar the 1st time are still firing.

Nothing in the logs.

Title: Re: New features
Post by: Tom Acunzo on January 06, 2017, 08:50:16 PM
BTW No errors on wired Dual Shock 4 retrofe exit.

Haven't tested bluetooth wireless or Dual Shock 3 yet but I feel it's good.
Title: Re: New features
Post by: Pieter Hulshoff on January 06, 2017, 09:30:04 PM
I just gave it a whirl on Mac...

I loaded the Sega game. After I quit with esc. The game fires right back up without me selecting it. I quit again. The game starts back up in a loop. It's as though all the key presses from hitting spacebar the 1st time are still firing.

Nothing in the logs.
No such issues for me, but on top of clearing the queue I will add a clear of the key information. That should solve that issue.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Floyd on January 06, 2017, 09:36:17 PM
Where can I download the latest compiled snapshots?
Title: Re: New features
Post by: Pieter Hulshoff on January 06, 2017, 10:24:31 PM
I can upload a snapshot this weekend if you'd like, but please realise that this is WIP, and not yet fully tested.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Floyd on January 06, 2017, 11:03:01 PM
I can upload a snapshot this weekend if you'd like, but please realise that this is WIP, and not yet fully tested.

Sent from my SM-G920F using Tapatalk

I thought you're throwing snapshots on regular basis. My bad I was wrong. No worries mate, you don't need to go through the hassle of compiling and uploading.
Title: Re: New features
Post by: Pieter Hulshoff on January 06, 2017, 11:08:45 PM
KMetalMind used to do that. Until yesterday I couldn't even compile a Windows executable. 😀

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Pieter Hulshoff on January 07, 2017, 08:44:36 AM
I just gave it a whirl on Mac...

I loaded the Sega game. After I quit with esc. The game fires right back up without me selecting it. I quit again. The game starts back up in a loop. It's as though all the key presses from hitting spacebar the 1st time are still firing.

Nothing in the logs.

Apparently the currentKeyState_ was not reset when resetting the key states. I guess Linux and Windows always have some kind of event happening in the queue, even if it's not a key press, which automatically updated the currentKeyState_. Let me know if this change fixes the issue for you?
Title: Re: New features
Post by: Tom Acunzo on January 07, 2017, 04:29:46 PM
I get Segmentation fault: 11...

If I advance the Load screen with spacebar or don't let it play to the end or even if I hit escape to quit before the load screen finishes all result in a crash.

added note:
$ retrofe --version
RetroFE version 0.7.20b1
Title: Re: New features
Post by: Pieter Hulshoff on January 07, 2017, 04:31:54 PM
I get Segmentation fault: 11...

If I advance the Load screen with spacebar or don't let it play to the end or even if I hit escape to quit before the load screen finishes all result in a crash.

I presume this is using MacOS?
I have no such issues under Linux or Windows. Is there any way for you to run it in the debugger to see where the issues are?

Thanks for mentioning the version; it shows me that you _are_ using the latest code.
Title: Re: New features
Post by: Tom Acunzo on January 07, 2017, 04:50:01 PM
I've only tested mac via quick brew install. Can't put much more time into it today. Something about adding playlists inside CollectionInfoBuilder

Code: [Select]
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_pthread.dylib        0x00007fffd61e04fc pthread_mutex_lock + 0
1   libsystem_c.dylib              0x00007fffd602dadc readdir$INODE64 + 22
2   retrofe                        0x0000000104e14e5f CollectionInfoBuilder::addPlaylists(CollectionInfo*) + 277
3   retrofe                        0x0000000104e4fc54 RetroFE::getCollection(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 1078
4   retrofe                        0x0000000104e4e068 RetroFE::run() + 2622
5   retrofe                        0x0000000104e4c3ec main + 5788
6   libdyld.dylib                  0x00007fffd5fcb255 start + 1
Title: Re: New features
Post by: Pieter Hulshoff on January 07, 2017, 04:56:58 PM
Damn, this is my latest fix, and (un?)fortunately I know exactly what's wrong, how to fix it, and that others will get the same issue. I only tested it using a collection that actually has playlists.
Title: Re: New features
Post by: Tom Acunzo on January 07, 2017, 05:03:30 PM
and don't forget there is now a --os=mac option for running the python step. We should better track adding new features as they affect multiple platforms.
Title: Re: New features
Post by: Pieter Hulshoff on January 07, 2017, 05:19:56 PM
Try again?
I've included a new executable. Hopefully this one will work better for everyone. :)

Please, back up your retrofe.exe before using this one. It's WIP and not fully tested yet.

This version contains playlist support and hierarchical rom directory support. Check the bit bucket commits for details.
Title: Re: New features
Post by: Pieter Hulshoff on January 07, 2017, 06:12:59 PM
and don't forget there is now a --os=mac option for running the python step. We should better track adding new features as they affect multiple platforms.
In this case I just didn't test it fully enough; it's not OS related. I added playlists, and only tested it with collections that actually had playlists, including my Main collection.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: ryuuji on January 07, 2017, 06:37:45 PM
What does that new feature actually do (the playlist) ?
Title: Re: New features
Post by: Pieter Hulshoff on January 07, 2017, 06:51:18 PM
It allows you to define and walk through sub lists of a collection, e.g. all Konami or all Driving games. It's an extension on the favorites playlist feature.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: ryuuji on January 07, 2017, 06:55:49 PM
Ok. So I can make custom lists (like genres) and when I press the next playlist button will cycle thru the genre lists I ve made ?
This can be done manual only ? the add to playlist button will add games only to fav list , right ?
Title: Re: New features
Post by: Pieter Hulshoff on January 07, 2017, 06:59:45 PM
Correct, for now. 😀 Just create .txt files in the playlists directory with the games you want. I've added a prevPlaylist and a favPlaylist key definition to the existing nextPlaylist button.

You could consider adding corresponding logos to the collections/_common/medium_artwork/playlist directory so you know what playlist you're in.
Title: Re: New features
Post by: ryuuji on January 07, 2017, 07:01:29 PM
Nice :) . Will test it soon but it is a nice feature indeed. Probably have to update the layouts also.
Title: Re: New features
Post by: Pieter Hulshoff on January 07, 2017, 07:08:47 PM
Not much; I just moved the collection's playlist image 50 pixels to the right to deal with large images, and added the genre wheels and some manufacturer wheels to the common artwork.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Tom Acunzo on January 07, 2017, 07:22:25 PM
and don't forget there is now a --os=mac option for running the python step. We should better track adding new features as they affect multiple platforms.
In this case I just didn't test it fully enough; it's not OS related. I added playlists, and only tested it with collections that actually had playlists, including my Main collection.

Sent from my SM-G920F using Tapatalk

In case new file types are added to collections or whatever in the future and the post script copies those to Artifacts. Yes otherwise error checking is nice.
Title: Re: New features
Post by: Pieter Hulshoff on January 07, 2017, 07:46:12 PM
High on my todo list is support for truRIP superdat files to support the upcoming truRIP releases.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Pieter Hulshoff on January 07, 2017, 08:01:52 PM
Btw, Tom, can you explain why MacOS cannot handle the png files that used to be included? I'm trying to see if I can batch convert them for future use for MacOS as well, since bit bucket contains only a small sub set of what I have.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Tom Acunzo on January 07, 2017, 08:39:24 PM
It's not so much as a mac issue per say (incorrect sRGB profile). A newer version of libpng is out. They have included some tools to patch pngs. I think they may suppress the error warnings in the library as other projects complained about how verbose they were and some apps even crashed. As for RetroFE it just spewed messages to the console every time an image was loaded.

The files that I did patch in bitbucket I used a tool pngcrush (https://bitbucket.org/RetroPrime/retrofe#markdown-header-fix-libpng-iccp-warnings-about-incorrect-srgb-profile).

But it's funny you brought it. Libpng literally just patched a huge 21 year old vulernabilty in 1.6.27! Totally worth a read on there main page (http://www.libpng.org/pub/png/libpng.html) as it may seriously affect people in different ways.

Toms-MacBook-Pro:sfml Tom$ brew info libpng
libpng: stable 1.6.26 (bottled), HEAD
Library for manipulating PNG images
http://www.libpng.org/pub/png/libpng.html
/usr/local/Cellar/libpng/1.6.26 (26 files, 1.2M) *
  Poured from bottle on 2016-12-16 at 22:06:15
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/libpng.rb
==> Options
--universal
   Build a universal binary
--HEAD
   Install HEAD version
Toms-MacBook-Pro:sfml Tom$ brew list libpng
/usr/local/Cellar/libpng/1.6.26/bin/libpng-config
/usr/local/Cellar/libpng/1.6.26/bin/libpng16-config
/usr/local/Cellar/libpng/1.6.26/bin/png-fix-itxt
/usr/local/Cellar/libpng/1.6.26/bin/pngfix
/usr/local/Cellar/libpng/1.6.26/include/libpng16/ (3 files)
/usr/local/Cellar/libpng/1.6.26/include/ (3 files)
/usr/local/Cellar/libpng/1.6.26/lib/libpng16.16.dylib
/usr/local/Cellar/libpng/1.6.26/lib/pkgconfig/ (2 files)
/usr/local/Cellar/libpng/1.6.26/lib/ (4 other files)
/usr/local/Cellar/libpng/1.6.26/share/man/ (3 files)


Update: I went a little overboard, the exploit is nothing major to us.
Title: Re: New features
Post by: Pieter Hulshoff on January 08, 2017, 09:59:22 AM
I thought I'd give an overview of the new features since 0.7.19 that were included in 0.7.20b1 (http://retrofe.nl/SMF/index.php?topic=7.msg291#msg291):

- Fixed menuSort = no behavior for include.txt files.
- Fixed Windows expansion of %RETROFE_EXEC_PATH%.
- Fixed local language support.
- Fixed container scaling.
- Fixed input queue when returning from a game.
- Fixed crash on exit when a controller is connected.
- Rewritten menu scrolling and input handler.
- Added support for hierarchy in the roms directory via list.romHierarchy parameter in collection's settings.conf file.
- Added playlist support via the keys favPlaylist, nextPlaylist, and prevPlaylist. The playlists should be placed as <playlist name>.txt in the collections/<collection name>/playlists directory.
- Added MacOS support (Tom).
Title: Re: New features
Post by: marxkemp on January 08, 2017, 11:47:21 AM
Great!
Title: Re: New features
Post by: ryuuji on January 08, 2017, 01:17:29 PM
Very nice
Title: Re: New features
Post by: JonahUK on January 08, 2017, 01:41:49 PM
One of the many, many reasons why I prefer RetroFE over others :)
Updates and issues fixed almost immediately :)

Keep up the excellent work fellas!
Title: Re: New features
Post by: Tom Acunzo on January 08, 2017, 04:33:17 PM
I thought I'd give an overview of the new features since 0.7.19 that were included in 0.7.20b1 (http://retrofe.nl/SMF/index.php?topic=7.msg291#msg291):

- Fixed menuSort = no behavior for include.txt files.
- Fixed Windows expansion of %RETROFE_EXEC_PATH%.
- Fixed local language support.
- Fixed container scaling.
- Fixed input queue when returning from a game.
- Fixed crash on exit when a controller is connected.
- Rewritten menu scrolling and input handler.
- Added support for hierarchy in the roms directory via list.romHierarchy parameter in collection's settings.conf file.
- Added playlist support via the keys favPlaylist, nextPlaylist, and prevPlaylist. The playlists should be placed as <playlist name>.txt in the collections/<collection name>/playlists directory.
- Added MacOS support (Tom).
And:
- Fixed incorrect sRGB profile errors for PNGs
- Added support for /home/user/.retrofe RETROFE_PATH setting for linux / mac.
- Added brew install option for mac
- Updated Overview instructions in readme

Note: The last two will be tweaked again via pull request.

Latest changes still break Mac (See CollectionInfoBuilder::ImportRomDirectory), haven't tested other builds.

Code: [Select]
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_pthread.dylib        0x00007fff94f184fc pthread_mutex_lock + 0
1   libsystem_c.dylib              0x00007fff94d5e9f8 closedir + 25
2   retrofe                        0x00000001040bc777 CollectionInfoBuilder::ImportRomDirectory(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, CollectionInfo*, std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Item*, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, Item*> > >, std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Item*, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, Item*> > >, bool) + 805
3   retrofe                        0x00000001040bb2bd CollectionInfoBuilder::ImportDirectory(CollectionInfo*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 2255
4   retrofe                        0x00000001040ba5b8 CollectionInfoBuilder::buildCollection(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 1674
5   retrofe                        0x00000001040b9ee4 CollectionInfoBuilder::buildCollection(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 72
6   retrofe                        0x00000001040f7829 RetroFE::getCollection(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 75
7   retrofe                        0x00000001040f6028 RetroFE::run() + 2622
8   retrofe                        0x00000001040f43ac main + 5788
9   libdyld.dylib                  0x00007fff94d03255 start + 1
Title: Re: New features
Post by: Tom Acunzo on January 08, 2017, 05:39:55 PM
I think the issue is that CollectionInfoBuilder is expecting a roms folder inside collections/Main which isn't there for any OS.

This is why you should run the python post install step and test new retrofe changes from inside Artifacts. There will be fresh installations of retrofe that don't have Mame even set up yet.

It's also good to double check once you copy files or folders to Package/Environment/<OS>
or if you add roms to Package/Environment/Common/collections/Main/ in bitbucket.

Hence my whole don't forget comment from before as a sanity check for new features.

UPDATE - The spacebar key event loop is tested good. Retrofe loads after creating the roms folder.
Title: Re: New features
Post by: Pieter Hulshoff on January 08, 2017, 05:58:00 PM
I will check, and update accordingly.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Pieter Hulshoff on January 08, 2017, 08:02:51 PM
I think the issue is that CollectionInfoBuilder is expecting a roms folder inside collections/Main which isn't there for any OS.

This is why you should run the python post install step and test new retrofe changes from inside Artifacts. There will be fresh installations of retrofe that don't have Mame even set up yet.

It's also good to double check once you copy files or folders to Package/Environment/<OS>
or if you add roms to Package/Environment/Common/collections/Main/ in bitbucket.

Hence my whole don't forget comment from before as a sanity check for new features.

UPDATE - The spacebar key event loop is tested good. Retrofe loads after creating the roms folder.

Odd, the roms directory IS created under Linux, but even without it I do not get a crash.

I've updated the code though. I noticed closedir may be called on a NULL pointer, which may not work on all operating systems. Let me know if that helps.
Title: Re: New features
Post by: Tom Acunzo on January 09, 2017, 12:49:19 AM
The fix works well. Thanks Pieter.
Title: Re: New features
Post by: Pieter Hulshoff on January 09, 2017, 01:25:52 PM
The fix works well. Thanks Pieter.

That's good to hear. :) That means I can focus on implementing support for truRIP superdat files. :) I hope to have that up and running by the end of this week. I also want to see if I can make RetroFE update meta.db automatically if any of the meta files change. Currently people still have to manually delete the meta.db to have it regenerate.
Title: Re: New features
Post by: KMetalMind on January 09, 2017, 04:15:37 PM
Now it works perfectly on Windows. Thanks guys!!!  ;)

With the last changes, the menus are a lot smoother, but it loads a lot faster on Windows too. For some reason, retroFE usually needed around 4-5 minutes after loading all to show up, but that doesn´t happen now.

Just a quick question? Would it be possible to keep animating images which are not reloadable just like menus? That would make everything even more smoother.
Title: Re: New features
Post by: ryuuji on January 09, 2017, 05:27:50 PM
That means I can focus on implementing support for truRIP superdat files.

and in English that would be .... ? :P
Title: Re: New features
Post by: Pieter Hulshoff on January 09, 2017, 08:45:21 PM
That means I can focus on implementing support for truRIP superdat files.

and in English that would be .... ?
http://database.trurip.org/

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Pieter Hulshoff on January 09, 2017, 10:42:27 PM


Just a quick question? Would it be possible to keep animating images which are not reloadable just like menus? That would make everything even more smoother.

Can you give me an example of what you're looking for?

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: bundangdon on January 10, 2017, 08:41:14 AM
Try again?
I've included a new executable. Hopefully this one will work better for everyone. :)

Please, back up your retrofe.exe before using this one. It's WIP and not fully tested yet.

This version contains playlist support and hierarchical rom directory support. Check the bit bucket commits for details.

Hate to bring this issue up again, but I've noticed that with this latest version, the wheel lag problem is back again :o I even tried a fresh install and noticed that there is a very noticeable lag in the wheel, but when I revert back to the previous version, there's no lag. Just wanted to bring this to your attention  :D
Title: Re: New features
Post by: Pieter Hulshoff on January 10, 2017, 10:06:20 AM
Can you define what you notice as lag? I've implemented it such now that the menu scroll animation does not get chopped by art loading, but realise that if you are too slow in pressing next that the loading will slow things down. It should properly react to multiple quick presses too now: 5x next = 5 game scroll.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: bundangdon on January 10, 2017, 01:34:58 PM
Can you define what you notice as lag? I've implemented it such now that the menu scroll animation does not get chopped by art loading, but realise that if you are too slow in pressing next that the loading will slow things down. It should properly react to multiple quick presses too now: 5x next = 5 game scroll.

Sent from my SM-G920F using Tapatalk

I had mentioned this on the original website forums a while back. At that time, the issue was related to the Aeon Nox theme, but this time it seems to be happening with other themes I've tried too.
http://www.retrofe.com/forum/index.php?topic=393.msg2549#msg2549 (http://www.retrofe.com/forum/index.php?topic=393.msg2549#msg2549)
and here http://www.retrofe.com/forum/index.php?topic=376.msg2540#msg2540 (http://www.retrofe.com/forum/index.php?topic=376.msg2540#msg2540)
In other words, you click to scroll left or right and have to wait 1-2 seconds before the wheel progresses. However, it's not a biggie since I can stick with the official version for now until things get sorted out in the future :) Just wanted to bring it to your attention
Title: Re: New features
Post by: Pieter Hulshoff on January 10, 2017, 02:02:32 PM
Still, that is odd, since I see no such issues myself. What do you use to control the menu, and does this happen on a single click or multiple clicks or ..?

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: bundangdon on January 10, 2017, 02:04:27 PM
Using the keyboard arrow/direction keys for now, scrolling from left to right, up and down, just standard 'one click' stuff
Title: Re: New features
Post by: Pieter Hulshoff on January 10, 2017, 02:10:52 PM
Ok, so using your keyboard you click once, and then have to wait for 1-2 seconds for something to happen or does it scroll immediately, and it takes 1-2 seconds for the entire animation (menu scroll, fade-out, art loading, fade-in) to complete or it takes 1-2 seconds before you can click again or ...? :) Just trying to understand what the exact issue is. I can fix almost anything as long as I can understand and reproduce it. :)
Title: Re: New features
Post by: Multiplexer on January 10, 2017, 07:38:40 PM
Can you define what you notice as lag? I've implemented it such now that the menu scroll animation does not get chopped by art loading, but realise that if you are too slow in pressing next that the loading will slow things down. It should properly react to multiple quick presses too now: 5x next = 5 game scroll.

Sent from my SM-G920F using Tapatalk



I have found now that it too sensitive. It is great for scrolling through games but if you accidentally press the select button twice on the system menu RetroFE will open that system and automatically play the first game on the list. Also if you press the back button twice or hold for too long it will go back the sytem menu then exit RetroFE. This seems more pronounced for some reason when using the DS4 controller where anything more than a light tap on the button will result in a double tap if you get what I mean?
Title: Re: New features
Post by: ryuuji on January 10, 2017, 07:47:05 PM
It sounds just normal to me ... retrofe registers that you pressed 2 times and it will result into playing a game/exiting retrofe. For example: if you are in systems menu and pres SELECT 2 times => 1st go in the game list => 2nd play the first game that will show up.
And if you hold it pressed will have the same reaction because when you will reach the next menu retrofe will automatically read the input.
Title: Re: New features
Post by: Pieter Hulshoff on January 10, 2017, 08:42:08 PM
True, though if people prefer that I clear the input buffer when entering/exiting a collection, I can certainly change that.

Also: you can disable exiting RetroFE with the back key.
Title: Re: New features
Post by: Multiplexer on January 10, 2017, 09:22:10 PM
It is doing exactly what it is supposed to. It is only really a problem when using the DS4 controller, it nearly always registers double presses unless you give the buttons the lightest of taps.
It isn't really an issue when exiting as it can be disabled but entering sub-menus cannot. I would prefer the input buffer be cleared but that may just be me. Other than that the latest exe seems to work spot on. Fast and smooth!
Title: Re: New features
Post by: Pieter Hulshoff on January 10, 2017, 09:54:19 PM
I feel a global setting coming... 😉

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Multiplexer on January 10, 2017, 10:15:23 PM
That would be great!  :)
Title: Re: New features
Post by: Pieter Hulshoff on January 11, 2017, 10:09:16 AM
truRIP support and the collectionInputClear parameter have been added to bit bucket. Version has been updated to 0.7.20b2; I'll try to make a new Windows executable this evening.
I also have auto generation of meta.db working under Linux, but it may need a bit more testing to make sure it works in all situations.
Title: Re: New features
Post by: bundangdon on January 11, 2017, 10:34:21 AM
Ok, so using your keyboard you click once, and then have to wait for 1-2 seconds for something to happen or does it scroll immediately, and it takes 1-2 seconds for the entire animation (menu scroll, fade-out, art loading, fade-in) to complete or it takes 1-2 seconds before you can click again or ...? :) Just trying to understand what the exact issue is. I can fix almost anything as long as I can understand and reproduce it. :)

Yep, the first one you mentioned (keyboard you click once, and then have to wait for 1-2 seconds for something to happen). For example, I want to scroll to the left (or right) to choose the next system, but even though I clicked, it doesn't move to the next system until 1-2 seconds later, hence the "lag"
Title: Re: New features
Post by: Pieter Hulshoff on January 11, 2017, 11:19:07 AM
Ok, so using your keyboard you click once, and then have to wait for 1-2 seconds for something to happen or does it scroll immediately, and it takes 1-2 seconds for the entire animation (menu scroll, fade-out, art loading, fade-in) to complete or it takes 1-2 seconds before you can click again or ...? :) Just trying to understand what the exact issue is. I can fix almost anything as long as I can understand and reproduce it. :)

Yep, the first one you mentioned (keyboard you click once, and then have to wait for 1-2 seconds for something to happen). For example, I want to scroll to the left (or right) to choose the next system, but even though I clicked, it doesn't move to the next system until 1-2 seconds later, hence the "lag"

Ok, that IS very odd. I would expect the menu to start scrolling immediately. If that's not the case for you, then I don't have a clue what might be causing that to be honest. This happens with the default theme (Aeon Nox) distributed with RetroFE or did you change any values?
Title: Re: New features
Post by: ryuuji on January 11, 2017, 03:20:16 PM
maybe is the layout ? :o ergo proxy (in the main menu) does not work like the usual ones :P
Title: Re: New features
Post by: Pieter Hulshoff on January 11, 2017, 08:00:35 PM
Here's a Windows exe for 0.7.20b2. Changes since 0.7.19 are:
- Fixed menuSort = no behavior for include.txt files.
- Fixed Windows expansion of %RETROFE_EXEC_PATH%.
- Fixed local language support.
- Fixed container scaling.
- Fixed input queue when returning from a game.
- Fixed crash on exit when a controller is connected.
- Fixed incorrect sRGB profile errors for PNGs (Tom).
- Rewritten menu scrolling and input handler.
- Added support for hierarchy in the roms directory via list.romHierarchy parameter in collection's settings.conf file.
- Added playlist support via the keys favPlaylist, nextPlaylist, and prevPlaylist. The playlists should be placed as <playlist name>.txt in the collections/<collection name>/playlists directory.
- Added MacOS support (Tom).
- Added support for /home/user/.retrofe RETROFE_PATH setting for linux / mac (Tom).
- Added brew install option for mac (Tom).
- Added trurip Super DAT support. .dat files are expected in meta/trurip.
- Added collectionInputClear parameter to the global settings.conf. When set to true, the input queue will be cleared when entering/exiting a collection.
- Added automatic update of meta.db when any of the meta xml/dat files are updated/added. No more manual deleting of meta.db required.
- Updated Overview instructions in readme (Tom).

As always: keep in mind that this is WIP, so not fully tested, and keep a backup of your working retrofe.exe handy in case this one doesn't work for you!
Title: Re: New features
Post by: Pieter Hulshoff on January 11, 2017, 08:18:23 PM
Just a quick question? Would it be possible to keep animating images which are not reloadable just like menus? That would make everything even more smoother.

Can you elaborate on this idea? What did you have in mind?
Title: Re: New features
Post by: Pieter Hulshoff on January 11, 2017, 08:36:23 PM
Playing around with a trurip work in progress: SNK Neo-Geo CD.
Title: Re: New features
Post by: Multiplexer on January 11, 2017, 09:09:19 PM
The collectionInputClear works perfectly, thanks!  :)
Title: Re: New features
Post by: bundangdon on January 12, 2017, 03:13:57 AM
Ok, so using your keyboard you click once, and then have to wait for 1-2 seconds for something to happen or does it scroll immediately, and it takes 1-2 seconds for the entire animation (menu scroll, fade-out, art loading, fade-in) to complete or it takes 1-2 seconds before you can click again or ...? :) Just trying to understand what the exact issue is. I can fix almost anything as long as I can understand and reproduce it. :)

Yep, the first one you mentioned (keyboard you click once, and then have to wait for 1-2 seconds for something to happen). For example, I want to scroll to the left (or right) to choose the next system, but even though I clicked, it doesn't move to the next system until 1-2 seconds later, hence the "lag"

Ok, that IS very odd. I would expect the menu to start scrolling immediately. If that's not the case for you, then I don't have a clue what might be causing that to be honest. This happens with the default theme (Aeon Nox) distributed with RetroFE or did you change any values?

It's with the Aeon Nox theme, Ergo Proxy, and a few other themes, as I've tried them out and come up with the same results. No values have been changed as far as I know. I guess I'll try a fresh install with the latest version you posted and see what happens  :P

Update: With a 'fresh' install including the latest retrofe.exe file, I've noticed that the lag seems to be caused by the program waiting for the media files for each system/game to load up on the screen. So, when there's any artwork including system, fanart, video, etc. it seems to be waiting for those to load before going to the next system/game. The loading of the artwork seems to be slowing down the pace of the wheel by a second or two
Title: Re: New features
Post by: Pieter Hulshoff on January 12, 2017, 05:05:27 AM
The loading of art doesn't start until AFTER the menu has stopped moving. That's why I find it so strange that you say your menu doesn't start moving either.

There is however a significant difference between the 0.7.19 and 0.7.20bx animations:

0.7.19:
- press next
- menu starts scrolling
- release next
- onHighlightExit animation
- when scrolling and onHighlightExit animation are done: load art
- onHighlightEnter animation

This caused various animation glitches or lag or missing key presses when keys were pressed before the animations were completed.

0.7.20bx:
- press next
- menu scrolls
- onHighlightExit animation
- load art
- onHighlightEnter animation

This allows for the menu to continue scrolling without animations starting if you press the key before the menu stops scrolling. It also means that if you press once the total animation takes longer than it did in 0.7.19, but that can be shortened in the theme, and there should be no more glitching.

You can also use the onMenuScroll animation in stead, and make it look more like HyperSpin, where art isn't visible during scrolling.
Title: Re: New features
Post by: bundangdon on January 12, 2017, 06:20:46 AM

You can also use the onMenuScroll animation in stead, and make it look more like HyperSpin, where art isn't visible during scrolling.

That sounds like a good idea. How can I use that?
Title: Re: New features
Post by: Pieter Hulshoff on January 12, 2017, 06:56:28 AM
Just replace all onHighlightExit animations with onMenuScroll. Should be an easy search/replace.
Title: Re: New features
Post by: Floyd on January 13, 2017, 10:08:03 AM
Is the new version, especially the part with wheel scrolling going to break themes?
Title: Re: New features
Post by: Pieter Hulshoff on January 13, 2017, 10:52:14 AM
No, it's not. It's just smoothing out some rough edges from 0.7.19. Feel free to give 0.7.20b2 a try, and see for yourself.

Sent from my SM-G920F using Tapatalk

Title: Re: New features
Post by: Pieter Hulshoff on January 13, 2017, 03:28:27 PM
Here's 0.7.20b3. I found a bug in 0.7.20b2 with attract mode. Basically attract mode didn't work anymore; it just restarted the video/scrolling text every so many seconds (depending on your settings).

As always: this is WIP, so mainly untested. Please backup your working retrofe.exe so you can go back to the old version if this one doesn't work for you.
Title: Re: New features
Post by: Floyd on January 13, 2017, 08:48:00 PM
Will give it a spin tonight and see how it works. Posting bugs if found any.
Title: Re: RetroFE development
Post by: firewater on January 20, 2017, 10:53:52 PM
I wanted to say that my #1 requested feature would be this option you mention in the OP to assign multiple controls for one action, so there's definitely still interest on that. Not trying to hurry you or anything of course, just thought I'd let you know :P
Title: Re: RetroFE development
Post by: Pieter Hulshoff on January 20, 2017, 11:15:22 PM
Just got word tonight that someone's already on it. I currently have 3 potential helpers on the coding front.

Sent from my SM-G920F using Tapatalk

Title: Re: RetroFE development
Post by: JonahUK on January 20, 2017, 11:42:34 PM
I currently have 3 potential helpers on the coding front.

Excellent!
Things can only get better!
Title: Re: RetroFE development
Post by: KMetalMind on January 21, 2017, 08:39:08 AM


Just a quick question? Would it be possible to keep animating images which are not reloadable just like menus? That would make everything even more smoother.

Can you give me an example of what you're looking for?

Reading twice I may have confused the improvement. Is the change that button presses keep getting triggered while art is loading, or does the menu art continue to be animated while art is loading? I thought it was the later one, so I was asking if that could happen too to the image tag too (currently while loading art all image animations freeze while loading next art, even the no reloadable ones).

Just got word tonight that someone's already on it. I currently have 3 potential helpers on the coding front.


I haven´t been able to spend much time on retroFE on last weeks, but all the last changes in bitBucket are totally amazing. Keep up the good work!!  ;D ;)
Title: Re: RetroFE development
Post by: Pieter Hulshoff on January 21, 2017, 11:13:24 AM
The loading of art now always waits until the animations are complete. The onHighlightExit animation doesn't trigger until all menu animations have stopped.

It's basically:
- menu actions
- onHighlightExit
- load art
- onHighlightEnter

Sent from my SM-G920F using Tapatalk

Title: Re: RetroFE development
Post by: KMetalMind on January 22, 2017, 10:46:16 AM
I found a bug yesterday: On latest build, on Windows, nothing launches properly. The problem is that retroFE is searching all the launchers from the collection folder, instead of using the root retroFE folder. I´ve tried returning to 0.7.20b1, but the bug was already there  ;)
Title: Re: RetroFE development
Post by: Pieter Hulshoff on January 22, 2017, 11:15:24 AM
Strange, I will investigate.

Do you have a log.txt for me?
Title: Re: RetroFE development
Post by: KMetalMind on January 22, 2017, 12:16:03 PM
Of course  ;) Here´s the log.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on January 22, 2017, 12:26:39 PM
Your NES settings.conf file is missing...

Sent from my SM-G920F using Tapatalk

Title: Re: RetroFE development
Post by: KMetalMind on January 22, 2017, 01:16:15 PM
Have you seen the correct log? Mine fails when executing a game, in this log, a Master System one:
Code: [Select]
[2017-01-22 13:15:15] [ERROR] [Launcher] Failed to run: Z:\Super DreamStation Plus\RetroFE 0.6.169\collections\launchers\Fusion\Fusion36\Fusion.exe
(My launchers are on the default folder, without changing the path on any settings.conf)
Title: Re: RetroFE development
Post by: Pieter Hulshoff on January 22, 2017, 01:33:14 PM
Sorry, seems my phone gave me the wrong log.txt file.
You're using BASE_ITEM_PATH in your launcher config file; as far as I know that expands to the collections path by default. In previous versions, that path wasn't expanded correctly.
Title: Re: RetroFE development
Post by: KMetalMind on January 22, 2017, 02:43:09 PM
Really thanks!!  ;D You nailed it!! Changing BASE_ITEM_PATH for RETROFE_PATH has fixed it.  ;D
Title: Re: RetroFE development
Post by: Pieter Hulshoff on January 24, 2017, 09:42:03 AM
If anyone's programming new features, please let me know so I can mark them on the first page. That way we can prevent two people spending time to implement the same feature. :)
Title: Re: RetroFE development
Post by: bodbod on January 26, 2017, 03:46:51 PM
Hi Guys,

where can we see the timeline and test some betas ?

Thanks for the great work !
Title: Re: RetroFE development
Post by: Pieter Hulshoff on January 26, 2017, 04:05:27 PM
You can always check in bit bucket to see what we're working on. 0.7.20b4 should be available soon, and I plan on making that 0.7.20 once it's properly tested.

Sent from my SM-G920F using Tapatalk

Title: Re: RetroFE development
Post by: KMetalMind on January 27, 2017, 08:06:19 PM
Loving latest features on bitBucket  ;D Multiple key bindings, launchers per Operative System and smoother videos!!

Thanks again to everybody involved!!  ;)
Title: Re: RetroFE development
Post by: marxkemp on January 27, 2017, 09:46:09 PM
Can't wait! :)
Title: Re: RetroFE development
Post by: Pieter Hulshoff on January 28, 2017, 11:13:11 AM
Here's a Windows build for 0.7.20b4.
-----
Changes:
- Support for multiple rompaths using the ; separator for list.path in the collection's settings.conf
- Removed requirement for the presence of the collection's settings.conf file.
- Recreated meta.db whenever any of the meta files or the executable changes.
- Support for launchers per game via the directory collections/collection name/launchers/game name.conf
- Support for multiple keys for the same action in controls.conf, comma separated (catelite)
- Improved video performance and playback, including aspect ratio (PinealServo)
- Improvement of input handlers (PinealServo)
- Support for launchers per OS via the optional launcher directories launchers.linux, launchers.windows, and launchers.apple
- Enable gdb debugging symbols in debug build for non-Windows (PinealServo)
- Fix crash when launcher files don't have extensions (PinealServo)
-----
As always: this is WIP, so please back up your working retrofe.exe before installing this one so you can go back if this one doesn't work for you. Let me know if you encounter any problems; I'd like to release 0.7.20 as full release before too long if there are no serious bugs.
Title: Re: RetroFE development
Post by: ryuuji on January 28, 2017, 01:24:13 PM
Cool. Looks like the video brightness is fixed now  ;D . Thanks.

(http://i.imgur.com/OZ8jv6w.jpg)
Title: Re: RetroFE development
Post by: PinealServo on January 28, 2017, 10:56:14 PM
Cool; the brightness change was probably an artifact of the conversion from a planar YUV 4:2:0 to a packed YUV 4:2:2 pixel format that was previously going on, or maybe an artifact of how SDL sets up the pixel shaders that convert the resulting textures of the two formats into RGB video frames. I wasn't sure it would fix that issue, but I'm glad it did!
Title: Re: RetroFE development
Post by: PinealServo on January 29, 2017, 05:24:58 AM
I've been playing around with a very cool feature of gcc, which is the set of "sanitizer" tools it has built-in now. If you're familiar with valgrind, it can catch many of the same kinds of errors but the program runs a *lot* faster than it does under valgrind and seems to do a better job of pinpointing where the relevant objects are referenced in the source.

Anyway, with -fsanitize=address and valgrind, I found a few little things that could potentially cause problems. These include some uninitialized variables being accessed, some memory being accessed after it was freed, and a *lot* of little memory leaks.

A bunch of the memory leaks are in the animation system and I haven't figured out where to free things yet, but I've fixed a bunch of the other problems.  I'll have a pull request coming for those misc clean-ups soon.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on January 29, 2017, 07:38:11 AM
Good work. :) I'll pull it in for 0.7.20b5 then.
Title: Re: RetroFE development
Post by: GoodWill Emu on January 29, 2017, 04:08:10 PM
I made a pre-Alpha of a RetroFE Setup Tool!

It has no actual Functionality, only opening windows and  quitting, but I would like to know what you think.

It's a python source file, just open it with a Python 3.6 Compiler.
Title: Re: RetroFE development
Post by: johnsaints on February 01, 2017, 08:27:51 PM
Just replace the .exe in "core" folder and it's ready ?
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 01, 2017, 08:45:18 PM
Just replace the .exe in "core" folder and it's ready ?

You mean the beta versions of RetroFE? Yes, that's sufficient.
Title: Re: RetroFE development
Post by: johnsaints on February 01, 2017, 09:10:02 PM
It did not work for me. I separated the two paths with ";", but the program only reads the first path. =/
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 01, 2017, 10:05:43 PM
Post your log.txt, please?
Title: Re: RetroFE development
Post by: johnsaints on February 01, 2017, 10:26:55 PM
Here. Thanks.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 01, 2017, 10:41:09 PM
Try removing the space after the ;
I don't think I considered removing whitespace from the path...
Title: Re: RetroFE development
Post by: Tom Acunzo on February 01, 2017, 11:05:16 PM
Hi Pieter MacOS ran fine on the initial tests including pngs I'll update brew on my tap to make the retrofe install live for Mac on the new branch. I also may need to update the readme notes as they differ with recent changes. I'll keep you posted.
Title: Re: RetroFE development
Post by: johnsaints on February 01, 2017, 11:54:58 PM
Try removing the space after the ;
I don't think I considered removing whitespace from the path...

Thanks Sir, the space was the problem. Now it's working. Good Job.  ;)
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 05, 2017, 11:40:02 AM
Here's RetroFE 0.7.21b1:
- Fixed support for "Shift Left" in controls.conf
- Fixed support for onMenuEnter="0" for 2nd level menu and similar theme features
Thanks PinealServo for your help. :)
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 05, 2017, 11:40:17 AM
I'm playing around a bit with the default menu animation for Aeon Nox (default theme). It feels a bit sluggish to me, so I've (locally) changed the starting speed to .25 seconds (down from .35 seconds). It does feel a bit more responsive that way. Feel free to play around with it on your own theme settings, and let me know what you think?
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 05, 2017, 11:46:36 AM
I'm also considering changing the release setup a bit. I'm currently using the bx postfix to indicate it's a beta release for a new upcoming release, but I think I will switch to increasing the middle number more often, so simply use 0.x.0 for the release, and then 0.x.y for the incremental changes. 0.x.beta-y will then be reserved for true beta releases in preparation for a full release. This would result in:
0.8.0 (full release)
0.8.y (y > 0, incremental changes on 0.8.0)
0.9.beta-z (beta release z for release 0.9.0)
0.9.0 (next full release)
Any thoughts?
Title: Re: RetroFE development
Post by: shatshoes on February 05, 2017, 05:27:47 PM
sounds good
Title: Re: RetroFE development
Post by: Tom Acunzo on February 05, 2017, 07:23:19 PM
It's a bit redundant, 0.x.y is all beta until 1.0 and beyond is out right?
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 05, 2017, 07:27:11 PM
I guess I could use RC (release candidate) in stead. 😀 The idea though is to only do bug fixes during that time.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 08, 2017, 02:11:30 PM
I'm playing around a bit with the default menu animation for Aeon Nox (default theme). It feels a bit sluggish to me, so I've (locally) changed the starting speed to .25 seconds (down from .35 seconds). It does feel a bit more responsive that way. Feel free to play around with it on your own theme settings, and let me know what you think?

Has anyone played around with this, and is able/willing to give me some feedback? This is always an issue between fast animation and smooth animation, and I'm trying to find an optimum.
Title: Re: RetroFE development
Post by: Tom Acunzo on February 08, 2017, 08:47:47 PM
All my themes are broken. :(
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 08, 2017, 10:46:13 PM
All my themes are broken. :(
Which themes are broken, and in which way?
Title: Re: RetroFE development
Post by: firewater on February 17, 2017, 03:58:42 AM
I'm interested on having a different background image load every time the selection changes. So for example:

[NES] background: image of Super Mario Bros. 3
>
[Mega Drive] background: image of Gunstar Heroes
>
[NES] background: image of Crystalis

Is this something that can already be done or is this what "Randomization of art alternative selection, animations, etc." refers to?
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 17, 2017, 06:38:48 AM
That's what the randomisation refers to. It's not yet available.

Sent from my SM-G920F using Tapatalk

Title: Re: RetroFE development
Post by: firewater on February 17, 2017, 07:58:28 AM
Cool, just wanted to be sure.

edit: I think this is covered by the planned UTF-8 support feature but I just wanted to report that "Pokémon Mini", "NEO・GEO CD" and "Odyssey˛" can't be the name of collections because if they are logo.png (perhaps neither are the games, I didn't go that far) isn't recognized and it defaults to a boring text name .
Title: Re: RetroFE development
Post by: FrankyRizzo on March 27, 2017, 03:11:19 AM
Cool, just wanted to be sure.

edit: I think this is covered by the planned UTF-8 support feature but I just wanted to report that "Pokémon Mini", "NEO・GEO CD" and "Odyssey˛" can't be the name of collections because if they are logo.png (perhaps neither are the games, I didn't go that far) isn't recognized and it defaults to a boring text name .

My guess is the special characters just aren't supported. 
Title: Re: RetroFE development
Post by: Pieter Hulshoff on March 31, 2017, 12:19:44 PM
My guess is the special characters just aren't supported.

RetroFE was programmed to use standard C++ strings, which indeed do not support UTF-8. It's quite a big program wide change to get this supported, but it's certainly on my to-do list. :)
Title: Re: RetroFE development
Post by: iGarikoitz on April 01, 2017, 07:53:00 AM
The loading of art now always waits until the animations are complete. The onHighlightExit animation doesn't trigger until all menu animations have stopped.

It's basically:
- menu actions
- onHighlightExit
- load art
- onHighlightEnter


Can I disable this? Because it break my theme
Title: Re: RetroFE development
Post by: Pieter Hulshoff on April 01, 2017, 07:55:30 AM
The loading of art now always waits until the animations are complete. The onHighlightExit animation doesn't trigger until all menu animations have stopped.

It's basically:
- menu actions
- onHighlightExit
- load art
- onHighlightEnter


Can I disable this? Because it break my theme

How exactly does it break your theme if I may ask? Which theme would that be?
Title: Re: RetroFE development
Post by: bodbod on April 01, 2017, 02:04:37 PM
Hey Pieter,

Could you create a new thread for the next release (7.21) and the different functionalities which are currently developped.
Just to keep track and better visibility.

Thanks !
Title: Re: RetroFE development
Post by: Pieter Hulshoff on April 01, 2017, 02:07:37 PM
Could you create a new thread for the next release (7.21) and the different functionalities which are currently developped.
Just to keep track and better visibility.

I'm working on 0.8.0 at the moment; I'm going back to full releases at 0.x, and use 0.x.y as updates. I'll open up new threads as soon as I'm ready with 0.8.0 - RC1.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on May 24, 2017, 07:44:06 PM
I've created a new (closed) thread for new versions; that way people can easily find the latest executable.
Just up: 0.8.6: http://retrofe.nl/SMF/index.php?topic=177.msg1781#msg1781
Title: Re: RetroFE development
Post by: Pieter Hulshoff on May 28, 2017, 08:12:24 AM
I've replaced the first post with a link to the RetroFE bitbucket issue list. You can find all the feature requests there from now on. Let me know if there's something missing, and I'll add it. That way we can keep track of what needs to be done still.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on July 08, 2017, 04:37:37 PM
Feature proposal:
- Add a parameter to the generic settings.conf to turn on the following feature:
- RetroFE will determine the screen ratio: 4:3, 5:4, 16:9, 16:10, 3:4, 4:5, 9:16, 10:16, and load a layout <ratio>.xml accordingly if available. If none is found, layout.xml is loaded in stead.
This will allow RetroFE to automatically select a ratio based layout (if so provided), and will allow a setup to be shared between different monitors. This can be especially helpful when setting it up on the RetroPi so users don't have to manually change that.

Any thoughts?
Title: Re: RetroFE development
Post by: dougan78 on July 09, 2017, 02:18:38 AM
Interesting idea.  How would one setup a layout for all those ratios?  Would be separate artwork per ratio?
Title: Re: RetroFE development
Post by: Pieter Hulshoff on July 09, 2017, 06:39:24 AM
It would be a different layout per ratio, similar to how Aeon Nox is doing it currently. The artwork could be the same; Aeon Nox uses the same artwork for 4x3 and 16x9, but 4x3 displays fewer menu elements, and has a bit more space for others.

Sent from my SM-G920F using Tapatalk

Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 10, 2018, 05:08:49 PM
I've managed to get a working stand-alone control configuration tool on Linux. I plan to add this code into RetroFE, so it will ask the user for input in case no controls.conf file is available. This should go a long way in helping people configure their keys, because frankly: it currently is trial-and-error for many controllers. :)
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 11, 2018, 03:42:14 PM
Ok, here's a 0.8.15b1 executable for you to play with. Please consider that this is partly untested code, so make a backup of your current executable before trying this one. You'll need to put both the retrofe.exe as well as the OpenSans.ttf file in your core directory for this to work properly.

New features:
- RetroFE will look for a layout xml file based on your window's aspect ratio before loading loading.xml. This will allow you to create a single setup where e.g. layout 4x3.xml or layout 16x9.xml will be loaded depending on your connected monitor setup. Currently only Aeon Nox offers these files, but I think it would be a nice addition for future purposes.
- RetroFE will ask for user input if no controls.conf file is found. This will allow you to configure the RetroFE controls on start-up so you don't have to go through trial and error to figure out how certain controller buttons map to RetroFE codes.

I'd love for people to run some tests, and provide me with some feedback. The control configuration's certainly not a graphical marvel, but in my tests so far it gets the job done.
Title: Re: RetroFE development
Post by: goldorakiller on February 16, 2018, 10:48:50 AM
Hello,
I've just made some test.
I remove control.conf and test.

There are too much screen and key to enter. It seems to have duplicate things.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 16, 2018, 05:38:20 PM
Hello,
I've just made some test.
I remove control.conf and test.

There are too much screen and key to enter. It seems to have duplicate things.

There are two control options:

A control is mandatory, like Menu Up:
1. It asks you for a key; enter a key.
2. It asks you for another key; enter another key, and go to 2 or wait 10 seconds to go to 1 for the next control.

A control is optional, like random game selection:
1. It asks you for a key; enter a key or wait 10 seconds to go to 1 for the next control.
2. It asks you for another key; enter another key, and go to 2 or wait 10 seconds to go to 1 for the next control.

In 2, in stead of waiting 10 seconds, you can also press the same key you pressed before to go to the next control.

Just read carefully what it says on the screen.
Title: Re: RetroFE development
Post by: KMetalMind on February 17, 2018, 10:14:48 AM
Hi Pieter!

On Windows, without controls.conf, it doesn't open for me:
Code: [Select]
[2018-02-17 11:06:33] [INFO] [Configuration] Importing "Z:\Super DreamStation Plus\RetroFE 0.6.169\controls.conf"
[2018-02-17 11:06:33] [ERROR] [Configuration] Could not open Z:\Super DreamStation Plus\RetroFE 0.6.169\controls.conf"
[2018-02-17 11:06:33] [ERROR] [RetroFE] Could not import "Z:\Super DreamStation Plus\RetroFE 0.6.169\controls.conf"

I haven't find any regressions on anything I use on my build, which is awesome, as I still used v0.7.21b1  :D
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 17, 2018, 05:07:10 PM
Hi Pieter!

On Windows, without controls.conf, it doesn't open for me:
Code: [Select]
[2018-02-17 11:06:33] [INFO] [Configuration] Importing "Z:\Super DreamStation Plus\RetroFE 0.6.169\controls.conf"
[2018-02-17 11:06:33] [ERROR] [Configuration] Could not open Z:\Super DreamStation Plus\RetroFE 0.6.169\controls.conf"
[2018-02-17 11:06:33] [ERROR] [RetroFE] Could not import "Z:\Super DreamStation Plus\RetroFE 0.6.169\controls.conf"

I haven't find any regressions on anything I use on my build, which is awesome, as I still used v0.7.21b1  :D

Which version exe and full version did you test this with? Can you post your full log.txt?
Title: Re: RetroFE development
Post by: KMetalMind on February 17, 2018, 08:47:07 PM
Of course, here it is  ;) log_ok.txt is a working log and log.txt is after deleting controls.conf.

The exe is the one you last posted. Some other files may be outdated. Should I update them? Everything works perfectly unless I delete controls.conf.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 17, 2018, 10:36:42 PM
Of course, here it is  ;) log_ok.txt is a working log and log.txt is after deleting controls.conf.

The exe is the one you last posted. Some other files may be outdated. Should I update them? Everything works perfectly unless I delete controls.conf.

You forgot to add the font your core directory...
Title: Re: RetroFE development
Post by: KMetalMind on February 18, 2018, 06:53:14 AM
My mistake, I had the font file on the main directory and not on the core one  :-[ Mixed both words.

My opinion: The controls configuration works perfectly and I don't know if I would personally evolve it much right now. Maybe you could assign a key in retroFE for triggering this config?

Minor improvements that could be done, all subjective:

Haven't tested the aspect ratio one, just that it works on 16:9 right now. Can somebody with a cabinet test it properly?

Edited after remembering that you can indeed configure multiple keys right now  :-[
Title: Re: RetroFE development
Post by: Pieter Hulshoff on February 18, 2018, 08:30:54 AM
I've given it some more thought, and it's quite possible that I'll replace the whole thing with a menu anyway. I'm currently in the process of thinking out exactly how I want that to be integrated into RetroFE, and it should be able to support much more than just key configuration. I'll use the existing layout features to handle it in stead of writing a separate one like I did for this feature. That way people can even integrate a cool menu structure within their theme if they want (and otherwise it will use the default).

I'm not sure I understand your remark regarding multiple key support though; I thought the current feature already supported that. It allows you to set multiple keys for each UI control.
Title: Re: RetroFE development
Post by: KMetalMind on February 18, 2018, 09:09:16 AM
Yeah, it supports it, I just wasn't paying enough attention  :-[

A menu feature using the layout system would be literally perfect! I would love it  ;D It would be nice too if the options in the menu could be configurable too (reorder options, change option names, don´t use some options, etc). That would let people remove options they don't want to use, translate it, etc. It would need some kind of new txt config in the main path though, and it would be a little harder to program, but it would be totally configurable then  :)
Title: Re: RetroFE development
Post by: billyc666 on April 01, 2018, 10:33:03 PM
i thought i would try this version by putting it in the core folder, however when i run it it only goes as far as splash screen then quits
log file lists an error at the end

[2018-04-01 22:27:10] [ERROR] [Input] Missing property controls.menu
[2018-04-01 22:27:10] [ERROR] [RetroFE] Could not initialize user controls
Title: RetroFE development
Post by: Pieter Hulshoff on April 01, 2018, 10:50:43 PM
Hmmm, I may need to add the menu files for people to run this version. I’ll upload those tomorrow. Sorry about that.
Title: Re: RetroFE development
Post by: Sequence on April 01, 2018, 11:07:43 PM
Yes, I received the same errors. Won't boot past the splash for me either.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on April 01, 2018, 11:28:08 PM
Yes, I received the same errors. Won't boot past the splash for me either.

I’m in the middle of implementing a configuration menu, so it currently expects a key for menu in the controls.conf file. Since I’m also testing my work, I already have that key configured in there. You could add it, but since you’re lacking the menu files I’m not sure what happens if you press the button then.


Sent from my iPad using Tapatalk
Title: Re: RetroFE development
Post by: BritneysPAIRS on April 01, 2018, 11:31:14 PM
:) I wanted to test this also...looks like ill have to wait
Title: Re: RetroFE development
Post by: Pieter Hulshoff on April 02, 2018, 11:07:31 AM
Here's 0.8.15b3. This should fix the issue regarding the missing menu button. As said: I'm in the middle of implementing the configuration menu structure when these requests for bug fixes came in. Guess that'll teach me to start working in branches again. :) Let me know if you encounter any other issues.
Title: Re: RetroFE development
Post by: billyc666 on April 02, 2018, 04:25:59 PM
working fine now, is the menu already accessible?
Title: Re: RetroFE development
Post by: Pieter Hulshoff on April 02, 2018, 05:46:45 PM
working fine now, is the menu already accessible?
No, it requires an extra set of files to use. I have some WIP, but it's very preliminary.

Sent from my SM-G950F using Tapatalk

Title: Re: RetroFE development
Post by: Pieter Hulshoff on April 08, 2018, 08:56:09 AM
Here's 8.15.b4. I've changed the lack of SDL audio from ERROR to WARNING; hopefully this will allow Windows 10 users without an audio setup to still run RetroFE (in silence).
Menu activity is still WIP, so not usable.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on April 18, 2018, 09:02:16 PM
'Here's 0.15.b5. I've changed the splash interruption to only react to an actual press of the select key rather than any SDL key event. This should prevent analog inputs from stopping the splash video.
Title: Re: RetroFE development
Post by: BritneysPAIRS on April 20, 2018, 12:06:57 PM
Cool just noticed this ill grab this tommorrow
Title: Re: RetroFE development
Post by: Pieter Hulshoff on June 20, 2018, 09:57:22 PM
My apologies for my silence lately. I've been very busy with my new job, but have recently started adding some features again. I'm in the process of finishing up with those, and adding support for the latest truRIP (super)dat files, after which I hope to do a full release again. Since there are some improvements in the animations department, I also plan to update the Aeon Nox theme accordingly.

As some of you may have seen: CoinOPS is working on some new releases for PC, and they've selected RetroFE to use as a base for their work. From what I've seen so far, it should be possible to extract a theme from their work as well that people can load on top of their current RetroFE installation.
Title: Re: RetroFE development
Post by: iGarikoitz on July 01, 2018, 06:54:40 PM
I am using version 8.15.b5 and it seems that it has a bug when you use the buttons to go from letter to letter that makes the videos start twice.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on July 01, 2018, 07:12:50 PM
You are correct; it's fixed in bit bucket already.

Sent from my SM-G950F using Tapatalk

Title: Re: RetroFE development
Post by: Pieter Hulshoff on July 04, 2018, 07:12:48 PM
While you're waiting for me to finish my work: here's 0.8.16 to play with. Keep in mind that onPlaylistExit/Enter and onMenuJumpExit/Enter animations have replaced the onHighlightExit/Enter animations for changes in playlist and jumps through the menu (next/previous page/letter and random).
Title: Re: RetroFE development
Post by: dougan78 on July 05, 2018, 02:17:26 AM
Sounds like some themes will need updating again.  Will have a look.  Thanks again for your hard work!
Title: Re: RetroFE development
Post by: Pieter Hulshoff on March 24, 2019, 09:27:38 PM
Here's version 0.8.23 to play with. I haven't run extensive tests on it yet, but it seems to be working as expected. As always: Please make sure to back up your working retrofe.exe before using this one.

The latest feature I added is volume control for video. The parameter is called "volume", and should work for animations as well, allowing for fade-in/out of sound as well as playing videos without sound. That last one will allow me to add mp3 support soon so you can add your own music.

I know I'm a bit behind on bug fixing; I'll start on that later this week. I'm starting to get the hang of it again, and it seems my schedule's cleared up a bit, so I should have some time to invest in programming again. :)

Edit: Made a small update to set the default volume to 1.0 to prevent everyone from needing to update their themes.
Title: Re: RetroFE development
Post by: iGarikoitz on March 24, 2019, 10:16:15 PM
I just tried the new volume feature and it works fine. What changes are there since version 0.8.18, apart from adding this new feature?
Title: Re: RetroFE development
Post by: jonny555 on March 31, 2019, 11:51:08 PM
Here's version 0.8.23 to play with. I haven't run extensive tests on it yet, but it seems to be working as expected. As always: Please make sure to back up your working retrofe.exe before using this one.

The latest feature I added is volume control for video. The parameter is called "volume", and should work for animations as well, allowing for fade-in/out of sound as well as playing videos without sound. That last one will allow me to add mp3 support soon so you can add your own music.

I know I'm a bit behind on bug fixing; I'll start on that later this week. I'm starting to get the hang of it again, and it seems my schedule's cleared up a bit, so I should have some time to invest in programming again. :)

Edit: Made a small update to set the default volume to 1.0 to prevent everyone from needing to update their themes.

Nice pieter
Thanks can do some good things with this feature
Title: Re: RetroFE development
Post by: Pieter Hulshoff on April 01, 2019, 08:40:01 AM
I just tried the new volume feature and it works fine. What changes are there since version 0.8.18, apart from adding this new feature?

- Parent add (for clones) was given priority over default art.
- Added support for a menu directory as alternative for menu.txt.
- Added support for exclude_all.txt; a filter for the automatically generated "all" playlist.
- Added volume support for videos.
Title: Re: RetroFE development
Post by: iGarikoitz on April 01, 2019, 12:25:34 PM
- Added support for a menu directory as alternative for menu.txt.
How can I use this?
Title: Re: RetroFE development
Post by: Pieter Hulshoff on April 01, 2019, 01:01:19 PM
- Added support for a menu directory as alternative for menu.txt.
How can I use this?

Not sure if you really need it; it was mostly added to allow drag-and-drop pack creation, but the idea is to use (empty) .txt files in a menu directory rather than the menu.txt file, so in stead of

menu.txt:
Arcade
NES
SNES

you would have

menu/Arcade.txt
menu/NES.txt
menu/SNES.txt
Title: Re: RetroFE development
Post by: Enkak on April 02, 2019, 01:24:07 PM
I just tried the new volume feature and it works fine. What changes are there since version 0.8.18, apart from adding this new feature?

- Parent add (for clones) was given priority over default art.
- Added support for a menu directory as alternative for menu.txt.
- Added support for exclude_all.txt; a filter for the automatically generated "all" playlist.
- Added volume support for videos.

Thank you for the update. The exclude_all.txt has already been useful here to keep out from the lists things like bios files.
A missing feature in RetroFE at the moment that I would love is the get back to last menu/last game selection like Attract-Mode has for example, instead of seeing/hearing always the same default menu/game every time we launch RetroFE.

PS: I'm currently focused in making RetroFE working with RocketLauncher in the background (for extra bezels for certain systems, etc.) with everything plug and play/relative paths/pre-configured and stable. Working good already.
Title: Re: RetroFE development
Post by: iGarikoitz on April 20, 2019, 06:05:05 PM
Pieter Hulshoff I would like to have the option of jumping between the playlist while you continue pressing the nextPlaylist / prevPlaylist button but in an intuitive way, I explained:

Now, when you press the nextPlaylist button, you go to the next playlist, but first the onPlaylistExit animation is executed and then the onPlaylistEnter animation is executed. This is repeated whenever you want to move from one playlist to another and it becomes very slow.

I would like to include a new animation called onPlaylistChange. What would this new animation be for?

By pressing and holding the nextPlaylist button, it would go from playlist to playlist but only in the onPlaylistChange animation. That is:

1. Enter the onPlaylistExit animation and then the animation onPlaylistChange.
2. The onPlaylistChange animation will be run as long as you do not release the nextPlaylist button and in this way you control the time it takes to go from one playlist to another.
3. When you release the nextPlaylist button, the onPlaylistEnter animation is executed.

* The same could also be applied to the letterUp / letterDown buttons adding also the animation onMenuJumpChange.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on April 20, 2019, 06:21:07 PM
Pieter Hulshoff I would like to have the option of jumping between the playlist while you continue pressing the nextPlaylist / prevPlaylist button but in an intuitive way

I'll give it some thought. I could probably add a check for input in the state machine after the art reloading, and act accordingly.
Title: Re: RetroFE development
Post by: Agent47 on April 20, 2019, 10:05:38 PM
Or even better, a menu for playlists. The next/prev is ok if you only have 2-3 playlists but if you have more than that (ie genre playlists) it's pretty clunky to navigate.
Title: Re: RetroFE development
Post by: Pieter Hulshoff on April 20, 2019, 10:16:36 PM
Or even better, a menu for playlists. The next/prev is ok if you only have 2-3 playlists but if you have more than that (ie genre playlists) it's pretty clunky to navigate.

CoinOPS Forgotten Worlds has made some interesting setup for that. It's certainly possible with the current setup.
That said: I've had a similar request from them regarding a playlist menu. I need to see how best to include that in the program structure.