Sunday, June 30, 2013

Summary

Man, it was a painfully-intense morning! I didn't manage to finish all of the coding for the monthly video until about 5 am (I was hoping to have it done at 1 or 2 ). Filming took longer than usual as I kept messing it up right near the end. By the time I got to recording the audio (which is the last step in my video production process), it was 10 am Hopefully that explains why my voice was like "rawrrrgghg I'm a zommmmbehhhh!"

I actually still haven't been to sleep, other than the 1-hour nap that I snuck in while the video was uploading to YT. So if you thought I sounded bad in the video...just imagine how I sound right now

I was a little surprised at how positive the overall reaction was to the video! People really seemed to like the ship improvements. I knew they were better but...seems like it made a really big difference to a lot of people. That's awesome!!! And I'm glad the early-morning coding for that little production demo excited a few people

My half-day off was pretty nice. I had big plans for it, as I always do...I wanted to dig into a bit of procedural music composition again and see if I could set up a basic framework...perhaps revisit some of the old techniques that I used to employ and see if my new programming experiences could help me push further than before. Sadly, as it always happens on this strange day of the month, I was entirely too exhausted to accomplish anything like that. Since my mind was mush, I decided to just go to the national park instead and lay on a rock in the middle of the river for a few hours. It was very soothing. I didn't even try to think about LT. Just a blank mind and the sky

Upon returning home, I fired up Star Trek Voyager. I only had 10 or so episodes left in the final season...so I wanted to see if perhaps I could close that chapter of my life tonight! But I didn't manage to get all the way through. I think I have about 4 left. I guess that's good, as I'm really not looking forward to being finished with it

And now, it's time for that glorious sleep that has been evading me for the past...however many hours (math are hard ).

Tomorrow I'll be on the road all day, as I'm heading home for a one-week visit with friends and family in Baton Rouge. I'll try to do some thinking in the car I'm also getting a Mac this week, so I'm hoping to knock out the Mac port sometime while I'm home!

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]

Monday, July 1, 2013

Summary

I tried to think in the car today..I really did! But there's just something about going 75 mph that does not agree well with deep thinking Couldn't manage to hold a train of thought for more than the distance between passing cars, which, unfortunately, was not very long.

However, the day was not without productivity! Tonight I cracked open my first-ever Mac! After taking a bit of time to get acquainted with this foreign thing, I got the LT source installed and everything, but have not yet been able to successfully compile. I had no idea that the latest version of Xcode ships with Clang as the default compiler rather than GCC. This is very interesting, and should provide some cool opportunities. But it's going to make things a bit more complicated than I anticipated for the Mac port, because Clang seems even pickier than GCC. Here I was, thinking that I had finally become a good little boy with my understanding of template namespace lookups...MSVC and GCC both agree with me. But Clang slaps me in the face and tells me that I'm doing everything wrong.

Upon consulting the FAQs, I read that this is a common issue with people moving to Clang, because some other compilers do not implement it correctly. HA. It's almost like I've heard this story before!! (third-to-last line). I'll go ahead and omit an "epic rant to compiler writers" for the sake of my mental health. But seriously. MSVC / GCC / Clang all have a different interpretation of the same c++ spec. Nvidia / AMD / Intel drivers all have a different interpretation of the same GLSL spec. NOT OK

Sorry about that Anyway, now that it's in motion, it won't be long before this Mac port is running (for what it's worth to you)

I'm also hoping to solidify more of the event architecture while I'm home this week, and if all goes well...start implementing some of it asap!!

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]

Tuesday, July 2, 2013

TL;DR (Specifically for those with no interest in Macs)

Mac port coming along nicely, 45% compilation. As always, porting is good for all versions of LT because it raises issues that require improving the codebase as a whole!

Summary

Quite a nice day, albeit another nothing-but-technical-grinding one. I really want to run LT on this new laptop, so I'm just grinding through all of the things standing between me and doing so!

Following the "correct," strictest-of-all-stricts c++ template rules has led me to having to redesign some of the fundamentals of the serialization engine. I wasn't happy about it at first, but in the end I managed to also see some simplifications while doing the rewrite, so it wasn't all a waste of time! I mean, nothing's a waste of time...like I said before, as long as you're learning, it can't be a waste of time. And I'm hoping that this is my last lesson in two-stage name lookup, because I think it's been more or less branded into my cortex at this point. I'm a pretty peaceful guy, but if any more compilers come along and decide to implement it differently, I swear I'll take a .45 magnum to my screen and never touch a computer again. I'll go get a degree in biology and become a park ranger instead.

Violence aside, I finished re-writing the serialization engine, and I think that this was the majority of what was causing problems. I'm at about 45% compilation now, which is a good sign. There are still some small issues to work through, but none of them indicate a problem as big as the aforementioned. Of course, there's also still linking to worry about, and these dylib things are new to me, but how different can they really be from DLLs or SOs? Hopefully not too different...

In other news, it's nice to be home for a bit and I'm enjoying spending some quality time with Mom. Even robots have families, you know

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]

Wednesday, July 3, 2013

TL;DR

Mad at the world because of OpenGL. Rawrrr ARB, rawrr Intel. Mac port harder than expected.

Summary

After re-working more of the engine code to appease the compiler, I managed to get 100% compilation. But I didn't celebrate. Because then came linking. Yes, we all know how joyous linking can be. I swear, I think any nightmares I have from this day forward are going to be about linker errors. It actually took me about an hour to win this battle with the linker. Much to my embarrassment, the issue turned out to be that I forgot about my custom modifications to the SFML source (remember all that text-rendering-speedup fanciness?), and linked against the vanilla version (while the LT engine was expecting to see the enhanced version). But naturally, the linker could not provide a sensible error, like "binary interfaces incompatible," or something like that, it has to be.. "non-virtual thunk unresolved." And of course this makes perfect sense...because we all know precisely what a "non-virtual thunk" is (yes, it sounds like Hutteese to me too..)

Finally, linking went through, and I had the official Mac versions of all LT-related applications compiled and ready to execute on my Macbook! As you might expect, they did not work on the first try (nor the second, nor the nth (for all n)). Now we get into the fun world of OpenGL on OS X.

A friend once warned me that GL support on OS X was #$^$ed up (I think he used those exact words, dollar sign and all). But it's not quite Apple's fault this time. It's Intel's. I ordered a Macbook Pro with an Intel HD4000 integrated graphics card. Yes, an underpowered option for gaming, but according to a survey carried out by Steam, a nontrivial portion of gamers actually use this very card to play games on Steam. So I figured, might as well go the extra mile and get LT to work on it. Well, to tell you the truth, this is not going to be a walk in the park. OpenGL is an incredibly strange beast, and by that, I mean, an incredibly poorly-designed API. From time to time I am able to forget about this. Months go by, LT works, I don't have to even think about GL thanks to my abstraction layer, and all is well. And then days like today happen. And I remember why I hate OpenGL.

So here's my dilemma, folks. OpenGL (being a terrible API), comes in various "modes." One of those "modes" is called "compatibility profile." This mode provides access to old / "deprecated" features, which are planned to be removed in the future because they suck (although, by this metric, all features in GL should be deprecated ). The other mode, "full," provides only the "new" features. SFML, the library upon which LT is built, requires the compatibility profile, because it uses some of the old GL functions. In fact, LT uses a few of these old functions as well, IIRC (although I think they could be removed without much pain). But here's the kicker. Depending on which profile you enable, compatibility / full, you get a totally different set of features, even on the same GPU. For example, with a "full" profile, this HD4000 supports all of the things that I need for LT. OpenGL 3, GLSL 1.5, all of the extensions, etc. BUT. With a compatibility profile, it supports...none of that. No GL 3, no GLSL 1.5....!?? Yes indeed. Even though the hardware and driver obviously have the ability to support these features, the driver won't do it in compatibility mode. Woot. Lovely choice. Really. Lovely choice by everyone involved.

So, being stuck between a rock and a hard place, I spent the night re-writing every shader in the entire engine to have GLSL 1.2 compatibility (which is supported by this absurd compatibility mode). I think this is going to prove to be the easier path. Just downgrade to GL 2 and GLSL 1.2. Hopefully this won't cause too much pain. LT doesn't use many fancy features, so it shouldn't be too bad. The lack of "textureLod" in GLSL may cause serious problems with the procedural generation of meshes, but I'm not sure about that yet. To be determined.

Any way you slice it, this Mac port is going to be more painful than I imagined. But I don't blame it on Mac. I blame it on Intel and ARB. I'm quite certain that if I had one of the more powerful MacBooks with an Nvidia GPU, LT would already be running without a problem on it! Too bad. At least this way I can see the problem before someone else has to tell me about it. And, as always, there's still some good news for non-Mac folks: LT will run on an even wider variety of GPUs, Windows and Linux included!

PS ~ I love you all and I'm really a very happy and positive person most of the time Just not right now. Not when it comes to GL.

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]

Thursday, July 4, 2013

Summary

YES. That is all.

As yesterday's log would suggest, I was thinking it would take a hefty amount of time and effort before we would see LT on Mac. And yet, somehow, the shiny LT battleship firing missiles all over this laptop's screen suggests otherwise

Naturally, this port didn't come without pain. But downgrading everything to GL 2.1 seemed a lot harder than it turned out to be All it really took was some retouching of all of the shaders, augmenting the LT shader preprocessor, and discovering that textureLod is actually supported via a widely-available GLSL extension. Hooray!

After getting the first "running" copy of LT for Mac, I quickly discovered that the mouse was pretty badly broken. As in, I couldn't move it, and I couldn't right-click. I solved the right-click issue by converting the input method to directly using window events instead of polling. Should have done that from the beginning, but you can get away with polling on non-Mac systems, apparently. But on Mac, it seems that, since the right-click is actually the same button as the left-click (just with two fingers), polling only detects a normal click. I guess polling accesses the raw hardware, while the messages coming to the window have been tampered with by OS X to convey the right-click.

I still haven't solved the mouse-not-movable issue, but it only occurs when the application requests that the mouse not be able to leave the window, so I can easily turn this feature off and play without a problem. Should be simple enough to solve once I look further into it.

And there you have it! LT is now a fully-cross-platform game. It only took a few days for Linux + a few days for Mac! Not bad at all

PS ~ Happy 4th of July, and remember - Argon Whiskey and missile launchers don't mix well. Fly responsibly

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]

Friday, July 5, 2013

Summary

Alright, well, the hours don't lie, and neither do I...so, might as well confess that very little work got done today. My family and I took a trip to New Orleans, one of the more "cultured" and interesting parts of Louisiana. While I did manage to do a bit of coding on the way there and back, it really didn't amount to much. I replaced the mouse movement system with events, just like I replaced button clicks with events yesterday. Now the mouse is completely controlled by events rather than polling. This fixed the issue with not being able to move the cursor, but I have not been able to correctly implement mouse-grabbing windowed mode on the Mac yet.

Since there's so little progress to report for today, it seems like a fitting time for a confession. I have a very solemn one to make. I don't really know how to say it, so I'll just lay it out there.

I switched to vim.

If you don't know what vim is, I'll just tell you. It's a program. And it's famous for precisely two things. First: being the most powerful text / code editor in existence. Second: being the most pain-in-the-rear, hard-to-learn, impossibly-steep-learning-curve text / code editor in existence. I always swore to myself that I would never stoop to something as counter-intuitive and obscure as vim. But you can only hide from the truth for so long. The truth is that vim is the most sophisticated coding environment out there. I hope to be coding for at least the next 40 years or so. If I'm going to be coding that long, I may as well ensure that I'm using the most powerful tools. So, I might as well see if there's something to this vim, which people seem to tout so vehemently.

They say it takes several months before you can even become proficient with vim. That may well be true. But at three days, I'm already feeling the power. Though I have yet to reap them, I can sense the speed gains coming. I can already feel the mentality; I can already understand why it is such an important step. The question that so many ask is "why does it matter that you increase your coding speed by some percentage, if a true programmer is thinking 90% of the time and only coding 10%?" That's the same question I asked, and it's the same reason why I refused to try out a fancy editor for so long. But now I understand the responses. It's not about increasing coding speed. It's about translating thoughts to concrete realities more fluidly. It's about less friction standing between your ideas and their implementation. It's about a thought flowing from your brain to the screen with as little resistance as possible. That's what vim does. Yes, it may speed up that 10% coding time by 2x or so. But that's not the point. The point is that it makes you feel like you can open up your laptop and take total and complete control of your code with little to no effort. And that's a good feeling. And it's only day three

So...I expect that this new piece of my life will bring with it all of the usual symptoms of being a vim user. Prolific arrogance, an undeserved sense of coding superiority, and, of course, a relentless condescension toward those that use "lesser" editors. With any luck, maybe I can manage to avoid these nasty side-effects

Vader was seduced by the dark side of the force.
Josh was seduced by the vim side of the editing.

Life happens. The dark side is just so darn powerful, you know? What can you do.

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]

Saturday, July 6, 2013

Summary

Finally getting back to the real work! I'm about ready for a change of pace after all of this Mac nonsense.

Continued work on events today, and started to explore their concrete implementation a bit more thoroughly. The notion of writing game code that works equally well for any level of granularity is certainly a challenge. As I've mentioned in the past, one of the keys to this process is making sure that the objects that are undergoing simulation are accessed and modified in a generic way. Today I started working on a few different schemes for making this happen. Once I get rolling on the simulation code, there's going to be a lot of it. If I get this architecture right the first time, it's gonna pay off. So let's do that.

As a test case for my ideas, I'm working on re-writing the construction module to use events. The goal is to end up with a piece of logic that works exactly like what was demoed in the monthly video...when run at a fine level. When run at a coarse level, the same piece of code should be able to operate in terms of the pure-numbers game of which I've spoken before. "Build points," for example, controlling how quickly a faction can increase its "weapon points" (how many weapons the faction owns).

The real technical magic in this scheme is the translation layer that events will use to interact with the world. I'm still playing with ideas to find the best way to implement this. Essentially, it will allow an event to produce changes in the world without ever knowing what "the world" actually is. All it needs is an "interface" into certain sets of functions, and from this it can drive "the world," whatever that may be. I think this is about as elegant as it gets for simulation unification. But it's so darn abstract and technically intense...it's going to be a wonderful challenge. But, if it pulls through, the reward will be..."well, more wealth than you can imagine!" ("I don't know, I can imagine quite a bit...")

Tomorrow I'll be driving back to my coding haven. I'm determined to do some thinking in the car this time I'm really looking forward to getting back and jamming on an intense week of simulation Let's get those hours back up above the 12 bar.

PS ~ Day 4 of vim. The addiction is worsening. My fingers haven't left home row in 16 hours, my skin is white from lack of sunlight, and I need a shower. Still no word from the mainland of Sublime. Hope they send help soon. Not sure how much longer I can survive out here in the terminal

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]

Week Summary

General Sentiment

Not too many hours this week since I spent a lot of time with family, but it's awfully nice to have that Mac port up and running! Very happy to already be able to cross one stretch goal off the to do list! I'm also excited about switching to vim, as I can already see it improving my productivity. Real-life optimizations are always welcome

Really hoping for an intense week of simulation next week

(Yes, I'm splitting the Mac port into three separate bullet points, firstly because the list would look pitiful if I didn't, and secondly because they are all rightfully major accomplishments!)

Major Accomplishments

• Achieved compatibility with OS X (!!)
• Achieved compatibility with Intel HD4000 (via graphics requirements downgrade)
• Achieved compatibility with Clang compiler
• Started implementing events & abstract simulation translation layer
• Successful (if a bit tired-sounding) 6th dev update!