Announcement

Collapse
No announcement yet.

Unreal Ed 3.0 selection issue with Windows 10

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • started a topic [BUG] Unreal Ed 3.0 selection issue with Windows 10

    Unreal Ed 3.0 selection issue with Windows 10

    Hi all. Does anyone know how the fix to this issue? It has been taking FOREVER to get anything done on a map. Thanks in advance for your time!

  • replied
    Originally posted by GLoups_AA View Post
    It's possible to install drivers for CPU intel integrated graphics and force an application to use it via the Control Panel or directly in W10 (Amd and Nvidia), like the Intel HD Graphics 630 which would be amply sufficient for ut2004, to make a test and see if the issue is Nvdia or amd related.

    https://support.serato.com/hc/en-us/...ging-graphics-

    https://www.laptopmag.com/articles/i...ics-comparison

    Hi, I didnt expect my i5 3450 supporting IGP, I turned it on in bios, installed the driver, the portviews are fine, but cpu still cant handle 18 static meshes, (selection delay was gone, as expected from disabling dGPU).
    Ive set memory size from 128 (default) to 1024, still nothing, its like it isnt even there

    You cannot force an application to use it on desktops. Nvidia Optimus does that, but it isnt supported on desktops, only laptops.
    There are ways to enable it, i got blackscreen and a bsod yesterday trying to enable it on win10 desktop, so this didnt work well.
    I basically still have to disable entire dGPU to use CPU Graphics, in the nvidia control center the option to choose which G-Processor to use isnt there. (Also rightclick on the .exe has no option to run on a specific GPU)
    Ive researched and it is only laptops with Nvidia Optimus which gets that option in the control center.

    So yeah thats that, my biggest question is why is it having no input delay when its on CPU, and suddenly gets one on dGPU.
    I wish the Integrated Graphics would change anything performance wise, in the SDK it doesnt feel like any performance was gained when its run on the CPU while IGP drivers are installed.

    HUGE EDIT:

    The trick isnt installing integrated graphics for the cpu only.
    It was to connect same screen twice. Once in mainboard, and once in GPU.
    Now: Win+P and choose "Only Another Screen" (Last option); the monitor swaps to the Mainboard connection (Automatically using integrated graphics).
    I was not aware that the cpu graphics wont work if the screen isnt plugged in mainboard (but came to me eventually with some thinking).
    This works as a solution for me specifically since i was only looking for a way to keep mapping on same pc, without lag because of cpu.
    All it takes is 2 actions: Win+P, choose last option, when done mapping, Win+P, first option.
    Windows thinks this way that the mainboard connection is the second screen btw.
    I got some answers from TWI aswell, they wont support and help with anything regarding this old SDK, they need to adress it and recompile, i can understand that its gonna be very complicated due to time and adapting to newest drivers. (Since it sounds to one of the TWI guys that its indeed windows/gpu driver related, but nothing for sure).

    With that said, Ill keep checking in here if someone trying to find a better solution than the above.
    For tech savy's: (Get Process Monitor(ProcMon)) and if youre patient, youll figure out that its very likely Direct3D. What to do with this information? I have no idea
    Last edited by Coffeediction; 06-18-2019, 04:49 PM.

    Leave a comment:


  • replied
    It's possible to install drivers for CPU intel integrated graphics and force an application to use it via the Control Panel or directly in W10 (Amd and Nvidia), like the Intel HD Graphics 630 which would be amply sufficient for ut2004, to make a test and see if the issue is Nvdia or amd related.

    https://support.serato.com/hc/en-us/...ging-graphics-

    https://www.laptopmag.com/articles/i...ics-comparison

    Leave a comment:


  • replied
    Originally posted by Party Boy View Post
    There is something different in the way viewports are being rendered, for a start, selection works with AA enabled...
    I tried both, AA on and off, no changes :/

    Leave a comment:


  • replied
    There is something different in the way viewports are being rendered, for a start, selection works with AA enabled...

    Leave a comment:


  • replied
    Originally posted by Dr.Flay View Post
    Well that makes no sense at all !
    OpenAL doesn't use a viewport. Weird.

    You could try disabling audio in the editor section of the ini and see if that error is still there.
    It could be worth replacing your DefOpenAL32.dll with a newer version of OpenAL32.dll from the creative labs installer or whatever AL driver your sound card uses.
    You may also need an updated wrap_oal.dll from the same source.

    Yep, its not OpenAL, the actions in the (background) are varying, sometimes it says "Closing" or anything else, so i guess has nothing to do with it.
    Funny is when you close all the windows (Texture Browser, Mesh Browser etc.) and minimize, then hover over the taskbar of the SDK, you see the windows still open. Not sure if its related.

    So for now the best way to avoid it, is to disable the GPU and work on CPU, drawback is, the more static meshes you start to add, you get to a point where the CPU cannot handle it anymore (mostly late mapping ofcourse)
    Still trying to find a more universal solution.

    Here a list again of what was tried from me and few other people who suggested to try thing and tried themself:

    Basic stuff:
    - Drivers, updated, rollbacked to any possible driver for the current GPU
    - Admin mode
    - Compatibility modes
    - Reinstall SDK, Steam, Verify cache
    - Tried standalone unrealed SDK (a different build too)
    - Moved from HDD to SSD
    - Increased Ram support for the .exe (from 2 to 4?)
    - Nvidia control settings (anything), Note: You cannot change the setting to not use the GPU on desktop, only laptops, disabling GPU from device manager does the same basically, but for everything, not just the .exe you chose.
    - Playing with refresh rates
    - Installing the CRD drivers (Creator drivers of nvidia, apparently specially designed for design/creations/development), but seem not to do anything actually, like at all, anywhere.
    - Trying some third party softwares for "boosting" performance of a programm (i know its bs most of the time, but .. desperation)
    - Disabling UAC, Firewall, everything (even Defender and any other application possible)
    - A new partition with a fresh Win10 Pro installation, with ONLY the SDK installed. (GPU Drivers where provided by windows automatically, also updated afterwards)
    And a few more I probably dont remember, since they were so bizarre and primitive/basic.


    More advanced indepth stuff:
    - Tweaked the .ini for opengl, d3d, performance settings etc. (pretty much any setting there which make sense)
    - Tweaked the editor ini for window sizes and their renderers
    - Tried a dgvoodoo d3d8 wrapper (worsened performance, the input delay issue was still unchanged, basically it did not affect the input at all)
    - Another GPU (from GTX 1060 to 660), cannot try AMD, as I dont have a card around of them, and its not a really a universal solution since the gpu is essential for others things aswell (Unless someone can try with AMD then we might know if its nvidia directly)
    - Changing write/read permissions of a a lot of files
    - ReduceMouseLag=false/true in the ini

    What I did not try:
    Changing something with the mouse itself, but I don't really know what exactly is to change/tweak and where.
    Since its a mouseinput issue, it CAN be related to it somehow (I tried to emulate the mouseinput over keyboard, still same delay too)

    When you zoom in all the portviews the most possible, it is slightly faster to process the mouseinput.
    So.. basically my thoughts are that every click does something, i guess it re-renders the portviews and that is re-rendered faster when zoomed in, since less pixels are to render? Something like this.. my head is out of ideas at that point. Sigh.

    Last edited by Coffeediction; 06-16-2019, 03:13 PM.

    Leave a comment:


  • replied
    Well that makes no sense at all !
    OpenAL doesn't use a viewport. Weird.

    You could try disabling audio in the editor section of the ini and see if that error is still there.
    It could be worth replacing your DefOpenAL32.dll with a newer version of OpenAL32.dll from the creative labs installer or whatever AL driver your sound card uses.
    You may also need an updated wrap_oal.dll from the same source.

    Leave a comment:


  • replied
    I found something intersting and bizarre... a little creepy too...
    So when i opened a bigger map, and clicked on something, it froze up as usual... now hovering over the taskbar window of the editor, reveals a preview of unrealed with this:

    Click image for larger version

Name:	xtNYCc4.jpg
Views:	1
Size:	148.9 KB
ID:	405737

    YEP while its frozen, this is what its been doing in the background (the message isnt visible in foreground, only if hover overed the taskbar's window for preview)

    Ideas?

    Leave a comment:


  • replied
    Originally posted by Coffeediction View Post
    I dont understand your quote and what it has to do with it.
    I don't think there is a more specialized expert in UnrealEd viewport behavior than Epic them self...

    If at least they had read me...

    Leave a comment:


  • replied
    I am starting to wonder if the culprit is ddraw.dll
    Try putting a copy of an older ddraw.dll from Windows 8.1 in the UT system folder maybe. If it fails to load from there and you are fine with tinkering in the system, backup the one in windows\system32\ and replace it there.
    We really need to pester Epic to see if we can get a GL, DX9 or higher renderer made.
    They could trust Smirftsch with the task if they can't be arsed with it, as he is the sanctioned and licenced source of all the new UE1 renderers.

    Leave a comment:


  • replied
    Originally posted by Party Boy View Post

    If you've read the thread, you'll see that I asked Epic directly...
    Yes I did too so?
    I dont understand your quote and what it has to do with it.
    Anyways, ive setup a winxp and gave up on this, talked to a few people, its very likely that the OS itself causing this due to how the editor is written.

    Leave a comment:


  • replied
    Originally posted by Coffeediction View Post
    need an expert here to "what happens when clicked in the portview"
    If you've read the thread, you'll see that I asked Epic directly...

    Leave a comment:


  • replied
    Originally posted by meowcatbuf View Post
    Coffeediction, I'm not super familiar with computers, but how did you disable your GPU? Did you have to restart and change something in the bios, or connect your monitor to the motherboard's onboard video output?

    I don't have a Windows 10 machine yet and this thread in particular concerned me a lot since I used UEd several times a month and will need to upgrade sometime this next year.
    Just disable it in the Device Manager, if the resolution breaks down, set it on normal again through windows settings (Win10 does that automatically).
    I also posted a thread to around 4 Forums about this, Nvidia forum is trying to help, but we are getting slowly out of luck. We even tried d3d wrappers to emulate d3d8, which did change things but didnt fix the slow mouseinput issue.
    So disabling the GPU fixes it, but without gpu its quite hard to do mapping on the CPU only (without integrated grafics), specially if the map is bigger and loaded with textures.
    Now who has a CPU with Integrated Grafics, is in a better position here.

    I even got UT2004 standalone just to test if the issue is persistent (Sorry EPIC, its for the science, I removed it after confirming it), and indeed the UnrealEd or KFEd are the same thing and having the same issue, even an out of steam installation.
    So it is 100% something with GPU + Win10 compatibility, but my theory it being d3d or opengl is slowly fading into windows10 general driver issues which work with the gpu.
    The 4 viewports are rendered separately as i understood right and it is even possible (in theory) to set for every viewport its own render device in the unrealed.ini. But using opengl doesnt allow you to open the editor anymore.
    Maybe those things can help someone here to figure something out, its more about trying everything and narrowing down the problem to one single thing.

    Here the issue described better with some things I tested based on suggestions:
    The thread cuts out the whole content, so i put it into a pastebin (see link at the end)

    One more thing needs to do is to get as much people as possible to install UT2004 or Killing Floor 1 and let them open the editor and see who has NO issue on Win10 + GPU so he can tell us the stats, helps narrowing down a lot here.
    It is just very hard to post in every thread because people logically assume you are an amateur and suggest reinstalling the drivers first or such basic things obviously (I dont blame anyone, its just natural), which means describing every single thing I did gonna take a very long time


    EDIT: Zooming in extremely makes it lag way less but still freezing up for 3-8 seconds. Something with portview re-rendering when clicked? :O Not sure.. need an expert here to "what happens when clicked in the portview"
    Last edited by Coffeediction; 05-22-2019, 09:30 AM.

    Leave a comment:


  • replied
    Coffeediction, I'm not super familiar with computers, but how did you disable your GPU? Did you have to restart and change something in the bios, or connect your monitor to the motherboard's onboard video output?

    I don't have a Windows 10 machine yet and this thread in particular concerned me a lot since I used UEd several times a month and will need to upgrade sometime this next year.

    Leave a comment:


  • replied
    Same Issue here, Im kinda relieved a bit that I found ANY people suffering on it.
    I am a mapper for Killing Floor 1, using KF SDK (KFEd) basically same editor.
    I made a map back in 2017, with the same issue, and I had windows 10 Home 64 running.
    Then I opened my map on Windows 8 (Laptop with pathetic 4GB ram).. and wow, no problems.
    Now in 2019 I got a new Win10 Pro installation on my desktop, and the issue still persists. Which means it is win10 related.
    Now, what I did notice:
    Win10:
    When a map is not loaded, the editor reacts with slight delay, 1 sec max
    When a map IS loaded, depends on size it takes upto 15 seconds to popup a context menu.
    Win8:
    Doesnt matter how big the map is (I even overloaded it with (almost 4GB ram usage, right before crash), it reacted instantly. The issue wasnt there.
    So my best guess is that the gpu drivers generally used by win10 are not working properly, and thats not anything new since windows10 is having a bad reputation when it comes to GPU compatibility (past issues nvidia+win10 prove it, specially after win10 updates..)
    I still hope to find a solution for this.

    EDIT: I found something out, disable your GPU and start the editor, it somehow started to work normally. Must be something with D3D or OpenGL on Win10!
    If someone knows how to fix it without disabling the GPU, let us know here asap please!
    Last edited by Coffeediction; 05-21-2019, 05:58 AM.

    Leave a comment:

Working...
X