[Solved] Problem with Windows 10 and device->run()

[Cymoth]

Hi everypody,

I've been tinkering with a game project for a while, and after updating to windows 10 I encountered a rather fishy problem. I wonder if this is with my system, or something more fundamental, as I'm running out of ideas how to fix this:

So I'm using Irrlicht 1.8.1, in Windows 10 (earlier Windows 7) and Microsoft Visual C++ Express 2013

I think the problem boils in these few lines:

Code: Select all

 
    device = //EDT_DIRECT3D9,EDT_OPENGL,EDT_BURNINGSVIDEO,EDT_SOFTWARE
        createDevice(video::EDT_DIRECT3D9, conf.win_size, 32, conf.full_screen, false, conf.vsync, &receiver);
    if (!device) //JL: If DIRECT3D9 fails (as with mingw! ?), try OpenGL.
        device = createDevice(video::EDT_OPENGL, conf.win_size, 32, conf.full_screen, false, conf.vsync, &receiver);
    if (!device)
        return 1;
    std::cout << "DEVICE RUN RESULT:" <<device->run();
 

Now, in all cases the first createDevice succeeds, so I get Direct3D9 device.

And in my old setup everything worked perfectly.
In windows 10 if I run my program in "release" configuration things still work fine.
However, running in debug mode causes the device->run() to return zero. (and further crashing the program)
The same seems to happen if I run the exe from "release" setup straight from windows10, not inside the visual Studio.
Then again, the "release" exe works perfectly fine, if I run it from windows10's command prompt.

Any idea what might be the cause of this?
Any idea what can cause the device to not run, while it still gets created (as far as I know) fine. Or is there some check I could still do before trying to run?

(edit:fixed a typos)

[mongoose7]

You have to recompile the Irrlicht DLL. MSVC won't let you mix debug and release versions.

[CuteAlien]

mongoose7: Running into that should give compile-errors (or maybe it was linker errors - anyway not runtime errors). The reason mixing isn't easily allowed is about mixing debug/release versions of STL to my knowledge. So it's fine with Irrlicht as it doesn't use STL (VS might still complain, but you can get it to shut up).

Cymoth: Different behaviour inside and outside of VS is often caused by paths (files you try to load from a relative path).
I don't think the lines you posted are the problem - those look fine (thought we can obviously not telll if &receiver is fine as we know nothing about the scope it or the code calling it are in).

[luthyr]

You have to recompile the Irrlicht DLL. MSVC won't let you mix debug and release versions.

We ran into this issue as well with Visual Studio 2015. For now, we just continue to compile Irrlicht with VS2010 and it seems to get around it.

[Cymoth]

mogoose7, CuteAlien, Thanks for your help.
I've tried to look it bit further. My guess at the moment is, that something, somewhere is uninitialized.

I had the device->run() as a loop end condition, which caused the game end immediately after loading. I tested to remove it from the loop condition, just run it in every cycle.
It still returns zero every frame, but graphics work as they should. It looks thou as some button would be constantly on in these cases... I guess the receiver is somehow broken, or something in Win10 is just different enough that things that work earlier don't anymore.

I don't quite understand thou how the graphics works even if device-run() returns zero, or is that normal?


I must spend bit more time digging my code, and unless I'm too embarrassed after figuring out what's wrong here will tell what the problem was/is.

luthyr: for me the VC Express 2013 worked pretty well with irrlicht until I noticed this clitch with Win10.

[Cymoth]

So far, have figured out two problems:

- as mentioned the device->run() returns zero in some conditions (debug mode, running outside VC (unless through prompt))
This doesn't seem to have any effect on drawing the game as such tho.
Instead when this happens there seems to be some "ghost" game-pad which has few buttons jammed..which leads to second problem

-It seems my gamepad detection code returns one pad too much (this seems to happen always, just never noticed it before ) In release version this doesn't seem to cause any problems tho, as I guess it is initialized as zero for all states or something.

Code: Select all

    
...  receiver defintion ...
core::array<SJoystickInfo> joystickInfo; //info of the active joysticks
...
 
receiver.joystickInfo.clear();
device->activateJoysticks(receiver.joystickInfo);
std::cout << "FOUND JOYSTICKS: >>> " << receiver.joystickInfo.size() << " <<<\n";
 

The size is one, if I have no pads attached to computer, 2 if one etc... I guess I should figure out if this is just a problem with my computer... oh well of to bed for now.

[Cymoth]

Ok, I finally figured out what was wrong here:

The thing was, that earlier in the software I created another temp device for reading some files needed before initialising the actual device:

Code: Select all

 
    irr::IrrlichtDevice *tmp_dev;
    if (vwg != NULL && vwg->device != NULL)
        tmp_dev = vwg->device;
    else
        tmp_dev= createDevice(video::EDT_NULL);
 
    irr::io::IFileSystem* fs = tmp_dev->getFileSystem();
    irr::io::path tmp = vwg->conf.dir_mods.c_str();
    if (!fs->changeWorkingDirectoryTo(tmp))
    {
        //failed to change to mod directory
        std::cout << "Failed to find mod directory.\n";
        vwg->mods.clear();
        return false;
 
    }
    irr::io::IFileList* f_list = fs->createFileList();
    tmp = vwg->conf.dir_main.c_str();
    fs->changeWorkingDirectoryTo(tmp);
    vwg->mods.clear();
    for (unsigned int i = 0; i < f_list->getFileCount(); i++)
    {
        if (!f_list->getFileName(i).equalsn(".", 1) && f_list->isDirectory(i))
        {
            mod_info tmp_inf;
            tmp_inf = get_mod_details(f_list->getFileName(i).c_str());
            vwg->mods.push_back(tmp_inf);
        }
    }
    f_list->drop();
    std::sort(vwg->mods.begin(), vwg->mods.end());
    if ((vwg == NULL || tmp_dev != vwg->device) && tmp_dev != NULL)
    {
//      tmp_dev->closeDevice(); //CAUSES HUGE PROBLEMS ON WINDOWS 10 (AND, GUESS, IS USELESS)
        tmp_dev->drop();
    }
    tmp_dev = NULL;
 
 

When finished with it, I closed, and dropped it. Seems closing it was a mistake, as that causes all the problems. (And I guess I really don't have to do it, as I drop it anyway..seemed a good idea at the time:P )
I guess the closeDevice call, can affect other devices, further created also, at least in some specific cases. (Like in my case, debug mode, or WIndows10 running outside editor or prompt)

I don't know if this is a known behavior, but well, now I know. Wheh, started to get bit desperate already.

[CuteAlien]

Do call run() once more after closing it. That eats up events which otherwise might still be in event-buffer of the operating system and might be used by the next device. Or you can call clearSystemMessages() on the new device (before first run()).

[Cymoth]

Thanks, CuteAlien.
I tried to change it that way. Now when releasing temporal device I close it, run() once after, then drop it. And always when creating one, run the clearSystemMessages(), right after ensuring I got a device. It seems to work fine in all cases like that. Feel now once again more confident with the game