A problem that has bugged me with co_moira might have been almost solved now. I'm hoping anyway. So far one person has been able to confirm it for me, and that seems promising.

What happens, if you've played my map, is you walk into the giant pit room (the atrium) some users experience a large drop in fps. This has been there since the first released version of my map. It's a large room, r_speeds hit just short of 900 in a couple specific spots, but for the most part it's around 6-800. There is no dynamic lighting inside it. And over the versions, I've cut entities, particles systsems and wpolies out of that room again and again. I used to experience the drop myself on my old computer, but I don't see a hint of it at all with my newer machine (running on the same videocard I should add!)

Today I had a bit of an epiphany, what if it's the one lonely sound I have in the middle of the room? I never paid much attention to the file it plays. It's scaryambience.mp3, a 900kb file found ns/sound/ambience. When coming into range of the sound, that's when the fps would drop.

I had a friend who experienced the problem swap the names with b1.mp3 (a similar, though shorter and smaller sound) and the result was 30-40 fps became 90ish fps for him. A significant difference. Future versions of the map will use the smaller sound for sure. (I'm still looking for more confirmation on this from other people, but if just one more person is fixed, I'm quite pleased for the moment.)

Now this is still strange to me, that it was a problem at all. I'm sure scaryambience.mp3 is used in other maps. My old computer had a sound card, this one is onboard sound. At first I thought maybe it's overlapping another sound somewhere, but upon looking, I don't see any should be overlapping that much area. (Besides, early versions the sounds were unnamed, and the "overlapping sound not playing if it has no name" bug resulted in me spacing sounds fairly sparsely in early versions.

Rebirth had an fps problem for some people, but I never saw it (I had my old computer back then), or at least I didn't notice it. Prometheus, which was part of the beta, I heard had a fps problem (I had my new computer for it so I really didn't notice any fps drops). I never understood one thing though, was why prometheus, a nice looking map in it's own right, but not nearly as r_speed crushing as ns_machina, was getting more complaints about fps. (Your mileage may vary here, this was what I was told, I might be off track with such a claim so don't quote me!) Anyway, I got to thinking about it some more, and one thing my map and prometheus do have in common is we both include very large (relative to the default ns ones anyway) custom mp3 files for our readyrooms.

Anyway, looking some more, ns_lost apparently includes a huge custom mp3 for use in it's hives (though upon playing it, I don't recognize it... is it used in the map?) Nancy includes a large custom .wav (you know which one I'm talking about) so I wonder if .wavs are handled differently than .mp3s?

So would having large music files in memory cause problems when other sound files start playing? Anyone else with more experience on this sort of problem? Am I just running off with conspiracy theories here?

Only difference I guess there is, mp3 needs to be decoded and wav can simply stream. Yet that is hardly a threat to 500mhz+ pc's (probably even lower and it still wouldn't be a threat when running a game)


I just had a look at the pit, and I see something which seems out of place. Go down and look for a tiny yellow lit triangle. It looks malformed to me, perhaps this is also linked to the problem... And I've also seen a left over spotlight prefab above your RR

shotlink

It seemed to make a pretty big difference for at least one person now. I'da never thunk it to be sound related. My old computer was a 1.4ghz p4 and while it wasn't as huge as this persons was, the drop was still a noticeable 10-20 fps or so.

And as far as that triangle goes... Hmm, how'd that little bugger get down there? Not to worry, I've already redid the geometry at the bottom of the pit to clean it up (the oldest part of the map and it shows when I looked it in hammer) and spare a couple of wpolies. And the lamp above the rr... yeah that was supposed to just sit there, but it wasn't supposed to still be a func_wall! Thanks kouji! Btw, what program is that which you took that screenshot with? BSPviewer?

For reference, the reason that triangle is yellow, is I do all my base brush work with a texture that looks like this:

I based it on one of the halflife "fifties" checkerboard floor textures. I then gave it a very bright yellow entry in my rad file.

I find doing this be quite beneficial:
a) Depth perception in hammer, and if I'm testing a piece of geometry out.
b) Helps me find little "pockets of air" in the map while I'm testing. (Particularly after I mix new architecture with old stuff. Mind you, I'm starting to get better with my work, less random blocks floating off in the middle of nowhere and that sort of thing!)
c) When I do a final compile, I should simply replace that texture with the null texture just in case I missed anything. I forgot to do this with that last release.

And now that I think about it, even going back to when I was first learning how to cut a hole in the wall in hammer, I was using that halflife checkerboard texture, so I guess the habit just stuck with me!

Heh no prob.

It's called Objectviewer, it's part of the Crafty pack --> I used X-ray mode, lots of things can be revealed with that mode...