Options?

Dabbles

Im a bit curious, does the dev team plan to add a more fleshed out options menu? As of now I can run the game (Intel HD 4000, I know, below min specs, but can run most games fine) at a relativley low FPS and still have fun, it would be nice though to be able to disable certain things like sunshafts and the like!

Aeroflux

You can already do that. Bring up the inventory (so you can use your mouse cursor) and hit the 'F3' button. You'll find quite a few options to optimize the framerate, even a handy real-time graph to gauge the overall impact of different options.

Racer1

You might get 15-20 FPS if you are lucky and stay out of the high-poly areas.

P.S. From what I can tell, half the purpose of SN is to look beautiful, and that just won't happen using HD* graphics.

Seldkam

^ the game is about exploration, so it will be hard to get the full experience of the game with that kind of rig... but I understand it's a great game and it's great fun to play

Lye

I'm half-hoping this won't be the extent of the graphical optimization. The game for me runs pretty smoothly at 60-70fps on normal or experimental settings, but has this weird tendency to slow down to 20-30 randomly every 10 seconds or so. Also, it seems like sometimes it experiences a memory leak as the game starts to gradually give up the more I play it in a sitting, accompanied by audible pops whenever the chugging starts. Didn't know about the F3 options though, might mess with those a bit.

Seldkam

I'd say unkown worlds can get a lot of bang for their buck so to speak when it comes to optimization... At least with my rigs, I can get a decent amount of fps (over 40) with great visuals on a laptop (granted a rather good one, but certainly not the best). IDK, I think a balance would be best, but I don't think judging what should be done with graphics optimization is fair since it's so early.

Dabbles

The game does actually run at around 25-30 in the open ocean, and I didnt know about the extra options! The game is a wonderful game to beutiful even on minimum so I do bare with the FPS issues.

Aeroflux

Lye wrote: »

I'm half-hoping this won't be the extent of the graphical optimization. The game for me runs pretty smoothly at 60-70fps on normal or experimental settings, but has this weird tendency to slow down to 20-30 randomly every 10 seconds or so. Also, it seems like sometimes it experiences a memory leak as the game starts to gradually give up the more I play it in a sitting, accompanied by audible pops whenever the chugging starts. Didn't know about the F3 options though, might mess with those a bit.

I've noticed this as well, a frame spike that is directly related to freeing ~20MB of memory at a time. 'F1' will show more information, including the RAM in use (GC.GetTotalMemory). The memory behavior is almost like a counter in the way it accesses the RAM. Once it gets around 800-1000MB it starts purging. That's when I get a frame spike from ~100+ FPS all the way down. The spike is big enough to escape the top of the screen on the frame graph.

Is there a guide anywhere for getting into the nuts and bolts of the settings? I watched a youtube video on a prior version, which was a bit more straight forward than the current. I'd like to get accurate detail on the framerate so I can properly tune the game. Average, lowest, highest, location-based, etc. Being a Rift owner, my interest is in keeping at least 75FPS locked in VSync (said to be coming soon).

Also, out of curiosity, will the devs be able to integrate a motion to photon latency feedback counter using the built-in tester from the DK2? That would help Rift users quite a bit.

LumpN

Unity games are written in a memory managed environment. That is a huge problem when it comes to performance. We do our best to mitigate the fact that Unity pauses the game for a short while to clean up unused memory. Sometimes we add a lot of new features to the game and performance goes down. Then Steve puts on his wizard hat and optimizes the evil out of Mordor until performance is good again. But evil always finds a way. It's a cycle. More or less.

Aeroflux

Ah, so that's what it is. Thanks for the explanation. I shall now refer to this bug as the "Eye of Sauron".

Racer1

Most managed engines/virtual machines have the technical ability to allow developers to micro-manage memory usage. However, these engines inexcusably hide that ability behind a wall of academic idealism in order to "protect" the engine and/or the developer from their own mistakes, and to make development faster. Even when some freedom is given, the interface is often course-grained and inadequate to make it worth the effort. The irony is that an inordinate amount of code must be rewritten in order to work around the limitations that were put in place to make the code easier to handle in the first place.

There are many cases where even the freedom to control just a few large grained objects at a lower level can make a huge difference with regards to real-time performance. Alas, building a reusable object pool (or similar) seems to often be the only way around these limitations, which again adds more complexity to what would otherwise be a simple use case.

LumpN

Unity actually blocks all the micromanagy circumventions to the automatic memory handling. So in this specific case there is very little we can do other than not allocate memory in the first place. Isn't that ironic?

Automation, frameworks, and virtual machines are nice and all that. You'll get much more done in fewer time which is great. Unless your project either reaches a significant size or you care about performance. In those cases you'll likely find yourself fighting the system more than reaping benefits from it.

I look forward to the day Unity uses a non-blocking garbage collector. It's not impossible. IBM made one for their real time Java system. @Unity if you read this: screw everything you have in development and do this instead. If you can get the garbage collector right there is very little reason not to use Unity anymore.

Racer1

So an object pool isn't an option? I understand it adds to the front-end work -- but once that is done and the objects exist, you can do whatever you want with them (i.e. keep them around to be used in the future by a different instance). You make the pool initially use the built-in GC, and add enhancements to keep them around later. The only problem with this is if you have too many disparate objects that cannot be reused.

SteveRock

of course we can take steps to eliminate/reduce garbage, such as by using pools, but that takes work and time. so we have to weigh these tasks against all other tasks we have currently. by my latest audit, GC spikes were not too frequent, but I will be taking another look soon and fixing the biggest offenders.

ezekel

my only hope for options is field of view, to me the single most important option in any video game

AceDude

@ezekel‌ I'm working on it