The game engine just seems wasteful and inefficient

While you have a fairly solid post there, please do not spread this particular misquote. Or rather, please use the *entire* quote. It's incredibly deceptive otherwise.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" - Donald Knuth

Emphasis on small efficiencies. And when it comes to the double/float thing, you are dead on. It's a small efficiency, and it's not worth arguing over. Period. When it comes to multi-threading - that isn't an efficiency - that is a basic design tenet. Either the code supports it or it doesn't. Going back and updating the code to support it is very much not ideal, and should infact be handled up front. At this point, that may not be a realistic option of course, since the damage is done. That's the one point I'll grant the OP.

Beyond that, float/double/int/whatever - none of that matters. Proper rendering, proper world loading, and multi-threading is what will make or break the game.

And for those of you who know me from Minecraft, you might know that I'm somewhat of an efficiency freak.

 

I'm a 3D artist so I don't notice it as much since multithread rendering has been around for ages. You are right, but I would argue that lack of multithreading has a much more impact on games than most other software.

 

The game actually multi-threads pretty well on our server, making use of all 8 threads (4 cores). The main performance issue atm is that memory is not getting released, there is no garbage collection it seems. When players log out, their portion of the memory remains, and when they log back in they even get assigned new memory. You can imagine how quickly this will escalate, causing the memory usage to go up constantly. We think it's also this issue that is responsible for the climbing CPU usage.

 

"Relevant" information you assume is correct because it's presented with an air of authority?

I know I don't know enough about programming to make any judgments on the coding critique. But I do know a little about arrogance and that's what the OP rings of to me. Less "why would you do this, would this other way be better" which would be helpful. More "look at me, I know stuff and you did it wrong" even if it is an educated guess, it's still a guess. There could be reasons for using the style of code that CF did that the OP isn't privy to. On the other hand, my observation could be simply "tone trolling" and be ignored entirely. It's largely subjective.

The OP may also be right and could have emailed or PM'd his observation without leaving us morons to comment ignorantly on it.

 

If you have nothing to add to the thread then please don't even bother posting, some of the guys here are willing to discuss the issue in greater detail... just let them be, okay?
There's no need to be snarky and negative.

 

I would have to say that when I play a game with 16bit-esque graphics and I'm running on a computer with a 6-core processor with 1GB of RAM and 1GB (I think?) GPU, something that can run something like Warframe at 60FPS+ full time with the settings all turned up, I should not be getting FPS drops in Starbound.

Sometimes I'll pick out 9 dirt blocks and they take 3+ seconds to move from where they were, to being 'sucked in' by my character. The game takes a HUGE FPS dump when I go from "Underground" to "Surface" (that very specific depth where the overworld theme starts to play, or when it stops playing and the quiet "wind loop" sound plays).

I go from 50-ish FPS down to 10 for a couple seconds as the game seems to struggle to swap background music tracks. And if you jump up and down, you get said FPS drop every time you do; the game doesn't load the BGM once, it loads it every single time you pass through that 1-block depth line. If you happen to be mining at that exact depth line, the constant FPS drops and stopping/starting of the BGM is highly annoying.

I realize the game is in beta, but damn. Something needs done with optimization. A computer this powerful should not be struggling with a game that features SNES-quality pixel graphics (This is NOT a complaint about the game's graphics; I LIKE them because they remind me of old days).

EDIT: ALSO, large NPC structures come with absolutely HUGE FPS drops. HUGE. Like < 30 FPS fulltime in those areas.

 

As a programmer, I do tend to agree with the OP.

But now a days, processing & memory is cheap so... I don't view this as a huge issue.

 

I respect thee oh wise programming wizard.

 

Your post was very informative, thank you for posting this information ^_^.

 

Maybe you can show the profiling results

 

As a moderately related sidenote, since this thread is one of the few regarding the game's actual programming, I have a question.
To all you more experienced programmers out there that have taken a look at Starbound's innards as much as it's possible - to you, what seem to be the biggest actual bottlenecks in the engine currently? Or is it impossible to access enough information on it to make deductions on that?

I'm a beginner programmer and these kinds of threads in game forums are always an interesting read.

 

First of all, telling people not to reply with It's beta/ it runs for me isn't going to stop them. Just watch

It's beta and it runs fine for me.

Now I understand complaining about optimization is reasonable but it is not needed. The devs are aware of the issues and plan on doing the optimizing later in the beta as they are adding new content and fixing things here and there. People have complained plenty about the state of the engine which you could have found out using the search bar. One more thing, this is general discussion and I'm pretty sure this would be better suited to somewhere else, like an email to the devs. Thank you for bringing your well known complaint to the forums already swamped in complaints.

 

I haven't taken the time to read through this whole thread, so I deeply apologize if it has already been mentioned. That being said, I would like to point out that it does state on the "how the beta will work" page that in this phase the game engine won't be optimized yet.

 

Even if the devs don't read these points, I'd like to give you a moment and thank you for the tips on behalf of my own future.

I've never even thought about these things.

Thanks!

 

I don't necessarily agree with the minor points of the OP, but I do agree with [what I perceive to be] the overall premise, that abundant hardware resources is no reason to be inefficient or wasteful.

 

Most of the things mentioned here are things you don't have to work there one day even to fix. Especially the high precision things can be fixed in a very short amount of time.

The constant updating, and bad multi-core functionality are a bit worse to fix, but still doable.

I think mainly OP's point here is that the devs have obviously never thought about optimization ever. (as can be seen in the prevalent double precision floats) He is basically just pointing out that optimizing a bit now would be a good idea, and that it is not that hard to make the game run much smoother.

 

Most of the things mentioned here are things you don't have to work there one day even to fix. Especially the high precision things can be fixed in a very short amount of time.

The constant updating, and bad multi-core functionality are a bit worse to fix, but still doable.

I think mainly OP's point here is that the devs have obviously never thought about optimization ever. (as can be seen in the prevalent double precision floats) He is basically just pointing out that optimizing a bit now would be a good idea, and that it is not that hard to make the game run much smoother.

 

I have no experience with programming but I do however wish to say this: people are throwing around "beta", "it's beta" (myself included). And in many respects that is completely fair! But the fact that the engine might be flawed to a certain extent might get pretty ugly in the long run, and in my opinion is something that should be prioritized (I can only think of one analogy here and that's bf3 netcode). Again, no experience here, just throwing an opinion out there that may make more or less sense. In a nutshell, what I'm trying to say is: smooth gameplay and solid mechanics before content (for me at least) any day. Interesting discussion, I wonder what the devs think about this.

 

I have atleast to disagree with those Points you have mentioned. Using float Point calculation for such simple stuff are really nothing for any CPU.

High complex stuff like AI or 3D calculaions would drain resources pretty badly if done wrong. Just because you use float Point calculation doesn't meen that you have to use the full range. You just reserve Memory for a given range. Also if you Count this stuff together you won't get that much reserved Memory. What's a couple of bit reserved Memory for a let's say a thousand or even ten's of thousand different things? Really it's nothing to mention.

What i have to say is that your thread title is very negative without any prove of concept because those simple things really can't back it up and it seems just like some generalization what is highly unfair and not correct.

So please provide atleast some some sort of evidence that really matters.

For a fact we can say that the whole universe isn't permanently loaded or used for calculation. Maybe just the part where your character/characters in multiplayer are currently.

I'm just a simple programmer and those at chucklefish are professionals. Every pro game programmer knows the bits and pieces and where it matters to optimize stuff or be carefull about it. If you have the slightest clue about game programming you would know such Facts.

 

I'm aware this post is trolling but i'll reply anyways.

CPU's have been good at Floating Point for a very very long time now.
http://stackoverflow.com/questions/2550281/floating-point-vs-integer-calculations-on-modern-hardware
O hey, look at that, FP is faster than integer math for mul/div...
Did you know that directx and opengl are fully floating point...
Starbound isn't very math heavy at all, most of the processing goes into queries for things like collision detection and our semiraycasting lighting system, which doesn't map at all to the SIMD style systems available in the GPU.
Floating point is _not_ a lazy option, using floats gives you all kinds of problems, the lack of absolute precision means that anywhere you do an equality comparison you might already have made a bug.
Health is stored in 8 bytes, whoop die doop, not using integer values allows us to do all kinds of status modifiers that give fractional boost.
Converting between double and single ? it might happen at some points, using double in calculations reduces precision loss, the cpu does ALL FP math in 80bit precision anyways before truncating to doubles for storage.
Most engines are incredibly serial for their mainloop, the game is made for multiple cores, in single player the planets run on different cores, asset loading and processing is also threaded, some of the more heavier operations are also done on a worker thread.
At the same time it still needs to function on lower end machines where a multithreaded architecture actually reduces performance. The recipe list thing is buggy ? news to me. Putting it on a worker thread has been a todo for a while, but you can imagine that it hasn't been our top priority ;p
The current build of the game isn't super optimized cause there was a deadline to make, it also started out with far more bugs than we have right now.

On the note of it being bad to be wasteful, optimization has no limit, you can always keep optimizing, rewriting the engine time and again, to get a few percentage points each time, that is not our goal.
We want to make a fun game that runs well enough, if that means fully loading your cpu and filling your ram, i'm fine with that.