[One Little Thing]

**********FREAKING OUT**********

I think it's too complicated.

 

Roland and Stack Overflow have confirmed what Furblog was saying about references and floats, ints, etc. Thank god for full project search and replace.

 

On the docs, rather than editing 600 entries I'm just going to write some PHP that replaces "const float& " with "float", etc.

 

Apparently there is no clear advantage to using const in front of floats either. Well, it depends on the compiler, the phase of the moon, etc. There are lots of situations when it is convenient to modify a float parameter though, so not using const in front of it does give an advantage in terms of flexibility.

 

Of course for things like a Vec3, there is a clear advantage to using const Vec3& because it avoid copying the larger contents of the Vec3 object.

 

I learn something new every day.

[One Little Thing]

A "*void extra" parameter would be a nice addition. The ForEachEntity... callbacks have that.

[One Little Thing]

I guess I got in the habit of doing it when I was passing Vec3 structures around.

[One Little Thing]

Thanks.

[One Little Thing]

You're bikeshedding.

[One Little Thing]

When you pass a variable by reference it doesn't make a copy of it.

[Unit Testing]

That kind of stuff isn't so much a matter of programming as it is a matter of decision-making. Exactly what do you want your AI to do, and how do you define that?

 

A simple attack mode would be "move towards the player until you have a clear line of sight, then start shooting".

[Unit Testing]

They can can't crouch, but they will climb over or go around dynamic obstacles and avoid each other. You just tell them to go to a point, or follow an entity, and you can specify the speed and acceleration.

[Unit Testing]

We're about 40% through the code examples. The last thing will be some level design work so our characters have somewhere nice to run around in.

[Unit Testing]

You should think about optimizing your optimization effort. You have a finite amount of effort and time. Are you going to spend it where it will be effective, or spend all your time worrying about an iterator that doesn't even run in the program loop?

 

It gets back on topic, or else it gets the hose again.

[Unit Testing]

That was a good suggestion. Even the Lua code looks nicer.

function App:Start()

self.window = Window:Create()

self.context = Context:Create(window)

return true

end

 

function App:Continue()

if self.window:Closed() or self.window:KeyDown(Key:Escape) then return false end

 

self.context:SetColor(0,0,0)

self.context:Clear()

self.context:SetColor(0,1,0)

self.context:DrawRect(0,0,100,100)

 

self.context:Sync()

return true

end

[Unit Testing]

I actually like the idea of using context->DrawText(), etc. though. Internally, the drawing commands have absolutely nothing to do with the context class, but it does make intuitive sense considering that you have context->Clear() and context->Sync().

 

So with a few changes, we get this:

#include "App.h"

using namespace Leadwerks;

App::App() : window(NULL), context(NULL), world(NULL), camera(NULL) {}

App::~App()
{
   delete world;
   delete window;
}

bool App::Start()
{
   window = Window::Create();
   context = Context::Create(window);
   return true;
}

bool App::Continue()
{
   if (window->Closed() || window->KeyDown(Key::Escape)) return false;

   context->SetColor(0,0,0);
   context->Clear();
   context->SetColor(0,1,0);
   context->DrawRect(0,0,100,100);

   context->Sync();        
   return true;
}

[Unit Testing]

Context::Create() is the creation function. You can have separate contexts, so it is necessary to call context->Clear(), not just a static function like "Context::Clear()".

[Unit Testing]

The SetPixels() code depends on the data being a known size because that's what the OpenGL texture format dictates. Is there actually any platform that doesn't treat a char as one byte?

[Unit Testing]

The engine and editor are done, unless we find any bugs.

[It's Friday]

My dream is to have a whiteboard that is the entire size of a wall because it'll make me feel important and cool

We have one of those in the main area.

[It's Friday]

The cause of and solution to all of life's problems.

[It's Friday]

Ah, apparently there is a Yelp party here tomorrow.

[Editor Documentation]

Yeah, snippets and simple examples like those on the wiki are VITAL.

See original post.

[Editor Documentation]

Yeah, PDF is actually the format the printer wants, so we have to make it anyways. I don't mind including that.

[Editor Documentation]

Will the documentation be in offline searchable format, like chm?

The docs are online only. Mac and Windows have completely different help systems. I'm not even sure if Windows still supports CHM without any fiddling. I'm looking into having a printed manual produced, in addition to the online docs.

 

I know that feeling you described concerning the usual documentations. Your documentation seems to be easy to understand, and it has structure. I also like the idea of "in case you want to ... then do ...", it feels complete

 

thank you for doing all this

It's something I learned from marketing. You have layers of messages, arranged from simplest to most complex. So you try to communicate the big ideas first, and then drill down to more detail.

[One Last Thing]

The physics presently run on 32-bit floats, so you can get about 8 km away from the origin before you have problems.

 

Entity::GetPosition() returns a dVec3 object. That is a three-component vector that uses doubles for each component (64-bit floats). This is not presently implemented, but the syntax is there for future implementation.

[Happy New Year]

Brushes are entities. If they have no mass and no scripts, they get collapsed when the scene is loaded, otherwise they remain as separate objects.

[One Last Thing]

There's always a tradeoff. In the future we could have three navmeshes for small, medium, and large characters. You would define those sizes in the scene properties, and each entity would just choose one of those three sizes.

 

Crowd pathing between agents from different navmeshes is a problem, but it might be something I can get Mikko to figure out a solution to. However, that's an area to research in the future.

[One Last Thing]

The radius is built into the navmesh data. The actual navigation is calculated with a point with no radius. So the only solution is multiple navmeshes for different sizes, but the characters then wouldn't avoid each other.

 

I don"t worry, recast and detour are opensource so they will just benefit from Josh's future code enhancements.

I'm not going to poke around the innards of Recast. That code is really complex.

 

Will there be any way to turn off the LE pathfinding?

Sure, just don't call the commands set objects to affect the navmesh.