Large flight deck, wierd 3d strangeness in-game, and...

#1
A Medusa handles like a Pegasus.

Today I decided I'd download the FreeSpace Open, just about every campaign I could, and the FS Port with Turey's installer. Unfortunately they didn't like my new computer, and instead of settling in, thought that they should make my life hell. I'm just here tto ask for a bit of help, please.

Case #1- The over-zealous 3D engine.

For some reason, and this has never happened to me on the old PC, Static objects tend to move when I alter my field of vision, or at least the background does. For example-

(These figures are for example only, and probable wouldn't give the same result, so don't take them as fact) Let's pretend that in my sight there is a Crate in front of me, a TC-TRI. When I look dead-on, straight forward at this crate, I cannot see the bunch of crates a kilometre behind it, as it eclipses them. However, when I turn my ship downward, without actually moving in relation to the TC-TRI, and the TC-TRI is in the top of my HUD reticule, I can see the other crates poking out from above the TC-TRI. Also, the Targeting 'Bow' that normally encompasses the TC-TRI is now above it, moving further away the further from my centre reticule the crate moves, almost as if all objects are behind what I am looking at, and rotating about a point at it's centre.

It's very strange, somewhat offputting, and I could probably get a video with FRAPS or something if you want to see first-hand.

Case #2- Attack of the pixelated flight deck.

This is a fairly mundane problem, I think brought on by my new, rather large monitor. I am running FS2 and the Port in my standard 1900x200 resolution (I have a lovely 24" monitor now, which craps on my previous 17"), but for some reason (especially on the port) the flight deck seems incredibly pixely, as if the computer has taken a 640xwhatever flight deck, and gone- 'Oh dear, this simply won't work' and stretched it across the monitor, making that whatever in the top left corner indistinguishable from that thing in the bottom right. A less extreme version of the problem seems to be occurring with the FS2 flight deck, but It may have simply been that the image is a lot larger than I remembered, but at perfect resolution, and I am not yet used to it.

Case #3- The unexpected

Change in handling that I get when turning. I was playing through one of my own created missions, a particularly large BoE mission, that I was using as a test of the performance on said new computer. It passed easily, but somehow, where as my Medusa bomber handled like a Medusa at the begining, it was turning like a Pegasus, if not faster, my head hurting from the sight of the stars creating huge lines in my view as if I was turning at near light-speed.

I don't remember any of these things from when I had the SCP installed on my old PC, or even in retail FreeSpace, nor do I want to, so please think about these problems and how to fix them, or forever mourn the waste of time reading this post.

Thanks for reading!
'Memory and imagination are but one thing, which for diverse considerations, have diverse names'
¦- F R E D E N T H U S I A S T -¦

#5
Offhand, have you tried this with the FSOpen executable set to single-processor affinity?
No, would that help? And how could I do that?
'Memory and imagination are but one thing, which for diverse considerations, have diverse names'
¦- F R E D E N T H U S I A S T -¦

#6
Press Ctrl+Alt+Delete (task manager) go to processes, find the line that starts with your FS2 Open executable and right click it and choose "Set Affinity". Then, uncheck one of the CPU # boxes and then press OK.

Though I'm not sure how that will help.

#7
Sounds to me like at least some of that is caused by using wide screen. That bug *has* recently been fixed, but I don't know in which builds you could find it. Try looking on HLP?
Would 3.6.10 work? As opposed to creating moar problems?
'Memory and imagination are but one thing, which for diverse considerations, have diverse names'
¦- F R E D E N T H U S I A S T -¦

#9
oh and, the fsport does that. nothing you can do about it.
╔╦╦╪╦╦_
╚╩╬╪╝╞╧╩╪╦
Now what am I supposed to put here?

#10
Press Ctrl+Alt+Delete (task manager) go to processes, find the line that starts with your FS2 Open executable and right click it and choose "Set Affinity". Then, uncheck one of the CPU # boxes and then press OK.

Though I'm not sure how that will help.
Might be no use atall, I have no idea how the game handles multi-threading on 2+ core systems. But I think it's possible you could get funny effects from having threads on different processors due to the timing differences.

#11
Well it supports it but doesn't take advantage of it last I heard. So it'd probably make the game slower since the thread is moving between the two cores all the time.

#12
Well it supports it but doesn't take advantage of it last I heard. So it'd probably make the game slower since the thread is moving between the two cores all the time.
I don't know. I have no idea how FSOpen or C++ programs in general would handle multi-cores, but one thing I am pretty sure is that, internally, there will be multiple threads to do different things. How or if that can be split to have these threads executing on different cores (rather than time-slicing) I'm not sure.

#13
Actually the trick is splitting the main process up into those threads rather than getting them to execute on different cores.

In fact for most things in a game it's incredibly difficult to split stuff up most into separate threads, and you'd need to design it from the ground up with that capability in mind - something that FS obviously wasn't built with. ;)

There are articles floating around the net that describe it better, but essentially the problem is where the results of two or more processing threads potentially conflict - say, the AI thread wants to make the character recognise the player this frame, but the gameplay thread says the guy has just been killed by the player, while the physics thread says his body has been hit by a car object.

How does the game decide what to do with all that info? All the threads have used processing time to get to that output, but at the very least the AI thread's processing was wasted, because he's dead. What happens if the physics thread reaches its output much later than the other threads? It's just huge piles of little issues like that.

Note I'm not saying it can't be done - in fact once engines figure out good techniques to use parallel processing efficiently it will result in massive performance gains on multi cores, but the complexity of the task is what's currently holding it up. Most multi core games currently use one core 100% and a second core maybe 5% or so depending on the game.
Twisted Infinities

#14
Actually the trick is splitting the main process up into those threads rather than getting them to execute on different cores.

In fact for most things in a game it's incredibly difficult to split stuff up most into separate threads, and you'd need to design it from the ground up with that capability in mind - something that FS obviously wasn't built with. ;)

There are articles floating around the net that describe it better, but essentially the problem is where the results of two or more processing threads potentially conflict - say, the AI thread wants to make the character recognise the player this frame, but the gameplay thread says the guy has just been killed by the player, while the physics thread says his body has been hit by a car object.

How does the game decide what to do with all that info? All the threads have used processing time to get to that output, but at the very least the AI thread's processing was wasted, because he's dead. What happens if the physics thread reaches its output much later than the other threads? It's just huge piles of little issues like that.

Note I'm not saying it can't be done - in fact once engines figure out good techniques to use parallel processing efficiently it will result in massive performance gains on multi cores, but the complexity of the task is what's currently holding it up. Most multi core games currently use one core 100% and a second core maybe 5% or so depending on the game.
That's an hardware resource allocation issue there, though, rather than a software structure one, though. There have been well-established rules for handling this type parallelism (synchronization primitives, semaphores) in all software (and hardware, i.e. deadlock avoidance in pipelining) for decades, because you don't want to have games (especially) single-threaded (imagine if they were only updating the 'world' everytime they redrew a frame - !). Not to mention real-time systems, of course. OpenGL, for example, should really use a seperate 'drawing' thread seperate from other threads (which themselve require synchronization).

Actually, thinking about it, it's absolutely necessary to thread games, because you have bottleneck sources in waiting for hardware.

It may not be a solved problem, but it's certainly one with known solutions (related link: http://www.gamasutra.com/features/20051 ... b_01.shtml).

The issue is not threading itself, it's load balancing. On single core you simply (!) control the priority each thread gets when being time-sliced, on multicore you can have proper real-time (but if windows does that automatically - which is something I'm not sure of - then it might not do so optimally).

EDIT; clarification - I'm 99% certain that even games designed for single-core will use threading, even if just to isolate display or memory related bottlenecks from the logic code. Certainly it's how I've programmed stuff in Java, although I don't know how the JVM manages these threads in terms of placing them 'on' resources.

#15
That article is a good read - I've always found the whole concept and implementation of parallel processing fascinating. :D
I was aware of the existing parallel processing in video (and audio) rendering from reading all about SLI/crossfire techniques, where the GPU input from the CPU basically consists of "stuff to draw next", and multiple GPUs can take alternate sets of instructions, but I wasn't aware of those finer programming related points. Stuff about deadlock avoidance, bottlenecks and resources etc. Things to look into anyway. :)

I'm learning C in uni this semester, so hopefully that'll sort at least a bit of it out. I'm doing a mechatronic engineering course at uni, so I expect I'll need to know this stuff to build the robotic legions of do-....granny helper devices I have planned.
Twisted Infinities
Locked

Who is online

Users browsing this forum: No registered users and 93 guests

cron