Return to “[Archived] Daily Dev Logs, 2012 - 2015”

Post

Week of January 5, 2014

#1
Sunday, January 5, 2014

With the completion of the pointer editing node today (including abstract base classes), the data editor is once again in working order, this time more elegant than ever since it's all implemented with the nodal UI!! The other major task du jour was fixing that blasted UI bug that was causing all of the nodes to jump to the upper-left corner of the screen for a moment when closing the UI (did anyone catch that in the update video? :oops: ). Well, I got it! Thankfully. That one was really annoying me :crazy:

I spent a while thinking about the difference between "informational" and "functional" nodes today. In most UIs there is a distinction between input and output - something that displays information versus something that takes it in. I keep thinking that there must be some elegant way to separate these in the nodal interface - it feels a bit messy to have the "new" and "delete" action nodes sitting next to the informational nodes within the pointer type viewer, for example. I feel like there should be some difference - maybe you have to pull up an action menu if you want to see the node's inputs. Maybe the input nodes are in a different location, lining the top or bottom of the screen. I'm not sure what the right solution is yet, so now I'll just leave them in the mix with the other nodes, but it does bother me a little.

So far, January is on track to be a big month :) If I can keep up the pace (and I will!), 2014 may just be the year I'm hoping it'll be.

The bulk of tomorrow's schedule is finishing the new local fog technique...but with SMAA integration and "working" research both due in two days, I've got my work cut out for me, as always :geek:

PS ~ Another interesting tidbit: I played around with square / rounded square nodes today rather than circular. Kind of an interesting effect..not sure which shape I prefer yet :)

PPS ~ Rather behind on weekly summaries again..who would have thought :roll: :oops:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 5, 2014

#2
Monday, January 6, 2014

Mostly worked on the new local dust technique today. I managed to finish it, and, ultimately, it's about twice as fast as the old one. Still, I'm more than pleased with it, since it uses less code, is cleaner, and doesn't have that nasty bug of drawing a big black sphere on the screen for a single frame every once in a while (yet another thing that hopefully no one caught in the update video :roll:). Furthermore, it can use soft depth blending, which makes the fog play nicely when it intersects geometry. Great! :) I'm also happy because the shader was my first step into the world of quaternions, which, to be honest, any graphics programmer should know like the back of his hand. Guess who knows almost nothing about them :shifty: Well...not anymore! :geek:

Interestingly, while implementing the new technique, I discovered a cool way of generating permutations of the background, quite by accident! I realized that, by applying a random rotation to the environment map and blending it back on itself, you can create a lot of different variations of the same background that look great. Surprised I didn't think of that until now :o But that's great, because the math that I use to generate the nebulae is a bit unstable, and for that reason it's not so easy to get variation out of it. I do get variations in the nebula formations, but sometimes the same large-scale features can be identified in a lot of the backgrounds. With this little permutation trick, that should be easy enough to change :thumbup:

I also got a head-start on the SMAA implementation today. I've finally given up on RSAA, not because it doesn't work well, but because it doesn't handle specular aliasing - and with all the new lighting fanciness in play, we really need to handle specular aliasing. It is my understanding that SMAA is currently the state-of-the-art in AA, so I'm excited to see the results. Unfortunately, like most modern-day shaders, it uses a lot of fancy GLSL instructions that aren't compatible with older versions (like the one LT is targeting), so I have to rewrite it to work with older GLSL. Well, I hope it's worth it - I'm getting tired of the specular jaggies :crazy:

SMAA and research due by the end of tomorrow. Let's go!! :D
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 5, 2014

#3
Tuesday, January 7, 2014

After about 12 hours of working on the SMAA integration, I was ready to give. I knew it would go this way. Fancy techniques always mean fancy code. And in graphics programming, we measure the fanciness of a piece of code by the number of ways it can (and will) break. I remember back when I integrated FXAA. It hurt. But that little bit of jaggy-killing fun isn't half as fancy as SMAA. No sir, not even a quarter. Or eighth. This right here, this is fancy. And you know what that means. Millions of ways to break :shock:

It's a three-pass ordeal. The first and last passes are straightforward. Edge detection and blending. Nothing to write home about. Appetizer and dessert. It's the middle pass - the entrée - that holds more black magic than all of the Daedric Princes combined. The mythical blending weight pass. :monkey: :crazy:

Well, we battled for hours. And by battled, I mean like, I had one or two infantry standing outside the SMAA castle. Standing outside the castle, but separated from the castle by at least three different moats filled with all variety of deadly sea creatures. We were casting wickedly-mean glares in the general direction, but I think it's fair to say the SMAAians did little more than laugh at us from the safety of their walls. There's just no way to understand code like this. No way to cross the moats, much less do any real damage. I tried re-writing it a thousand different ways, but each time...the same, equally-wrong result.

I nearly did give in, until I stumbled upon an exceptionally low-profile git repository by someone claiming to have implemented SMAA in GL. It was also said that this person had acquired help from the creator of SMAA himself in order to hammer out the issues with the GLSL port. So I compared our code. I had done everything similarly. Really couldn't see any way that I had made a mistake and he hadn't - it all looked the same in function.

Just for kicks, I decided to diff the 1200+ line SMAA header in case this person had figured out a magical way of tampering with the header to make it work.

Code: Select all

Line 846: e.g = -e.g
HA.

HA. HA.

Yes. One incredibly-cryptic line, hidden in one incredibly-cryptic function, in a file of over a thousand incredibly-cryptic lines of shader code. Of course. e.g = -e.g. OF. COURSE. WHY DIDN'T I THINK OF THAT. You just have to add a random line in a random place that negates a random component of a random variable!!! Derp. :monkey:

Sure, I thought. Why the flip not. So I tossed in that line. You know, for fun.



And the whole bleepedy-bleep thing worked. Perfectly.


(And yes, SMAA looks amazing - every bit as nice as they say it does. But I'm still mad at it >:3)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 5, 2014

#4
Wednesday, January 8, 2014

To be fair, it's hard to match the excitement of a day-long war with a graphics technique, so I think I'll keep it a bit short today ;)

I finally created a file browser with the nodal UI, as many people have suggested on the dev videos of late. Not really much work, since the UI does all the heavy-lifting...but the results are definitely cool :) I got to visualize the LT source tree for the first time ever. It's actually quite pretty! Very structured. And one super-cool thing that I saw with the browser (which I also mentioned a long time ago in the first iterations of the data editor) is that I could quickly discern patterns in the data that normal file browsing just can't expose. Like, I could quickly make out directories with the same structure just at a glance! So cool :D Anyway. Yes it's relevant to LT! This is going to tie into how the modding tools work. I believe I will just have the mod editor be a "restricted" browser that edits files within the LT resource archive. I'm still working out exactly how to define a file, but I think each file will just correspond to exactly one piece of data (for example, a grammar that describes a procedural language, an expression tree that describes how to build a ship, etc). Then we will open up these individual files to see the data, at which point you will be using the trusty old data editor to do whatever it is you want to do.

If you're wondering where all this is heading, yes, it's still a part of getting research up and running :geek: The data that the research mechanisms require is really the first true "game data" that I will be authoring and exporting to files (using the editor). This data will describe the default properties of items, as well as the ways in which those properties can vary under technological modifiers. I'm close to being able to do so, but I'm battling one final issue with the reflection system at the moment :monkey:

I also took a bit of a deviation into troubleshooting today, as I'm getting tired of this very slight FPS issue that I've noticed over the past few months. It's nothing major, in fact a lot of people probably wouldn't notice it - but there's a certain roughness in the frames, especially when all of the graphical settings are turned on. After some thorough investigation, I realized today that this is due to "microstutter," or individual frames having a high variance in the time it takes to produce them. After whipping up some tools to measure and quantify the stutter, I was a bit disheartened to see that LT suffers anywhere between 50% and 100% frame time variance (a lot more than "normal," presumably). Meaning, one frame may take 10ms, and then the next may take 20ms!! Overall, everything still averages out to 60+FPS. But the discrepancy between frames causes a slight roughness in motion. Now that I'm aware of the issue, I'll surely be able to beat it back into line. I've already identified that the cause is, not surprisingly, the game simulation not being run every frame (so simulation frames get hit with a lot more CPU work than other frames). Perhaps I should look into multi-threading the rendering / sim components... :|

Luckily, the stutter is easily-defeated by vsync, which I imagine most people will play with. But personally, I like to turn vsync off to get the fastest-possible response time...so it bothers me :ghost:

Looks like tomorrow will be another full day of working on research :)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 5, 2014

#5
Thursday, January 9, 2014

Unfortunately, was quite ill today for unknown reasons :( Didn't manage to get much done as I was having a hard time concentrating, and spent most of my time incapacitated on the couch. Not sure what I came down with but it seemed to come out of nowhere. Not cool! I can't afford to be getting sick in a critical month like January. And how I managed to catch something when I live in complete isolation from civilization is a mystery of grand proportions :eh:

Maybe it was the squirrels :squirrel: :( Those darn, sickly squirrels. They did this to me :think:

Hoping for a speedy recovery and a fast track back to the coding zone :geek:

PS ~ The speculation about me being a robot is clearly wrong, since, as we all know, robots do not get sick ;)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 5, 2014

#6
Friday, January 10, 2014

Back in action! Was able to quarantine the vir-...er...get over my cold...fairly quickly :)

I finally tackled the bridge between the file explorer and data editor today by introducing a notion of an "AnyType" class and writing serialization functionality for it. A file is just a serialized AnyType!! Very nice and clean. I can now create new files after selecting a type for them, and the engine will make the appropriate annotations using the same serialization architecture that everything else uses.

The result of all this is truly elegant. I can explore the file system using the nodal UI, and when the engine detects a file written in LT's universal data format, it can automatically expand the structure of the file using the data editor. So I can literally drill all the way from my home directory down into the properties of a weapon in the game data file, modify the damage, and pop back up into my source tree all in a few effortless motions. Oh, and if I really want to, I can do it with my gamepad or joystick :D This level of unification...makes me so happy :) Opening a directory is the same as opening a file is the same as expanding the properties of a weapon is the same as...you get the idea. It's all just data - why do we have five million different ways of visualizing and traversing it in the present day?? :think:

So! I've got the tools...research is ready...I just need to...author the data! If you couldn't already tell, that's the part that I put off as long as possible :roll: I hate making arbitrary choices, like how much integrity the most basic shield should have, etc. But we do have to have a starting point somewhere.

Believe it or not, most of the day was actually spent elsewhere - on scanner gameplay theory. I'm getting a bit ahead of myself, because that's not supposed to be until next week, but I'm really interested to hammer out the mechanics of information acquisition. I solidified a lot of nice ideas today, but I'm not quite prepared to discuss them yet (primarily because I fear that, in my present needing-to-go-to-bed-very-badly state, I won't communicate them very effectively). But there's some super cool stuff on the horizon with respect to that area of gameplay :thumbup:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 5, 2014

#7
Saturday, January 11, 2014

Massive day. The code just wouldn't stop flowing...you know how that goes :D Subsystems are getting a really good going-over at the moment as I prepare to implement new ones and finalize old ones.

I implemented a "generic" entity messaging system today that's going to help me keep things clean and tidy as I write highly-specific gameplay code. I always have a rough time figuring out how to do "specific" things...I'm much better at the whole unification game :) To understand where messages come in, consider, for example, that weapons need to be fed a "heading" that tells them where to aim. Thrusters need to be fed a "throttle" value that tells them how hard to burn. Scanners will need to be given several inputs that describe the behavior of their sampling patterns. Unlike most of the other code in the engine, these things are specific to only one type of object. So it doesn't make sense to write a component for them, nor does it make sense to introduce new items in the virtual function table to account for them. Messaging functions solve this need cleanly, allowing these specific units of functionality to be activated dynamically, without introducing any new bloat to the object class.

One interesting question that comes up in generic messaging is how to send and receive different types of data. Yet again, this recent "AnyType" class proves to be of great use! With AnyType, I can pass...you guessed it, any type of data as the message body, even while using the same function :) And here you were thinking that my fancy reflection engine was never going to be of use. It's really amazing how all of the engine tech that I've been working on for ages is finally paying off. I knew it would be worth it!! ;)

My final goal for the moment is arriving at a "clean" separation of turret and subsystem logic, where the concepts of "the thing that swivels and points in a given direction" and "the thing that happens when you fire" are independent. Reason being is that I'd like to work on transfer unit implementation, but a transfer unit is a turret that is not a weapon, and I don't have a codepath to support that yet. My approach right now is to convert the weapon into a subsystem of the turret, which is a subsystem of the ship. That way I have reusable turret logic. But I'm sure you can see something more interesting in what I just said! Recursive subsystems!? :D Opens up the door for a lot of cool potential, right? Things like being able to upgrade the capacitor on your gun, mount a more effective heat sink on your afterburners, or wire a range-booster up to your scanner. Heck, maybe you can even have guns on your guns :P

Hoping for another big day of code, and, hopefully, a first glimpse at transfer units sometime in the near future!
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 5, 2014

#8
Week Summary

(Written 1 week later)

I'd call the week a solid continuation of what promises to be a good month! With the data editor and file nodes in place, LT is finally equipped for authoring game "content" in an elegant and unified way. No, I still haven't authored that content :P But it's the tools that are the hard part :roll:

Not surprisingly, graphics Josh is most pleased with the SMAA integration. It was one of those "long but worthwhile" struggles. I didn't write the technique, so I can't be that proud - but it makes LT look that much better, so I'm happy nonetheless. Only the best for LT...always ;) It really makes such a tremendous difference to have all edges nicely-antialiased, but still have the stars in the sky look crisp :geek:

Accomplishments
  • Integrated SMAA into the engine - goodbye aliasing concerns!! :)
  • Implemented file browsing nodes and "AnyType" facilities for easily saving and editing engine data using files
  • Implemented generic entity messaging for ultra-clean & efficient entity-specific behaviors
  • Started work on scanner theory
  • Finished new local dust technique
  • Fixed UI jumpiness (one of the few long-standing bugs in the engine)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Online Now

Users browsing this forum: No registered users and 3 guests

cron