Full Screen Errors, Need Help :(

[Qrion]

We started testing our game with different resolutions and fullscreen / windowed and some weird problems have risen that we can't seem to solve:

1. Sometimes (pretty random) when in full-screen our terrain in both maps dissapears or gets drawn way wrong up in the air. (added screenshots to show whats going wrong)
2. When the player that is the listened server alt-tabs in fullscreen the whole server gets a massive lag spike.

These problems both happen when playing with just a single person or multiple over LAN (Listened server).
We tried several fixes when it comes to the terrain but nothing has helped so far thats why were asking for any suggestions from the community here.

Here are the pics how its supposed to be:



Here are the pics how it (sometimes) is on full-screen:



Have to note that when the player walks into the bunker and out of line of sight of the beach and then goes outside again its propper drawn again.

Halp .

[Wyldhunt]

ALT_TAB+(Server|Listener)=FAIL

Never alt tab the server. Alt Tab uses a huge spike of CPU to process all of the active screens and sort. It's a windows thing that you notice a lot more when multiple computers are depending on that computer. Especially if the server is already under a heavy load trying to keep up with all of the client computers.

As for the graphics, I've seen problems similar to that. Usually, this happens with multiplayer games when there are lag spikes or the server/listener pc can't keep up with the work load. The server controls what shows up where on all of the client computers. The clients depend upon a very strict packet size of information showing up on a very strict schedule. If you are playing the game on the listener and playing fullscreen (Which uses a lot more resources and DX Foo), then random packet fail becomes much more likely. You'll get odd bugs like what you describe.

Here's a test.

Play fullscreen in single player without LAN support. See if it still happens. If it doesn't, then it's a packet/lag thing.

Always make sure that your listener is your fastest computer. If you play the game on the listener as well, try to minimize lag by turning down any graphics/sound settings and windowing your game.

Bug causing spikes won't always be noticeable during game play. If the listener is communicating with 2 computers at 30FPS, it is sending/recieving at least 120 packets/second. It only takes 1 packet to show up or send out slow to bug. The listener will usually recognize a missing packet and request a new one, or re-send it. Sometimes garbled info gets through when there's a lot of high traffic.

[Qrion]

Thanks for the suggestions.
Already figured there was not much we could do about the Alt+Tab on server.

As for the terrain bug, it does happen on the server as much as any client and starting the map without any network game gives the same grafical bug on fullscreen. It does not appear to be a network problem but a terrain (material) + fullscreen problem.

Weird thing is that it only seems to be material of the terrain. The collision is still there and so are all other models, decals, materials, textures etc etc.
It could be a simple setting in our terrain and/or terrain material but we have not found a solution yet.

[Wyldhunt]

Waaay back in the olden days (2002ish :P), I used to mod Neverwinter Nights. There was a fairly popular Hardcore RP server called Abyss404 that had an odd bug that they could never fix. There were these little monsters called swarmers that would spawn in groups and attack you. You always knew that swarmers were coming because there would be a full second freeze while they spawned...
Sometimes, a swarmer would spawn but the mesh would fail to spawn. The controller was there. The swarmer would attack you, but it had no body. Nothing for the player to attack. You had to run away from it and wait until it would eventually despawn itself.

The server went through multiple owners who all added to it and changed it. None of them ever figured out what was wrong with swarmers.
Eventually, it was given to us. Being the code guru that I am, I set about fixing bugs.
Here is what I found:
The way the swarmers were scripted, the engine would spawn a large group of them(up to 12, a lot for the old engine) and begin running their AI at the same moment, assuming that they were already spawned. Any time the server was busy doing anything else, the spawning of the swarmers would fault on Too Many Instructions because of the large group. Then the AI would run, and assume that all of the swarmers were there even if they weren't.
I changed it to spawn them in a loop with a slight (0.05 second) delay in between each, and only trigger the AI after it verified that they were all there. The lag spike disappeared. So did the meshless swarmers of doom.

The moral of this story, and what my best guess is given the random nature of your problem, is that you can only process a limited amount in a given amount of time.

Your issue happens when you have the extra load of drawing a full screen version of your level when it loads. By the looks of it, you have some custom stuff going on. Cell shading at least. Check to see what all you have happening On Level Loaded both via kismet and uscript. If you have anything, try putting a delay before it runs. In kismet, I think you can right click the little connector box and add a delay that way. Set it to something like 1 second. That way, the engine will have a full second to load the graphics before your custom stuff happens. That'll probably be too much of a delay for a final game, but it makes sure that it's enough to fix the bug if it's related to a Too Many Instructions thing. If the delays do fix it, you can shorten them and experiment to see how much of a delay you need. The Cell Shading is probably in the custom lighting in the material and has to do all of those instructions on load. Every mesh that uses a custom lighting material has to run those instructions as well. If all else fails, you may want to try reducing the number of meshes to reduce instructions for testing purposes (Just make sure to save it as a copy first so you don't accidentally lose your original).

Also, check your logs and see if they report any errors when the bug happens. They may list the cause.

[Qrion]

Thanks again for the advice.

We gave the terrain it's own sublevel and made it load 0.1 sec later, at level load it is now solved and the terrain always loads propper. So it does seem a problem with loading everything at once that bugged it.

Only way the terrain bugs now is after a alt-tab on fullscreen, both on server and clients. Since when tabbing back the engine still tries to build everything at once. Any way to also load sublevels later when tabbing back into the game or is this all native/impossible?

[Wyldhunt]

I think the Alt Tab problem is Micosoft not making proper use of Direct X to redraw everything when you make a window selection. It's native windows/DX code that re-draws the window on Alt Tab. If you have any good C++ programmers, they might be able to find some way to DLL Bind a UDK plugin that checks to see if the game window is in the background and re-run the On Level Loaded stuff when it first detects that it's no longer in the background. I'm not entirely sure if that would be possible without source code access though. You'd need some way to grab the On Level Loaded event and re-process the whole thing to fix the Microfail.

I'm guessing that the reason it's the terrain material that always goes away is because the terrain is the largest mesh and your custom lighting has to run on every bit of it before the material can show up. If the PC only has to worry about the terrain, it can do it. If it has the terrain and everything else, it times out because the terrain is such a huge chunk.

Your best way of fixing it may be to reduce your instruction count in your cel shader (I assume that it's in your material). That would probably be tricky if you want to maintain your high quality, but you may be able to slightly reduce the instruction count on only the terrain materials and leave everything else full quality. Without your material, I can't give any advise on what you could tweak (I'm not very good with cel shaders anyway), but that would give you a permanent fix if you could streamline it enough.

[Qrion]

Removed the shader, problem persists (not solved)

[Wyldhunt]

Hmm...
Well, not the shader then.
What else are you running On Level Load?
The reason it only happens sometimes is because of the combined instructions of everything. It may not be a single thing. It's the workload of spawning the meshes, applying the materials, applying the light/shadow maps, calculating dynamic lighting/shadows for the dynamic actors, loading in any controllers for the pawns, running any initial on load checks that you may have for your personal systems, loading the HUD, etc.
It can do it all, but just barely. Any time your pc is busy with anything else at all, it chokes.
Beyond this point, there's not anything specific that I can offer. Try to find anything that you've added or changed that happens on level load and streamline it as best you can. If you get enough, it'll work. Otherwise, just don't Alt Tab, I guess.