Hello again, Will and Steff,
regarding the steep decrease in PSX frame rate you are reporting (I am assuming this is the frame rate as indicated by PSX itself):
But PSX runs at about 25 fps (down from 72 fps), and the moving map tends to magnify PSX movements. Like if PSX makes a minimum radius turn on the ground at 3 kts (per GS display on the ND), then the Whereamium map shows a turn with a much increased radius, maybe 10 times as large
My greater problem is that I still get just 20 fps since I tried to use Wheramium yesterday.
As far as PSX is concerned, Wheramium is strictly "read-only":
¤ The PSX Boost server pumps data out as it always does (at the frequency set in the Preferences, e.g. max. 73 fps),
¤ Wheramium (PSX client part) reads them at user-defined intervals (POLLINTV in the INI file)
¤ and the webpage fetches (requests) them from Wheramium (webserver part) at other user-defined intervals (REQINTV in the INI file).
At no point does Wheramium
send anything to PSX, let alone try to
control any of PSX settings or behaviour.
So if the fps go down, the only thing I can think of is that running Wheramium (over)loads the system (CPU or possibly graphics card, etc.) so much that PSX is slowed down far below its set frame rate limit.
If and to what degree this happens is of course highly dependent on the hardware, the operating system, and the general system configuration.
But with current boxes, I find it difficult to see how Wheramium can force the fps value down from ca 50 or even 70 to ca 20 or even lower, just by putting extra load on the CPU etc.
Things which were good to know:
¤ When exactly does this slow-down happen?
¤ As soon as Wheramium is started (but
before the webpage is loaded in the browser)?
¤ As soon as the webpage is loaded (but
before it is connected to Wheramium/PSX)
¤ Only
after the connection is made (and the map is now actually being updated constantly)?
¤ Similar: At what point does the frame rate
go up again (
if it does, which is not the case for Steff).
¤ Also: try to vary the REQINTV and POLLINTV settings. making Wheramium fetch and process the data at large intervals,
e.g. POLLINTV=200 (data read from PSX only 5x per second),
and REQINTV=500 (data requested by browser only 2x per second),
The map will then stutter badly of course, but the point is to see if this relieves the CPU and thus helps with the slow-down of the PSX frame rate at all.
Finally: a test.
(I am aware the situation may be overly "favourable" for Wheramium (i.e."best case"), but it should be on the ground (because of the taxying problems reported by Will), and it should use a SITU which is the same for all of us. Feel free to suggest other situations to test...
¤ load the situ "Basic 004 - Cleared for takeoff.situ" which comes with PSX.
¤ start Wheramium (if possible from a Command Prompt, to see any error messages)
¤ load the webpage for Wheramium
¤ (
optional: open the browser's Dev Tools so you can monitor any error messages on the webpage side, and perhaps also the GET requests)
¤ connect webpage to Wheramium/PSX
¤ zoom out until the coastline/surf becomes visible at the left edge of the screen
*¤ check that the "heartbeat" indeed shows activity (numbers changing), and that the correct coordinates are displayed
¤ in PSX, unlock the parking brake
¤ in the Instructor (Situation > Position > TAS field) set a ground speed of 12 kn
¤ let her trundle down the (extended) runway with throttle at idle (speed will increase anyway by a few knots, it's a 744)
¤ take the first exit to the right (shortly before the actual threshold)
¤ roll on to the apron and do some more turns etc at your discretion.
On my box, during all of this exercise, I never saw a PSX frame rate less than
73 fps. I took the turn (and some more on the apron), somewhat boldly but intentionally, at 19 kn and had no issue with the turn radius. Also, frame rate was still not affected (although turns always generate higher loads).
I didn't even see a major increase in CPU temperature (which perhaps indicates the test is indeed too "harmless"??
)
Obviously, YMMV.
Will: If I understand correctly, you are seeing these wrong turn radii
only on the map but not in PSX itself?
Which would mean that map movement and PSX are actually not in sync?
This is strange: what I would expect (if the map lags behind the actual movement and cannot catch up) is that it
jumps, but even then it should not be able to put the marker to a position which is
different from the PSX one (although perhaps delayed).
In other words: instead of a smooth arc, the marker would describe a kind of "polygon", jumping from one corner to the next, but the
radius should still be the same, and those marker positions which are displayed (even if updated at large intervals) should still be in the respective correct places.
Cheers,
Martin
* I realise only now that the zoom value in the webpage display should have more decimals; only one decimal is not informative for the lower range.
(It used actually to be 4 decimals during development, and then I overcorrected...
)
