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

Post

Week of September 8, 2013

#1
Sunday, September 8, 2013

Summary

Intended to work on AI today, but the universe had different plans for me :)

Something that's bothered me for a while is that the Mac version of LT looks...very different from the Windows / Linux versions. When I say very different, I mean....you spawn in a totally different universe, the icons look different, the ships look different, etc. Now that's not too surprising, because all of those things are procedural. So I just suspected some platform-specific code in the random generators was causing it.

Today I finally decided to tackle this issue, which I knew had to be dealt with sooner or later. Come release time, I want everyone to be experiencing the same universe when they enter the same seed! Don't want one set of universes for Mac, etc.. :P After some thorough investigation, I was a bit shocked to realize the source of this problem. It actually had very little to do with the way the random computations were performed, and everything to do with the way in which they were used.

Turns out, there's an absolutely evil piece in the c++ standard that says "the order of evaluation of function parameters is unspecified." Now, I always knew that. But I guess I never really understood the consequences until today. I guess it never really sank in. But here's what it means...suppose you have the following piece of code:

Code: Select all

myFunction(randomGenerator->GetFloat(0, 1), randomGenerator->GetFloat(0, 1));
This kind of thing happens all over the codebase, because we're creating things using random generators all the time in a procedural game. The thing is, when you pull a number out of a random generator, it changes the state of the generator (because next time you pull a number out, you want it to be a different number). So, thanks to the c++ standard, this very reasonable and seemingly-well-formed line of code is actually unspecified behavior. Depending on the compiler, the first or second parameter may be evaluated first, and since it changes the state of the random generator, it will cause the parameters to be swapped depending on the order of evaluation. Wow :x

Well, guess what. You guessed it, it just so happens that Clang and gcc implement this differently, hence the major differences in the versions of LT. I never realized just how much of my code was actually not platform-independent.

Honestly, this is not my fault, this is the fault of the standards committee :problem: To have such a perfectly-sensible statement as above causing different behavior on different platforms is totally and completely unacceptable. There are very few places in which I feel c++ really messed up, but I'm going to have to add this one to the list. It's really a great pain and causes a great deal of superfluous code to have to pull those parameters out and manually evaluate them in order before passing to a function call.

In the end, after re-writing a lot of the random-related code, I was able to get the universes to mostly sync up (there must be a handful of bad spots remaining, but I'll find them). But man, this irks me :( :monkey:

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of September 8, 2013

#2
Monday, September 9, 2013

Summary

All over the place today! Not much coherent thought to log, though :oops:

For whatever reason, I feel like I made huge strides in understanding the AI / sim architecture today. Specifically, understanding how events translate to low-level "strategies," as I used to call them. My change in understanding has also brought about a change in terminology. I now look at simulation as comprising events and actions. An action is an "implementation" of an event: it is the concrete change that brings about the event.

The big thing that I realized is that the difference between abstract / concrete simulation is even smaller than I originally suspected (which is great!), and the only logical branching should be taking place at the lowest level: inside the action implementation, not in the event. This has some great properties, namely, it forces a reconciliation of the two "different" types of simulation (which, in an ideal world, are actually not different at all). For some actions, there won't even be any branching, because the abstract version will be the same as the concrete (for example, construction and research events). So with this insight, I feel really good about the interaction between an event and implementation :D

Towards the end of the day I randomly started thinking a lot about lighting and shadows. I've got some ideas that I'm itching to try out..specifically concerning dynamic lighting. I just keep thinking how great it would be if I could see my pulse weapons light up the dust in an asteroid field.....!

I need to keep pushing on AI but I feel the graphics urges creeping up on me. I've got a sneaking suspicion that graphics Josh might be visiting tomorrow. I'd be OK with that :) :monkey:

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of September 8, 2013

#3
Tuesday, September 10, 2013

Summary

Disclaimer: forgive my lack of enthusiasm...it was a fantastic day, but I'm so tired that I'm literally falling asleep at the keyboard as I'm trying to write the dev log right now :oops:

Yep, graphics Josh visited!! :cool:

Super-intense day. Once I sat down I basically didn't stop all day. The graphics just totally took over :D Today's attempt: dynamic lighting in LT.

So how'd I do? Well, mixed feelings. The day wasn't as succesful as last week's distant fog day. But it certainly wasn't a failure either. Dynamic lighting is always a hot topic in real-time rendering, and there are a lot of different ways to approach it, and not really any "perfect" solution (well, not a performant one at least). I implemented a relatively modern technique known as tiled forward rendering / light indexing. But light indexing is usually reserved for DX11-class hardware. My implementation builds the light indices on the CPU, so it works fine under older hardware ;) (at the cost of not being as precise as the DX11-based technique)

Right now I've successfully tested the dynamic lighting in a few areas. It works!! Pulse weapons, for example, now give off a nice glow that corresponds to their color. You can see the reflection of a pulse on your ship as you fire. You can see a diffusion glow around the pulse if you're in a dusty place (that's a pretty nice touch :) ). And, of course, you can see the side of an asteroid light up as the pulse flies by. Cool! Really amplifies the feeling of power when you fire a weapon :D I also tried it out with thrusters, so the back of your ship is now lit up when you're thrusting. And the light changes color when you engage cruise mode (since your thruster trail changes color) - it's a pretty cool effect. You can see nearby asteroids light up a bit orangish as you go into cruise :) No real surprises here - dynamic lighting adds a lot to the game experience.

The reason I'm not jumping up and down with excitement right now (again, other than the fact that I'm about to pass out) is that it's not as performant as I'd like. My desktop can take the technique pretty well, but I'm concerned about the Intel chip in my Mac. It's not having such a great time, as frame time seems to have gone up by 8 ms or so, which is a bit much.

But hey, in all honesty, I should be patting myself on the back. I've never implemented any form of dynamic lighting before today, but now I've implemented one of the most modern techniques and it's already working quite well. I've got plenty of time to learn more tricks and optimize the technique! Like everything else, it's just going to get better and better.

So.....hooorah for another implemented feature that I had absolutely no intention of attempting in the beginning :D :D :D

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of September 8, 2013

#4
Wednesday, September 11, 2013

Summary

With such a cool new graphics feature implemented yesterday, I don't think there was really any choice about what had to happen today: it was destined to be an optimization day ;) 8-)

I'm actually really pleased with what I was able to do today in terms of optimizing the lighting system. I pulled out a lot of tricks, and they paid off ;) I'm now able to run it at 8 lights per tile at very low cost. Awesome!! 8 is really quite a lot: in general only a few lights are ever really affecting one local region of the screen.

So, if the excitement wasn't high enough yesterday, consider it overflowing today :D :D Cheap, dynamic lighting is a go! I think this is going to make a tremendous difference for LT's graphical quality in the long run :)

Now then, I've had my fun...it's been a nice little graphics vacation, but I do think the AI is in need of some attention ;)

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of September 8, 2013

#5
Thursday, September 12, 2013

Summary

Two really productive days in a row...I guess it called for an unproductive one to follow up. Today I just couldn't get in the zone - probably because I haven't slept enough the past two days and my mind was complaining about even the slightest bit of thinking :(

Nonetheless, I started thinking about some of the complexity related to the implementation of abstract docking, and tried to figure out how I could mitigate it. I think I made a lot of mistakes in my first implementation of contexts, and I'm now having to clean them out one-by-one. I think one of the remaining mistakes is using a vector to store a list of objects. This makes removal a bit difficult, and I think is responsible for part of the complexity :think:

My new idea is to move to internal linked lists - that should allow me to remove extremely easily. It also slightly reduces the memory usage :) Unfortunately, it's not trivial to implement, so I'm still working on that...

Other than that, I'm starting to tackle the "go to" event, which is obviously one of the most fundamental and important. The real challenge there is path finding - not because it's hard, but because I have to figure out how I want to handle path finding in a universe that can't be loaded all at once. I came up with a few ideas today that are changing the way I think of the process...give me a bit longer and I think I'll have a good algorithm :)

PS ~ Sorry about the strange hours of the dev log posting - lately I've been sleeping at a new time which overlaps the old posting time :oops:

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of September 8, 2013

#6
Friday, September 13, 2013

Summary

Hehe...listen, I swear I didn't mean for it to be another (awesome) graphics day... :D ;) But...I guess this week is just a graphics kind of week :)

Today I implemented a legitimate lens flare system. I was thinking about lights and such, and I realized that, since I now have a lighting system, I can use it to automatically render lens flares for bright lights as well. What I went on to realize is that a lot of the graphical effects that I've been implementing for various things have been conflated with pseudo-lens-flares!

For example: the glow around the head of a pulse weapon, the glow (and anamorphic streak) around thrusters, the light coming from a star, etc...all of these things I have implemented separately, but really, they are all trying to look like lens flares! And...what do they all have in common? Of course! They're bright lights :) So let's just do it automatically!

Although the flares aren't perfect yet, the full system is in place and looking great. If I can perfect the look in the future, I think this is going to be a major step in the right direction. I was watching the new Elite: Dangerous teaser today, and it really hammered in the importance of lens artifacts.

Oh! Also, another big achievement: I fixed saving today. Next up: loading :oops:

Alright folks I swear I won't get caught in the graphics trap tomorrow....:roll:

:wave:

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of September 8, 2013

#7
Saturday, September 14, 2013

Summary

Really just felt great today :D Not even sure why...it wasn't a hugely impressive day or anything, but for some reason I'm really starting to feel that everything is coming together. I mean, we're obviously a long ways off, but seeing working AI, good graphics, a really solid engine, etc....it's all contributing to a growing feeling of warmth and fuzziness.

That's all good and well, but did I accomplish anything!? Indeed! I wrote (well, re-wrote) AI pathfinding, this time using a very sleek and natural technique that is tightly-integrated into the structure of the game world. All of the details concerning loading / unloading of objects and such should be taken care of. When the time comes to get serious about "knowledge," it will also be very easy to make sure that the AI can only compute routes using navigational objects of which it has knowledge (hence, selling the location of an undiscovered jump hole could completely change the way that NPCs go about their business).

Naturally, I did continue just a bit of work on the lens flare system ;) The big remaining deficiency is a depth pre-pass. I realllllly need to implement a depth pre-pass for a lot of reasons. Light indexing should really be using it. And lens flares absolutely need it so that they can be correctly occluded. Soon enough, soon enough :) Hopefully that will come next week.

It's been such a fantastic week for LT. All of the progress has left me with a smile and a really good mood....and I think those things are only going to make next week even better :) I'm hoping this is the start of a fantastically-positive feedback loop, all resulting from the near-finished state of those beastly conceptual problems with which I've been battling for what seems like ages :ugeek: :monkey:

PS ~ Yep, another weird dev log time...but I decided to write it before bed this time so that I don't sound so dead-tired ;)

[ You can visit devtime.ltheory.com for more detailed information on today's work. ]
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of September 8, 2013

#8
Week Summary

General Sentiment

Just a tremendous week for graphics :) Really nice to have a week like that...kind of rejuvenating for the mind. LT really has never looked so good, and I know the lighting is only going to continue to get better in the future.

So far, September has been nothing but impressive...I'm looking to keep that trend up over the next two weeks!!! :D :monkey:

Major Accomplishments
  • Implemented dynamic lighting :D
  • Implemented a generic lens flare system
  • Implemented AI pathfinding
  • Fixed random generators to yield same results across different platforms
“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