The game engine just seems wasteful and inefficient

You really know your stuff. Just Shows me that the difference between simple app coding and game making is worlds apart and a league of it's own. Brilliant post and thanks for the small insight ;-)

 

Anything going to happen with the server "memory leak" in the next version(s)?

I mean, "running well enough" is a nice goal and all, but right now the continuous memory eating (and cpu hogging that comes with it) is what's preventing most servers from going big. If you fix that, you could have 200-player servers instead of 40-player servers, because I honestly yet have to run into a server with 40+ players that doesn't lag, and most of them run on very decent machines. Just try it, visit the servers with top playercount in the server list.

It could really bring the game to another scale regarding multiplayer

No pressure though, just wanna know if a fix is planned or not.

 

Yeah its definitly being looked into by several of the team, it is however a sneaky one, we don't even know what is being leaked yet.

 

I'm sure server owners are more than happy to provide you guys with all the information they could gather if that's of any help.

Threads like this one can be useful too to see what different owners experienced on different setups: http://community.playstarbound.com/index.php?threads/cpu-usage-and-multi-core.62793/

But I'm sure you guys saw most of those threads already!

 

i love nerdy posts like the op , they make me smile

 

I love screen names like "saltychipmunk", because they make me hungry

Seriously though, that bit back in the thread about memory being grabbed but not released seems like exactly what my game is doing in singleplayer.. And if the magical Bartwe is still about, I wouldn't mind knowing about how costly the debug infos being enabled is on performance.. Hoping once these are removed/disabled I'll see some improvement

 

I do know that if I play too long, I ALWAYS get Exception Errors and the game won't close itself properly. It won't take screenshots, etc.

But yet if I only play for a few minutes to an hour, screenshots work and the game closes normally.

There has to be some sort of memory leak or SOMETHING going on.

Also, playing for too long, the sound effect when the ship "lifts off" is silent, too until it jumps to FTL, then the sound comes back on.

 

I understand... but any game thats to big can be a problem. If this game was fully released and I was reviewing it, and in the end it really was TO big, I'd note that. Sandbox games are ones you wouldn't delete from your PC anytime soon, after all, you spent a lot of time on your creations.
I fully agree that a fun game is top priority, but if (I'm not saying you are) things are to big where they could be significantly smaller, it would get a lower score from me.

 

​

 

Giggles. No. Just no. Assuming some version of C was used, it was likely in the range of 1.7x10^308. That's massively smaller than you mention, and even then only uses 8 bytes.

Um.... 4 bit integer can range from 0 to 15. Or -8 to 7. 4 billion would require 4 bytes.

As you so rightly mentioned, GPU's are great at floating point operations (FPO) so it really doesn't affect anything there.

Yep, which in most C-style compilers would reduce to less than 3 assembly instructions, and isn't worth considering.

99% of games and applications made today are. They have to be, as parallel processing is ridiculously difficult, especially when dealing with things like graphics and user interfaces, which is primarily how games input and output data.

I'm assuming you're using static in laymans terms here, not programming, and I would love to see the code you're considering when looking at this. It's likely an inlining optimisation done by the compiler, and doesn't reflect the code quality at all, and in fact is speeding up the processing.

What makes more sense? Having the game update at say, 50 times per second, called 50 ticks or tps, and then every tick you're underwater, subtracting 1 from 1000, making you have 20 seconds of time underwater...

or having 50 ticks per second, and skipping 25 ticks where your breath is unaffected, then subtracting 25 from 1000 in one big chunk?

You should be aiming to have the code model as close to real world as possible. The smaller the increments, the better. And at what cost? A couple (literally < 16) bytes. On machines with 4 BILLION available.

Well... yeah. Because they're used all over the place in the memory. Current health is unquestionably stored in one single place in the code, but no doubt it is CHECKED at many places in the code, and in every one of the spots where it's CHECKED, there is going to be either a value or reference passed. For something like the things you mentioned, value will be quicker in 99% of cases and more appropriate (As well as easier to debug) so when you hexdump the memory later, it looks like 11 instances of Player.health, but in reality it's 10 monsters deciding what to attack first.

Have you ever coded a voxel or tilemap based game?

Let's say that on screen we have 80 blocks wide, 50 blocks high. Lets say we keep 3x3 screens worth of data loaded at a time. There's what, 100 different block types (Stone, sand, dirt)? And then say 16 types of variants for each (blue dirt, green dirt) and then 2 locations (fore and background), and each block has a damage value for how much 'health' it has when it's broken, lets say that's another byte

Keep in mind this is ONLY loading the current neighbourhood of the character. Which isn't the case. It seems like a much MUCH bigger proportion is actually being loaded.

So... 80x50 blocks, x 9 regions on or near the screen. That's 36,000 blocks. We need a byte to determine each block type, and another 2 bytes for variants / data. Let's call it 4, because I've aimed low on block types.

The array of JUST blocks, on the screen and 8 screens around the player, is going to take up 128k JUST IN ARRAY DATA.

Those blocks? each one has a 16x16 texture, probably png-8 or 24, but let's use 8 to keep it small. With texture atlasing, we're going to have all variants of each block currently on screen kept in instance memory on the GPU. Assuming 16 variants for each, and a worst case scenario of 100 different blocks on screen, thats 1600 x 16 x 16 x 8 bytes of block textures. That's 3 megabytes, assuming a static collection and the blocks aren't changing. Because then you've got to adjust and have copies of the list. There's 4MB of data there. 4MB that changes everytime you run more than 100 blocks across the screen.

And all this is just blocks. What about the thousands of items available? I completely forgot / ignored lighting and shadow data. The monsters, their AI and pathfinding, Every single character of text is another 4 bytes, and I'm betting a majority are kept in memory, to avoid having an IO call made whenever you mouse over an item....

Oh, mouse. The GUI. Every gui in the game likely takes up a decent chunk of memory too. A LOT of memory.

Ahahaha... Oh wow.

No kidding? each sprite is an entity, with a position, rotation, velocity and at least one value for light amount and another for light colour (likely 4, one for each vertex, which will likely end up as 6 on the GPU). Each sprite probably comes from a sprite sheet, with 8-64 different images that this sprite might be (like a star twinking in and out of existence). That whole sprite sheet needs to be in memory.

So 2000 sprites, with an ID number (4 bytes), position (8), rotation (8), velocity (8), light (4x4), light color (4 x 16) = 216,000 different figures that are constantly changing and being adjusted, probably 20 times per second.

Now THERE'S a laugh. Proof? At least something you've made and put online yourself?

 

I find it funny how everyone is ignoring the elephant in the room in terms of how this preforms worse than high end 3d games. It's the dynamic nature obviously! It's a hell of a lot simpler to render polygons if said polygons are not tasked with having to listen for things that may affect it. One massive indestructible box is going to be easier to physically simulate than a 10^3 member cube of equal size, because of the hidden complexity, the seams. Games like Minecraft, Terraria, and Starbound have lots of these "seams" in their terrain that make it infinitely more responsive than say, team fortress 2. In order for anything to change it has to be responsive to stimulus, and listening for stimulus on the programming level is a very small but rapidly repeated process, similar to the classic "are we there yet" joke.

 

The Commodore 64 was the last computer that could be completely understood by a single person. As Moore's law hurtles us ever further to higher clock speeds, our games and applications will likewise do their best to fill the space. This is not new, and I really doubt the vast majority of people will ever harken back to the golden age of amazingly efficient, and elegantly beautiful assembly applications. It's not a silly notion: Rollercoaster Tycoon was programmed entirely in assembly, and I'd argue that it's a much more complex game than this.

Hope is not lost... NASA doesn't use Ruby on Rails to run their spaceships after all. yet. There is no excuse for 30% cpu being used on the menu screen. And you know what? Ten years from now they'll be no excuse for 30% of my Trinity 100 gigahertz QPU being used on my game's menu.

 

Memory leaks, the true nemesis of any C/C++ developer! Have you had any luck with running Starbound in profilers? I swear by (and sometimes at) Valgrind, personally.

Well, if you're not a developer yourself, it's pretty hard to appreciate the efficiency, elegance and beauty of code, unless it's something very dramatic like a FPS where code and data came to 96k.

 

Oh, I forgot to make my planned 'actually-helpful' post for the day. I use a program called "BES" or "Battle Encoder Shirase" for my badly-behaving programs on windows. It forcibly and violently maintains order in my cpu scheduling, and sets the cpu usage of any program to a cap based on my input. Slide the cpu usage down too far though, and I get choppiness. ...And, were you implying I'm not a 'developer'? I admit I have no active projects at the moment, and very little finished to speak of. More of a hobbyist. I do recommend that program though. I'll look into Valgrind.

 

It will be interesting to see what the developers have to say about this.

 

maybe you should have taken a look through the postings because one allready did rendering the op's statment as uterly false

 

No... That was the generic 'you' rather than you personally

I don't think there's a Windows version actually. Dr. Memory is quite good, though not quite as full-featured.

 

You lose all credibility with this statement, the reason for standalone chips like PhysX is that devs DONT have to program these complex physics engines themselves. These add on chips your talking about you get the middleware engine for the intended purpose.

When you have middleware written for specific hardware it WILL be better than just middleware ran on a CPU. CPU's do millions of instructions a second (with the majority including math), so calling them bad at it is ignorance. I wish high schools would stop having people read Dijkstra's Notes on Structured Programming....that thing was written in the 70's.

 

Programming manuals get better with age, because all of the antiquated notions back then are useful now; R&K remains the best C tutorial and textbook after all this time. But on the other hand you're right; PhysX, and, relevantly, SDL.DLL (Which you might find in a bunch of different games on steam) exist and are used so everyone isn't reinventing the wheel (even if it might be personally beneficial and efficient to do so). This is because, in the end, human labor is worth vastly more than cpu cycles; cpu cycles are getting cheaper every day, but humans good at CS are still in high demand.