RetroFE development

[Agent47]

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.

[Pieter Hulshoff]

Any useful information in the log.txt perhaps?

[FrankyRizzo]

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. 

[Pieter Hulshoff]

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.

[FrankyRizzo]

Awesome thanks for the update. 

[Pieter Hulshoff]

Just got confirmation that the Windows build doesn't run. We're trying to sort it out.

Sent from my SM-G920F using Tapatalk

[Tom Acunzo]

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 

[Pieter Hulshoff]

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

[KMetalMind]

I´ll take a look if I find some time too Could it be a specific VS problem?

[Pieter Hulshoff]

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

[KMetalMind]

It seems it has something to do with the Mac build too  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 

[Pieter Hulshoff]

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

[Tom Acunzo]

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

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 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.

[KMetalMind]

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 

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! 

[Tom Acunzo]

I'm glad it works. But that code block is an older commit than this:

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.