1.62 System Requirements?

[FlyingBlind]

I've been playing v 1.62 for a little over a week now, and have noticed that sometimes the animation redraws tend to hang for a second, as in maneuvering during combat with multiple pirates, or during the white flash of a ship exploding.

Never one to rule out "Operator Error," I thought I'd mention it here to see what I might be doing wrong. I'm running 1.62 binary on a Powerbook G4
with 1.67Ghz processor and 1.5 Gb RAM. I use an external flat screen running at 1280x1024, 75 Hz. I have no OXP's installed, (but not for long), and when I play, my beta test habit of shutting down all other applications is the modus operandi.

Surely I'm not overtaxing the system here?

Thanks for any help.

Dan

[TedJ]

Your specs should be plenty good to run Oolite... one of the regulars here is still running on a mid range G3.

I'm personally running the linux build on a P3 866 with 256MB and an old GeForce4 card; aside from an intermittent bug causing a memory leak, it runs well.

[Rxke]

A whole second? I'm running Oolite on a G3@350 MHz,384Mb, and have little hangups too, but they are fractions of a second, when the engine loads new textures. Maybe you have some systemsettings that let your Hard Drive spin down?
Also when there's a lot happening, the game tends to slow down, but that's the collision AI struggling, I often get down to 4fps in such cases (4fps is the minimum, in practice it can run slower, but it will still show 4fps.)

OTOH, I do think 1.62 'micro-freezes' more than the previous builds, I originally thought that was because I had the GMail notifier running, disabling it helped, but not much...

[JensAyton]

Collision detection is not AI.

Collision detection does struggle when there are a lot of entities, but not appreciably more when those entities are close to you; that is, for the normal usage of “a lot happening”, collision detection isn’t really the issue.

[Flying_Circus]

Here's an off-the-wall suggestion: are you running from somehwere in your home directory (like straight off your desktop) with filevault enabled? I've never tried doing that, but I'd guess that unzipping a texture under such circumstance could lead to a significant hang, even on such a system as yours.

[FlyingBlind]

Sorry about my inaccurate mention of the delay time. It does hang for less than a second, possibly 1/2. I'll be more observant of that when it happens again.

After posting last night, I did see comments about turning the Gmail notifier off, which I plan to do at my earliest opportunity.

At present, Oolite is located in my "Applications" folder on the hard drive, and not running from the desktop. I hadn't considered any filevault connection, but I'd be willing to check it out. Thanks, all, for your thoughts.

Dan

[winston]

It's probably loading textures. The PowerBook, being a portable, has a low power low RPM hard disk at the expense of disk speed. I only occasionally get a percetable pause on my desktop system, but on my G4 powerbook, I get a very brief pause (nothing as long as a second!) whenever a texture is loaded.

There are several implementation methods that could get around this:

1. Accept you're going to eventually load all the textures anyway, so preload them all (certainly the default game texture).
2. Load them on a different thread, so you don't block Oolite's main thread while waiting for a texture to come off disk and get uncompressed.

(2) would be the most fraught implementation, though.

[FlyingBlind]

Winston,

That makes a great deal of sense. The preloading of textures sounds like the solution here. I'm also looking for info to compare the speed of my laptop's drive to a 250Gb outboard drive I keep for storage of video projects. If it is indeed faster, I might try running Oolite there via firewire.

Back to preloading. I haven't gone into the file structure before. Where/how would I proceed to preload the textures? Thanks for your ideas.

Dan

[JensAyton]

I’ve already implemented async loading of textures, but that implementation was a mess.

I’m working on a new material system with mip-mapping and general Shiny. Loading will be asynchronous by default, although I’ve stuck some disabling macros in in case it goes boom under GNUStep. I’ve currently got inter-thread communication problems, but they’ll go away at some point. (This is my displacement activity for sound bugs…)