Oolite Bulletins

JazHaz wrote:

caracal wrote:

Maybe I'm wrong, but ... if it were graphics-related, wouldn't it drop off noticeably when I was in-station, when the only thing being displayed was a page full of the price of furs?

But when you are in station, things still happen outside. Ships still fly about and attack each other. ... Try pressing Shift-F before docking, and watch the FPS/Objects counts change whilst docked.

Right, and I have checked the framerate in the past, though hadn't with 1.73.4. I did it just now, got some interesting but not surprising results:

I ran a launch-witchjump-dock sequence through two different systems, got basically the same results both times.

• While sitting in the station, around 60 FPS, plus or minus no more than 3, very steady. Same when I was outside looking at nothing but stars.
• After launch, while the planet and nav buoy filled my screen, around 30 FPS, with occasional jumps to 60.
• After pitching up so I miss both the planet and the buoy, with the planet now about 25% of my screen, back to 60 FPS. Same when I use the rear view to watch the station recede behind me. More variation now, though, plus or minus 5 to 7.
• Closing in on the next station, 60 FPS when looking at either the planet or the station. Closer to 30 when both are on-screen.
• When (manual) docking, when the station fills my screen and beyond, back down to 30 FPS. Once I get very close, it dropped to around 18, which explains why I am seeing the jerkiness when docking at a constore. Don't notice it at the main station because I'm normally lined up very well, no maneuvering needed.

So, not great, but not bad for a cheap on-board nVidia graphics chipset, and more than good enough most of the time to make the game very smooth and playable, as well as visually satisfying.

And it's interesting to note that the FPS value, as expected, varies immediately and directly according to the complexity of the scene being rendered. Updating the various goings-on outside the station while I'm inside has no graphics impact, and I imagine requires only a modest amount of CPU cycles. And at no time did my CPU usage change more than a few percent up or down, regardless of the reported framerate. Also as I would expect with mostly hardware rendering.

JazHaz wrote:

That's why you occasionally get calls for help etc.

Yes, whenever I see those plaintive maydays or hear the buzzing of an ECM system, I always think, "Oh my, I should rush right out there and rack up some more kills help those poor souls!"

JazHaz wrote:

caracal wrote:

Nice to see such an energetic and constructive new hand has joined the commOonity!

I do what I can, can't code or draw for toffee, but can make wiki pages!! Glad someone has noticed!

We each do what we can, and I know that every contribution is welcome. We can't all be coders, nor would we want that, else we wouldn't have things like the glorious artistic Griff ships, or your wiki pages, and so on.

And yes, I noticed you on the forum soon after my return, and it's clear that you're a positive force and well regarded by others. Now quit blushing and go out and save somebody! Or kill somebody, whatever your preference.

JazHaz wrote:

I do what I can, can't code or draw for toffee, but can make wiki pages!! Glad someone has noticed!

I'm sure lots of us have noticed, JazHaz. The Wiki is better than it's ever been and improving all the time. Thanks!

JazHaz wrote:

But when you are in station, things still happen outside. Ships still fly about and attack each other. That's why you occasionally get calls for help etc.

True, but nothing outside is rendered, and there’s no texture uploading going on.

Caracal, I’m not sure what would cause a noticeable increase in CPU load, unless you’re using a debug build for some reason. The first line of the log will say something like “[log.header] Opening log for Oolite version 1.73.4 (x86-32 foo)”. What does it say in the parentheses?

Regarding the severe FPS drops when pirates are around: Caracal, please try to check, by dumping the entire entity list to the log, whether a Griff Moray is within player's scanner range when the slowdowns start. You can check that by doing some math using the position coordinates of the entities as reported in the dump. I have noticed rare cases where the game drops to 4 FPS (in reality it's more like 1, but no less than 4 can be displayed on the counter) when a pirate group appears. Once I drop the bomb, everything returns to normal. My idea is that something in the Moray shader code is doing something wrong, but it would be good if someone else could repeat the test.

Ahruman wrote:

Caracal, I’m not sure what would cause a noticeable increase in CPU load ...

I should hasten to point out that the "increase" in CPU load is between version I'm using now (1.73.4) and the version I used two years ago (as I recall, pre-1.72, built from svn). And I suppose it's possible that it used 50% of my CPU back then and I just didn't notice, or care. I only notice it so much nowadays because I'm now running a little CPU load monitor applet (which I wasn't back then) and because this comp has a rather noisy CPU cooling fan which comes on only when the processor is under increased load. I like to think I would have noticed an app using half my CPU back then, but maybe I was just focused on Profit and Pirates.

Ahruman wrote:

... unless you’re using a debug build for some reason.

I'm using whatever was on BerliOS the week before last.

Ahruman wrote:

The first line of the log will say something like “[log.header] Opening log for Oolite version 1.73.4 (x86-32 foo)”. What does it say in the parentheses?

It says "x86-64 test release".

Honestly, this isn't a serious problem for me. Sure, I'd love to quiet the fan, but that's more of a personal problem than anything to do with oolite. It also roars when I play fullscreen Flash videos and a few other places. It has come in handy a couple times during my own development, too: When I run a test that eats more than an expected amount of processor cycles, the fan is sort of my "idiot" alarm.

another_commander wrote:

Regarding the severe FPS drops when pirates are around ...

Luckily I don't have that problem. Or at least I've only noticed a fairly minimal drop in control responsiveness when I'm very close to objects, and I'm facing them; given its consistency, I doubt if there was a Griff Moray around each time. And I never saw a drop to anything like 1-4 FPS, just a certain jerkiness in maneuvering. I never even noticed the drop (from 60 FPS to 30 when viewing a planet or station up close) that I reported a couple posts back until JazHaz suggested yesterday that I turn on the FPS reporting.

In case it matters, I run with "Shaders: Full" in my configuration. I figured I'd start out that way, then drop back to "Simple" or even "Off" if necessary, but so far it hasn't been. When I first saw the juddering when docking (at a casino, as it turns out), I tried dropping that setting down, but it had no effect. Do docking bays use shaders at all? If not, then no surprise it didn't change anything. If so, then shaders aren't my problem, at least for this comparatively minor and transient irritation.

I haven't seen any kind of change in performance when viewing "just ships", however many there might be. But I certainly will keep an eye out for the situation you described (a Griff Moray is nearby) and will try to gather the data you requested. I know that Linux x64 users are probably in the vast minority here, as we are pretty much everywhere, so if I can help by supplying alternative data points, I'm happy to.

another_commander wrote:

Regarding the severe FPS drops when pirates are around: Caracal, please try to check, by dumping the entire entity list to the log, whether a Griff Moray is within player's scanner range when the slowdowns start. You can check that by doing some math using the position coordinates of the entities as reported in the dump. I have noticed rare cases where the game drops to 4 FPS (in reality it's more like 1, but no less than 4 can be displayed on the counter) when a pirate group appears. Once I drop the bomb, everything returns to normal. My idea is that something in the Moray shader code is doing something wrong, but it would be good if someone else could repeat the test.

I reported a massive slow down on both my Desktop PC (XP 2800+, Ubuntu, 2.5GB RAM, 128MB GF6600 Ultra) and my work laptop (2.6GHz Core 2, Vista, 6GB RAM, 2xSLI 512MB GF9800M GTs) when Morays appear - the work laptop can go from an unshakeable 60fps to 15 fps with two morays on the screen. Griff, I think, said he was going to (and did?) tweak the shader model to tone down the sea effects - but I don't play Oolite much anymore and haven't repeated under Win7 or latest Nvidia drivers or with (possibly) tweaked Moray.

Oolite 1.73.4 on Win XP Pro, E6600 2 x 2.4, 4GB RAM, ATI 3650 512

Just had two Griff Morays, and a couple of other ships on the scan... no drop in FPS at all, steady at 64, even while I was splashing them.

El Viejo wrote:

Oolite 1.73.4 on Win XP Pro, E6600 2 x 2.4, 4GB RAM, ATI 3650 512

Just had two Griff Morays, and a couple of other ships on the scan... no drop in FPS at all, steady at 64, even while I was splashing them.

Like I said, moray v1 killed my system - not had chance to play with latest version - sounds good though from your stats!

A little late, but anyway: Welcome back, Caracal!

Unfortunately that's about the most helpful thing I can contribute regarding your CPU-load observation, except wasn't 1.73 supposed to use less resources than its predecessor? Though that doesn't necessarily mean processor time... As I said, nothing too helpful from here, I'm afraid.

Instead, just another warm welcome back!

caracal wrote:

First, I notice the Fuel Station OXP saying that in 1.73.4 it shows up on your space compass as a "fuel pump icon", yet I still see an "F". I saw a thread that suggested that yes it does, no it doesn't, so was wondering what the real story is. I eventually uninstalled the OXP because I couldn't tell the factories from the fuel stations, and at the time I really wanted to find the factories more.

It's done by using the spawned role linking up with the role used in descriptions.plist to give the compass icon. In the 1.73.4 version of fuel station these got a little out of synch, hence why the lovely little icon got lost.

I've fixed it in the beta for 1.74 (link in my sig below), or else if you want I can check things and PM you what to change to get it working again in 1.73.4 (or I'll update the current non-beta version of the OXP, that might be a better route).

Commander McLane wrote:

A little late, but anyway: Welcome back, Caracal!

Thank you most kindly, Commander!

Commander McLane wrote:

Unfortunately that's about the most helpful thing I can contribute regarding your CPU-load observation, except wasn't 1.73 supposed to use less resources than its predecessor? Though that doesn't necessarily mean processor time... As I said, nothing too helpful from here, I'm afraid.

I just noticed something today, when chasing a problem I'm having with X.org and my joystick and input events, unrelated to oolite except that it doesn't start until I run oolite for a while. But I think the actual bug is in the server code, not the app. Anyway, the thing I noticed was that the standard demo program "glxgears" pegs my CPU at 100% (well, one core, anyway) so it must be something to do with running OpenGL on this system. Not enough hardware rendering, would be my guess. So since oolite only runs up to about 50% (one quarter of my dual-core system's capacity) it's actually doing quite well overall. (But then, I don't sit and stare at glxgears for hours at a time, either. )

Commander McLane wrote:

Instead, just another warm welcome back!

Thank you again. It's great to be back!

Thargoid wrote:

caracal wrote:

First, I notice the Fuel Station OXP saying that in 1.73.4 it shows up on your space compass as a "fuel pump icon", yet I still see an "F".

It's done by using the spawned role linking up with the role used in descriptions.plist to give the compass icon. In the 1.73.4 version of fuel station these got a little out of synch, hence why the lovely little icon got lost.

Okay, so the definitive answer is, at this precise point in time, with what's currently downloadable, seeing the "F" is no great shock.

Thargoid wrote:

I've fixed it in the beta for 1.74 (link in my sig below), or else if you want I can check things and PM you what to change to get it working again in 1.73.4 (or I'll update the current non-beta version of the OXP, that might be a better route).

No, please don't make changes on my account--I'm happy with things the way they are. I will be starting to use the fuel stations soon, and will be switching to 1.74 (or at least a pre-1.74 nightly build) soon, so those two events should sync nicely.

Yesterday I thought of, and quickly coded up, a silly little one-file OXP that might be good for a laugh, except the crucial methods it depends on don't arrive until 1.74. I'm soooo tempted to switch from 1.73.4 to one of the nightly builds just to see if it works (instead of just putting up a comms message saying, "I would be working now"), but I think I want to get a few more (millions of) miles on my newest commander before going off into the jungle. Once I do take the plunge, I'll grab your beta version of FS and try it also.

Thanks very much for your reply, and your offer for action, Thargoid. Your OXPs rock!

All you need to do is edit descriptions.plist. Currently the only entry (compass icon) there is for fuelStation_location which is the generic role for them and not now the role that they are spawned under.

Simply duplicate that entry with the roles fuelStation_station and fuelStation_satellite and your compass icons will change to the pump ones.
I'll upload an amended version later.

Thargoid wrote:

All you need to do is edit descriptions.plist. ...

That certainly seems simple enough. But I see you've already done it and uploaded it, so now I don't have to. I grabbed your latest version, and indeed there are the icons. Delightful! And thanks, both for the change and for the cool OXP.

And just in time, because this commander is now at that stage in his career where he does more than just milk runs.