Excellent week of work. Excellent in the sense of no sudden big problems, changes in course, crazy ideas that cause straying from existing courses, or agendas that obliterate all notions of course entirely, etc. Just your standard, solid week of good work. The kind that we need a couple <insert order-of-magnitude estimate here> more of and LT will be done
On the LTLJ front (Limit Theory in LuaJIT; yes I like abbreviations): good week of getting more content brought over and sanitized. PlateMeshes are on the way back (the model format used to generate stations, ships, turrets, and most other artificial objects in LT), this time being promoted to the LT core. With them, all pm-based generators are on the way back as well (ship, station, and the various little hardpoint mesh generators). I'm interested in doing a better job with the implementation of this type of model than I did in LTC++, since it ended up being a really good, heavily-used piece of tech. When I wrote PlateMeshes in the original engine, it was more of a prototype that ended up seeing a huge amount of use. I never did replace the occlusion generator with something robust. Though I'll first port over the old solution, I'd like to upgrade it to a sub-quadratic algorithm...it was very slow to generate HQ meshes with occlusion in the old engine! Perhaps more importantly, I never did come up with a good texturing solution (by 'good' I mean nice, clean UV-mapping rather than doing a bunch of expensive pixel shader hacks to get a decent-looking plating pattern). PMs really should be quite trivial to UV-map, so I'll give it a shot once ships and stations are 100% back.
In other content news, planets are back and almost at 100%, including atmospheric scattering. The only thing lacking is the actual atmosphere mesh (which will take all of thirty more minutes). Asteroids will be back as soon as scalar field surface extraction makes it into the LT core, which, again, is more just a matter of me spending some hours on it than any kind of real intellectual work. The LTLJ renderer (a remarkably small piece of code compared to in LTC++) now respects opaque vs. blended passes.
In summary, a lot of stuff is coming back very quickly, as I promised it would, since the real work of thinking through problems is already done in many cases. It feels so nice to get to focus on pulling content back in. It's getting more and more fun to hop into the growing PAX demo and shoot at baddies It feels a lot more epic with a nice, big planet in the background. This time around, I'm not going to make the mistake of going for long periods without a playable version of LT. I intend to keep the PAX demo in working shape and updated with relatively-recent content, both so that I can continue to feel the inspiration of being able to play LT, and because I'll be pushing myself to go to more local tech events where I'll demo the game (I'll give you all a better heads-up next time if I happen to go to another major event, though I think PAX South will be the last for the foreseeable future; the other opportunities available to me are local to Baton Rouge or New Orleans).
Some more good news: this week I experienced one of the happiest development moments in memory when I got to see my universes in VR for the first time!! For Christmas I treated myself to an HTC Vive (with which I'm in love), and subsequently implemented VR support in the LT core. However, I had never taken the time to wire up the PAX demo to the VR functionality before this week. All I did was add support for rendering to a VR headset and using the headset's tracking information to allow looking around; I didn't actually spend time making controller mappings or making the demo appropriate for VR in any way -- I just wanted to see it. And whew, did it blow me away. (Allow me to be nostalgic for a moment?) It reminded me of why I became a graphics programmer: because I wanted to build worlds. I always dreamed of getting to build worlds and then explore them. When I was 17 I pledged to myself that I would stop dreaming about it and do what I could to make it a reality, which is when I started the long process of learning 3D programming (which I assumed, at the time, I'd never really be able to do). Around this time I also looked into the other component -- exploring the worlds. But the hardware just wasn't around back then. I saw how I might be able to build worlds with enough learning, but I didn't see how on earth I could learn enough to build the technology that would let me experience those worlds. Fast-forward less than a decade, and a bunch of really smart people have done exactly that. I never dreamed it would happen so soon...if you had told me back then that in eight years I'd be able to code planets, nebulae, stars, ships, AND that I'd have access to hardware that would let me SEE them (almost) as I see objects in reality...no way I would have believed it. But there I was, this week, floating above a planet, staring at nebulae and stars, watching the occasional pulse laser fly by my face. Switching to first-person and flying by big ships (even though they're just big blocks pending the transfer of the ship generating algorithm) is thrilling. Even the most trivial of experiences, like slowing down time and watching a pulse fly by, thinking "my god, that's just a big equation I wrote...and here it is, flying by my face..." can be rather amazing
Though the VR experience isn't the primary focus of LT, I'm planning to do a lot more visualization and testing in VR, simply for the inspiration factor. It's one thing to see my changes on a screen, but it's 10x more inspiring seeing it 'for real.' After two years of relatively-uninspiring work, I'll take all the motivational boosts I can get. This week's LTVR experiences were an unexpected but welcome dose of fire
On the nuclear front: not a lot of progress (I'm doing a good job of keeping it low-priority!) However, I did implement address patching for jmp, jcc, call, etc. This means that I can effectively use labels, which means I can implement function calls, conditionals, loops, etc...things involving code addresses that have to be patched-in during relocation. I tested this out by writing and emitting some basic loops. It was surprisingly-exciting to see the results, simply because it's a great feeling to see zero-overhead loops. When I say zero-overhead, I mean...I can literally take the # of loops executed per second, multiply by the number of ops in the loop's emitted machine code, and get a number in the rough ballpark of my processor's clock speed (to be perfectly honest I'm not sure if that math makes sense given my still-limited knowledge of micro-architecture...but...I do get numbers close to my clock speed... :3 ) Cool stuff!
I also made it through chapters 7 & 8 of the Intel Manual (Vol 1), which I'm slowly digesting for fun and the betterment of my brain. 7 (programming with general-purpose instructions) was mostly review, although I was unaware of the string instructions like MOVS, LODS, STOS, etc. Interesting stuff to know. "A REP STOS instruction is the fastest way to initialize a large block of memory." Neat tidbit, always wondered if that kind of thing could be done in asm without a bulky loop. 8 (programming with the x87 FPU) was fairly new to me, and was a lot of enjoyable (and relevant) information. I never knew that the FPU used a stack-based register model..interesting. Also didn't know there was an instruction for loading a very-high-precision pi constant (FLDPI). It was also nice to solidify my understanding of FP precision, a common source of confusion and misinformation from what I've seen.
Next week will hopefully see more of the same: old content revitalized and brought back to life with renewed vigor in the LT core or the LJ code, more functionality in the PAX demo (I would especially like to see some more AI work, although it may be premature at the moment), more inspirational moments staring out into space with a Vive on my head, and more assembler functionality (I'd like to see basic FPU usage and machine code generation for some basic 'real-world' math, the likes of which would be used in LT tight loops).
Seems I failed again at a short log. Ah well, I guess this is just how things are now...I seem to enjoy my work and talking about it! I suppose it's better than the alternative, which has been the case in the recent past