Josh

Curve( targetvalue, currentvalue, divisions/AppSpeed() )

I'm not using this in the engine, at the moment. It's going in the bin of stuff I may do later, maybe as part of Codewerks.

That's somewhat better, but I still don't like this because you always have to have the list and the iterator. Why can't the iterator just remember which list it belongs to? Haven't got to try it yet, but I have the solution here so I can go back to it later.

STL lists suck because they return iterators as objects, not pointers. With pointers, you know if a value is NULL it is no good: Link* link = list.AddLast(o); delete link; link=NULL; With STL iterators, you have no idea whether an iterator is valid or not: std::list<Object*>::iterator it = list.begin(); list.erase(it); //it still hangs around, can't be changed to NULL

I wrote my own LinkedList class that is a lot simpler than messing around with STL iterators. It uses the Leadwerks3D Object class for the link values. I'd like to be able to create lists for entities, integers, strings, or whatever else. Does anyone know how to use templates to make this declarable like stl lists are?: LinkedList<Entity*> list; linkedlist.rar

Excellent. Have you got some milestones planned on the programming side? The thing that will make or break this is the weapon and zombie interaction.

So what's the next step?

I don't know. Any prediction I make is me pulling a date out of thin air. I don't know how long this takes until after I do it.

That would be a good addition. The Far Cry 2 editor actually has the best snapping features I've ever seen. Lay out some curved train tracks and you'll see what I mean. It's brilliant.

Yes, certainly.

If I were to just compile the engine itself for Linux, that's quite a bit simpler. But we can have the editor itself running in Linux, using the native GUI on that distro.

The control widget always shows for each entity in perspective view, including brushes. The control widget shows in orthographic views for all entities except brushes. It sounds a little weird when I describe it, but it's pretty simple and intuitive to use. I'm planning to implement icons for some entity types like lights, emitters, etc. All the properties you see are built into the editor, and appear based on what's selected. You don't need a script for control of the basic stuff.

It's hard to say exactly when it will be done. We're certainly getting closer. I think we're through the scary part.

The built-in level design tools in Leadwerks3D are great for quickly sketching out a game level. Most of this remains unchanged from the design of 3D World Studio, with a few extras like smooth groups and new primitive types: When a point entity object type is selected in the side panel, the object creation widget changes to a simple cross hair: The selection box with tabs that CSG brushes use are great for quickly moving, scaling, rotating, and shearing brushes, but they aren't that great for point entities. That's why I'm implementing a different control style for selected point entities. A 3D widget like 3DS Max uses will appear in the 3D and 2D viewports: To give the user more control, they can choose between global and local coordinate systems to move and rotate entities: We think this will provide the best combination of fast level editing with CSG brushes, and quick object manipulation for other types of objects. --EDIT-- Here's an updated view of the 3D control widget. Of all the implementations of this I have seen, I like the Crysis Editor's the best. The next step will be to make the widget change appearance when the mouse is hovered over it. As has been requested in the past, the widget stays on top of everything drawn, and always scales to appear the same size at any distance.

Porting the engine to Linux should be easy. It already runs on four operating systems, so adding one more at this point is not hard. Porting the editor is more difficult, because there's a lot of GUI stuff that can go wrong. We use a cross-platform GUI library that abstracts the OS-specific stuff, but I have made so many modifications, that I have no idea what will happen when we try to run it on Linux. In the U.S., the average programmer's salary is around $50,000: http://www1.salary.c...r-I-Salary.html I estimate it would take six months to have a Linux version ready. According to the figure above, that's going to cost us about $25,000. Then you figure in the cost of ongoing support, which I am going to say is equal to one half-time worker, or an additional $25,000 annually. So just to break even, my cost is around $50,000 to implement the Linux version and provide support for one year.

If we support Linux, it will be a native build, not an emulation.

Mac is working with the beta right now: http://www.leadwerks.com/werkspace/blog/1/entry-919-getting-fun-now/ Linux may be supported in the future.

One of our design principles for Leadwerks3D is to make development fast. You need to be able to iterate and re-iterate quickly, to try out ideas and make adjustments in as few of mouse clicks as possible. A real-time properties editor is definitely one way to enable that. In the screenshot below, I can adjust the intensity and color of the light dynamically, and see the results instantly. It feels so responsive and natural. I feel like this design philosophy gets us back to our roots with Cartography Shop and 3D World Studio. Those were tools built for level designers, by a level designer (me) who wanted better tools.

The engine doesn't ever deal with triangles in the rendering routine. It just tells the GPU which vertex buffer to draw. In Leadwerks3D, it is possible to replace the rendering module with your own, so you could make a voxel ray-tracer without using my renderer at all.

I don't understand what you mean by triangles being processed. There are draw entity callbacks, but you can't override them with something else.

If you bought less than 24 hours ago, you should already have it.

Enet compiles for iOS and Android. I have no idea whether it actually works yet.

BlitzMax doesn't work on Android or iOS. You can probably use Monkey, though.

I don't have a clear and obvious subject for this blog, but I haven't posted in a while, so I wanted to write something. I've been getting in a lot of hours of development. My schedule on most days is wake up around 7, answer emails or test code on my Mac at home, then head over to the office at 10. Chris usually comes in right around then (we aren't too strict on schedules) and usually hangs around until around 6. I leave anywhere from 6-9 (and totally miss the rush hour traffic), go home, make some dinner, do some light coding until about 10, then play Left 4 Dead 2 for about 30 minutes and go to sleep. I'm having a blast with the editor features. The similarity to 3D World Studio puts us in better touch with our roots and core values, as a company, because 3D World Studio is where it all started. It was an editor borne out of a problem I had as a level designer. I'm picking and choosing the aspects I liked from that program, as well as the overall feel and philosophy behind it. For example, I decided the Leadwerks3D scene file format needs to be binary, not ASCII, because load times are important, both for high-end machines loading complex scenes, and low-end mobile devices loading simpler scenes. It's funny how optimization works both ways like that. The Leadwerks3D scene file format is very similar to the 3D World Studio map file format, with an object and string table. There's no complicated chunk structure designed to account for data types the loader doesn't recognize (which I have never ended up using). There's just a defined file structure, and if anything ever needs to be changed, a simple version number stored in the file will do it. On the other hand, we're calling scenes in Leadwerks3D "scenes" and not "maps". I feel like "maps" is an old-timey term applicable to first and second-generation FPS engines. These systems, while groundbreaking and awesome, didn't put the emphasis on tools that Leadwerks3D does, so I think it's important to get away from the old terminology associated with those programs. If you haven't seen it, there's some really cool work being done with Leadwerks Engine by a few community members. In particular, check out Klepto2's atmospheric scattering and Shadmar's ocean water. The possibility of a Leadwerks Engine graphics module for the Leadwerks3D beta has been suggested, and while I can't promise anything before trying it out to make sure, it is an intriguing possibility. Chris has some really cool particle effects on the way. Working as a team is a new experience for me, and the benefits became apparent to me last Friday. Chris was having trouble with code that makes billboarded particles rotate in the direction of the velocity, relative to the camera. He asked me for help and I tried a few times, then took a guess with a couple of transformation calls that turned out to be right. As a result, we now have an awesome particle system running, and it only took about 15 minutes of my attention to solve on particularly difficult problem. If I had to do that whole thing myself, it just wouldn't have gotten done, but we were able to leverage my skills to get that last piece in place, while Chris is doing a fantastic job with the overall system. However, we will not be going with the slogan I saw on his board the other day.

The AABB is calculated for each entity, not the entity and its children.