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

Post

Week of January 26, 2014

#1
Sunday, January 26, 2014

Once again, not the day I was expecting, but still a great one - and very necessary :geek:

A long time ago when reading about Valve's work on porting the Source engine to Linux, I came across an interesting tidbit. Valve mentioned a particular optimization related to framebuffers. Given how much of a pain in the rear those things are, I figured I should look out for performance issues related to not having implemented this optimization. Over time, I came to suspect several bottlenecks in the LT graphics pipeline as being related to this particular issue.

I was right. :geek:

Today I finally implemented this optimization suggested by Valve. It was no small task, as it requires a significant upheaval of some of the framebuffer-related code. But man. I'm glad I did it. They were right - this is a major bottleneck, especially on OS X and Linux.

Now, I know what you're thinking..."Josh, do we really need to be doing graphics optimizations when there are so many bigger fish to fry?" Well, the answer is...yes, just this one! Really, when I say this is a big one, I mean it. Bloom has been taking suspiciously long for too long, and I'm tired of giving it the benefit of the doubt :D I knew something was up. And I smelled framebuffer foulness. Sure enough, fixing this takes bloom from 4+ milliseconds to about 1. That's huge. The same is true of lens flares! :)

At any rate, now that it's all over with, LT is running at an extremely-smooth 80 FPS at full settings, 1080p on linux (and it should be about the same on Windows, though probably slightly faster). So. Silky. Smooth.

Between this latest optimization and the whole "spreading simulation over multiple frames" thing that happened a week or so ago, this game is so, so much smoother than it was last month :)

Thanks Valve for the pro tip!! :wave:

PS ~ I realize I never actually said what the optimization is, but if anybody out there is a graphics programmer and wants to know, it might be helpful to explain, since this one is a non-obvious but highly-necessary optimization for GL. The key is this: don't switch out the attachments of your framebuffers. Instead, switch framebuffers. E.g., if you need to render to a texture, don't just keep the same framebuffer and switch out the attachment. Create a new framebuffer, attach the texture, use it, then cache the new FBO. Next time you need to render to the same texture, do a cache lookup and use the same FBO. The idea is that when you change out the attachments of an FBO, it forces the drivers to do some kind of stupid validation, and, for whatever reason (probably the fact that everything related to FBOs is Evil and Bad), this validation takes a remarkable chunk of time, leading to noticeable performance degradation whenever attachment-switching is involved.
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 26, 2013

#2
Monday, January 27, 2014

Started implementing signatures today! Yes folks, it's finally that time. Let's put this bad boy of a HUD to use :D

The biggest question for me now is how to handle the different HUD "modes." I almost want to think of them like full-screen applications between which you can switch. A scanner gives you access to an active scanning mode for the HUD that is dedicated to careful analysis of signatures. Other pieces of equipment might give you access to other applications to which you can switch. But they can also give you access to smaller widgets that you can pin to your primary HUD view. What's the difference? How do they communicate the fact that they have associated applications? How does the HUD query them? How does the HUD indicate the availability of full-screen applications to the pilot? How is control of the HUD transferred to a subsystem? A fresh batch of questions begs a fresh batch of answers :geek:

Now, a very exciting little development. You're going to have to trust me when I say that I didn't mean to do any graphics work today. I swear it!! Honestly! I didn't mean to :monkey: But an idea concerning chromatic aberration just came to me. An idea concerning how to achieve the amazing soft, gradual, sharpness-preserving aberration that I see in the big boy game engines. It has baffled me for too long. My previous solution was so close, but still so far, and it was driving me crazy when I saw the quality of, for example, the CryEngine aberration. This idea promised to change all that. I had to try it. It was such a simple idea, yet....yep, bingo, that's it, that's the secret!! :D I was missing something. A key insight. But today I got it, and it's almost unfair how good the aberration looks now. More subtle than ever before, yet more prominent and beautiful than ever before. Lovely. :clap: It's absolutely incredible how the subtle little "rainbows" all over the scene (don't worry, the chroma shifting is very subtle) goes so far towards tricking the eye into believing the scene :) I swear I didn't mean to!!

Wonder what surprises today holds... :geek:

PS ~ I feel like I may have mentioned this already, like, maybe yesterday or something but...the game is sooooo smooth!!! I'm just really happy about that ;)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 26, 2013

#3
Tuesday, January 28, 2014

Worked almost all day on the concept of "workspaces," which is what I now call yesterday's concept of full-screen HUD applications. Any node can now expose a set of "workspaces" between which the player can switch. Finally, we're ready to implement a "scanner mode" for the HUD (by building a scanner workspace)!

To that end, I made a quick test for a new workspace. Just a little overlay that projected a ring around every object in the system to my HUD. Looked wonderful, and the thing is, it took...like...zero code. And virtually no performance hit (there are thousands of objects in the system...). Compare this to the last time I built an overlay, where hundreds of lines of code were involved, and the thing chewed up nearly 10ms? Yeah, this interface system is alright, folks ;) I think I'll keep it :lol:

Other than that, I may have flirted just a little bit with gas giants today. Just some harmless flirting :) I'll say no more of it. And I certainly won't apologize for it :P

Hard to believe January is already gone and I've only got two days before the update :( I'll admit, I didn't get everything done that I wanted to...but then again, I never imagined the HUD would turn out this well. Ah, trade-offs... :thumbup: Who knows, maybe there's still time for a coding miracle :monkey:

It's not over till it's over ;)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 26, 2013

#4
Wednesday, January 29, 2014

Yep, miracles do happen :monkey:

Occasionally I get discouraged by the way I work. And then, on certain glorious days like this one, I get to remember why it's the way to go :geek: It's no secret that I have a particular methodology that puts algorithm, system, and tool above content creation. I'll spend two weeks at the whiteboard if it means a powerful and flexible subsystem. I did that with the HUD. It's discouraging sometimes because it leaves me with a lack of visible content while the architecture is underway. But then, there comes a day when the scaffolding comes off...a day when a system, algorithm, or tool comes of age and steps up to the plate to prove itself worthy of the development effort. Invariably, they succeed. Today I built a basic implementation of active scanning in about an hour. I spent several more hours refining it, but the core logic and graphics were done in an hour. It was effortless. The result? Sleek, elegant, and I would even say...fun! I won't claim that it's perfect. It might not even come close to resembling what the final version will look like. But it proves, once again, that what I'm doing here is legitimate. The gameplay will flow. It will flow quickly and easily, because it's nothing more than a child resting atop the shoulders of invisible giants :) The node UI, the HUD framework, the node renderer, the physics engine, the entity system, etc. etc....these are the real heroes :clap:

I mentioned my ideas on active scanning gameplay before, and that's pretty much what I implemented on this first go-around. I wanted something fun and simple, but 'real.' Not a minigame. Real as in, has meaning that makes sense. The way it works right now is that you have a circle in the center of the HUD that represents the scanning region. On the outside of this circle, a polar graph is constantly updating to show a history of the detected signal. When an object emitting a signature comes into the "field of view" of the scanner, a signal will be received, but is attenuated both by distance and angle. When you get an emissive object that's within range in your scanning cone, the graph spikes in real-time as it receives a signal. It's really quite cool to watch :)

You can increase or decrease the size of your sensor's aperture at will, and there are some nice trade-offs to be had in doing so. A large aperture means you can pick up a signal over a bigger region of space. But it also means that you won't know exactly where the signal's coming from, since it could be anywhere within a large cone. A large aperture also suffers from a much noisier signal. As you focus the aperture, you will get a cleaner signal, and will also know with greater precision where it's coming from. So naturally, you will generally want to sweep with a broad cone first, and then narrow it down as you close in on the signal's source. I like this system because it's easy to learn and hard to master. It's not hard at all to track large signatures at short range. But a master will learn how to comb regions with a very small aperture to discover ore / enemies / jump holes at a much larger range. They'll also learn how to discern faint signals among the noise, where an inexperienced user will miss them. Cool :D Again, totally subject to change and improvement. But for the moment, cool.

A quick word on active vs. passive scanning: you might ask why the ship's computer can't just do all of this for you. There are two answers. The first is that it wouldn't be fun - might as well ask "why isn't there a button that I can click to win the game" :P I mean, at some point, we have to have things that the player does to "play" the game, right? Now, the second, and less stupid answer, is that the ship computer does use the scanner passively when you're not in control of it. But the computer doesn't want to report false positives, so it will only pick up things that are 'certain.' In other words, in passive mode, the computer is going to wait until it can get a solid lock on that object before reporting it. By taking the reigns and using "active" mode, you're actually seeing the raw output from the scanner, which means you can discern and investigate signals long before they can be resolved into objects. I think that's a fair enough justification for why there should be a manual mode :) In general, I want most of the LT gameplay to follow that pattern - engaging with a mechanic is a bonus, not a requirement. You don't have to ever touch active scanning if you're not interested, but if you are, you'll have an edge when it comes to discovery.

After it was all said and done, I had quite a fun time hunting for ore today. Granted, it would have been a much sweeter victory had I actually been able to extract said ore, but...you know...one step at a time ;)

PS ~ Loads of other stuff done today. Like I said, really the "miracle day" I was looking for :) But scanning takes the cake for best dev log material ;)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 26, 2013

#5
Thursday, January 30, 2014

Oh hey, yeah, that's right, I should probably write a dev log now :oops:

BUT! I'm too busy making a video. It's a good video. I like it :) So no thorough dev log today ;)

Besides, I only did about 20 million different things today, so it's too hard to remember. Same story as always before the update. Polish a billions things, make it all very shiny :monkey: (yes, in the time it took to write two sentences, 20 million turned into a billion. I'm not good with numbers; sue me :P ).

See you on the other side :wave: :wave:

:ghost: :ghost:

PS ~ Progress report: filming and overdub complete. Mixing and post-production in process. ETA: 3-4 hours.
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 26, 2013

#6
Friday, January 31, 2014

Wowww.....sorry for the late dev log but..I just woke up from a 15 hour sleep :shock: :shock: That may be a personal record. On the bright side, it means I effectively got almost eight hours of sleep for both today and yesterday :D (even though I never slept yesterday) :monkey:

Well, the update came and went with a fairly moderate amount of pain - not so much on the filming side this time as on the uploading. Still, I'm pleased with how it all went, and rather pleased with January as well! The game is in better and better shape every month, and, more importantly, the subsystems on which everything will rest are quickly coming of age. It's all very exciting :)

Quite a bit of debate already over how the scanner should be modified / why it doesn't make sense, etc. I'm a bit surprised at how many people seem to feel that the lack of spatial correlation with the polar graph is an issue. It's strange, make a cartesian plot of a function over time and no one thinks anything of it. But a polar plot? Suddenly there is an expectation of something more than just value over time :think: A bit odd, but maybe because polar time graphs are not so common. Still, it's the perfect visualization of a ring buffer IMO, which is exactly what the scanner's internal buffer is. Anyway, plenty of time to hammer out the details later :)

Now, I've got a whole load of logistics to attend to today, but I'm fairly certain that there's going to be an expedition into Vvardenfell after that ;)

EDIT : Ok, I want to mention one more counterintuitive thing that I keep reading :think: People keep mentioning wanting faster scanners. But...what? The scanner is extremely fast, it gives you a sample every frame :wtf: I guess you mean...if I made the size of the buffer smaller, then you would see the complete history buffer wiped out "faster"...but the only thing that would do is give you a smaller historical snapshot! You're already getting the signal instantaneously...so if you keep your eye on the radial cursor, you're seeing the signal at the moment that it gets emitted / you receive it. Anyway. Just wanted to mention that :?
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 26, 2013

#7
Saturday, February 1, 2014

No idea how that day came and went so quickly :( Ah well, it was good while it lasted. I got my logistics work done, but, unfortunately, never made it into Vvardenfell. Very regrettable :oops:

Now then. Let's see what February is all about :geek:

:D
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of January 26, 2014

#8
Summary of the Week of January 26, 2014
  • Implemented FBO caching for huge framerate boost!!
  • Implemented emission signatures for use with scanning gameplay
  • Implemented workspaces for nodal UI
  • Implemented preliminary scanner workspace + scanner logic :)
  • Successful 13th development update! :D
  • Set a personal record for sleeping :oops: (on my day off, of course!)
“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 5 guests

cron