Sunday, March 26, 2017

One of those weeks where loads of things were started, but none were finished. This week was dedicated almost exclusively to working on the entity system in the LT Core. This is, as we've found out from previous experience, where we'll either make or break LT's performance. Sadly, it'll be a rather bland log since I don't have all the solutions yet (getting these particular bits structured correctly is of utmost importance). I'll describe my work-in-progress nonetheless. On a side note, it's been a pretty rough week for me due to unfortunate events in my personal life, so forgive me if I'm not as enthusiastic as usual.---: In progress. I've been running through lots and lots of ideas on how to structure this bit, since, again, it's part of the overarching entity system that's going to make or break performance. I'm experimenting with several different architectures at the moment. Component-based entities are no doubt the right way to go in games (as opposed to big inheritance chains and/or multiple inheritance), but with them, the devil is in the details. Trade-offs are everywhere. Do we want to be able to add or remove components dynamically? Perhaps not -- but if not, can we still define new types of objects from script efficiently? If not -- can we define a 'generic enough' set of prefab entity types to support all that we want to do from Lua? Should we prefer structure-of-arrays format to save instruction cache misses, or array-of-structures format to save data cache misses (most people people assume the former when speaking of component-based entities; I'm not completely convinced.) Basically, there are a lot of choices to be made here that will have far-reaching consequences for both how gameplay is written in Lua as well as how performant everything is. Only time and experimentation is going to tell which set of choices are optimal: In progress. I spoke in the last log about my excitement for handling gameplay in a fundamentally different way using event-driven programming. I've started implementing the machinery for it in the core and have a few basic event types defined, although I can't test this system effectively until the entity component system is stable. Nonetheless, the more I get into the implementation and the more I shift my mindset to using events rather than 'polling,' the more comfortable I feel about LT's performance. I'm still absolutely convinced that we're going to see incredible results from this paradigm shift! When speaking about FPLT, I've often explained how the performance problems that arose in the old LT were, at their core, due to the sheer number of entities requiring simulation, resulting in a 'death by a thousand papercuts' situation. When the event system is complete, number of entities will no longer be the problem, because any entities that don't require computation on any given frame won't take up a single CPU cycle!: I've had some revelations this week about my usage of Lua. In particular, I think I'm using it sub-optimally with respect to scripting the behavior of entities. I have a new idea that I've yet to get around to testing that involves binding an entity's local Lua state very tightly to the C Entity structure. When implemented, this will result in, essentially, me being able to turn off Lua's GC and manage memory explicitly, which will be a huge win. It will also solve the problem of how best to 'wrap' the core entity data with extra scripted data. However, until implemented, I won't know if the memory overhead of this approach will be a deal-breaker or not. I doubt it will be.: More performance tests this week yielded some startling news: the JIT part of LuaJIT is hardly helping at all. Turning it off entirely results in almost the same performance. This is both good and bad news. The bad news is that I'm obviously using LuaJIT sub-optimally (and it may have to do with the above point). The good news is that if such is the case, then there's more perf waiting to be squeezed out of the LJ parts of the code! I honestly just need to come to a better understanding of Lua and LJ, and perform more measurements to see what's up.: In progress. Lots and lots of thinking time put into it this week. It's a toughie, but I'm going to nail it sooner than laterJust wanted to give it a mention since a large amount of brainpower was spent on it.: On Thursday I showed LT off in New Orleans at the 'New Orleans Entrepreneurship Week' event ( check it ). Since it was less amenable to interaction than the previous events, I wrote a new 'cinematic camera' that flies around a system, smoothly moving and panning while looking for interesting things to look at. Yes, my demo was, essentially, 'Limit Theory Screensaver'It was quite lovely and I got very positive feedback on the aesthetics (of course, that's not of particular consequence; we already know LT looks great...the being really fun part is more important now!) One guy even mentioned that he used to love playing Freelancer, and was excited because LT looked like a modern version of it. Naturally this made my day---In the coming week I'll just be continuing with all of this work and, if the fates align, perhaps even finishing some of it. The day where we leave FPLT in the dust is fast approachingPS ~ To those who voiced their concern at the last log: my sleeping patterns were significantly more regular this weekDon't worry, I did learn my lessonHey everyone! This is Talvieno, ready to serve up your non-technical summary!Josh first mentioned that he's been working on how objects (entities) are designed in the code. In code, an "entity" could be a ship, or a station, or an asteroid, for instance, and could all use the same base code. Josh is working on designing this "entity code" so it will run as fast as possible, because with so many "entities" in the game, the quality of this code will really decide what kind of frame rate you see. He's not sure of the best way to do it yet, but he's making steady progress.Something else Josh worked on: the "notification/event system" lets the program decide where it can safely (temporarily!) forget about things like ships to save even more frame rate (e.g. if a ship is idling, the game doesn't necessarily need to think about that ship all the time). LT runs fast, sure - but that's on his beefy machine. He wants it even faster.As to LuaJIT (the scripting language that modders can use), Josh discovered that he was using it sub-optimally - kind of like if you were using a paintbrush with the wrong kind of paint. (It's a poor analogy, but hopefully you get the idea.) He's working on fixing that too, again for more performance improvements.Finally, Josh took an "LT screensaver" to NOEW - the New Orleans Entrepreneurship Week event. This "LT screensaver" had a ship that flew around and looked at things in a system. People loved it, even though they couldn't actually play. Josh was quite pleased with this.tl;dr: Josh is working on performance improvements so that almost anyone can run LT.