Josh

I agree. Originally I thought people would find that too restricting, but the general desire seems to be to have more of these pre-made things built in, so I won't worry about it. There should not be any problem with that with the current version.

Aggror, everything you listed is planned. I also want to be able to record an AVI from the editor by rendering each frame along a camera path, and then combining the frames into a video file. Far Cry 2, Crysis, STALKER, none of the newer engines use it. I think Unreal only has it because they originally used lightmaps on everything. I'll consider it, but a CSG editor is a very big chunk of work, and I think the results would be a lot of bad blocky level design. The artists I have heard from generally do not like CSG, so I am afraid I would be making a lot of effort for something skilled artists don't usually want. Let me think about it some more. No, I think in the editor you will have some primitives to choose from. Not entirely sure yet how it will work, but you will be able to create lights, emitters, as well as non-entity things like joints and solids. Physics bodies in LE3 will be something you attach to an entity, instead of being an entity themselves.

No, you would just have some creation parameters like width/height/depth, and then attach the solid to an entity. The Quake-style editing isn't something I want to get into.

I'm not such a fan of CSG, even though I wrote a CSG editor. It's been obsolete for about four years now, and it would be a big chunk of time to support something that would give low-quality results. Actually, I am planning on "solids" which are based on my CSG code, but they are for creating triggers and zones, like a block of water, not for making level geometry.

Yes.

See the C++ tutorials package in the tutorials area to download the oildrum with phy file.

That's a pretty slick design. It certainly gives a nice visual studio-esque feeling to the process.

I hope we can do better than that.

Yeah, I agree. As far as I can tell, that will work: SetEntityPosition() GetMaterialTexture() SetJointStiffness() EntityHidden() So yeah, I think that is better. There will be a BlitzMax module because I need one to write the editor. I have a BMX module for Newton that loads the DLL. You can even compile a C++ static lib into a BMX module, and build your program with no external DLLs. Unless something changes in the development plan of BlitzMax 2, there will not be a BMX2 module because AFAIK the language does not support use of external libraries.

You don't download OpenGL. It's included in your GPU drivers. OpenAL is usually already installed, it's also available in Tools/oalinst.exe.

I'll look into it. If I just compiled raknet into the engine, it would be the same as not providing any networking support, for most people. But it might be possible to use this for the internals and provide a nicer interface. I'm actually completely happy with the unreleased networking system I experimented with, except for the lack of NAT punch-through and client-side prediction. Yes, this is supported with OpenGL 3 and 4. CSM is already used, so I am not sure what you mean. I am interested in skewed perspective techniques, but so far have not seen any implementation that didn't have severe problems. This is a definite possibility. I am pretty happy with Newton, but I want the addition of soft bodies and a way to handle large streaming worlds. I will take another look at Bullet, but so far I have not found anything as stable and accurate as Newton. The Penumbra games use a lot of complex joints and interacting machinery, which would not have been possible with PhysX or Havok. You take things for granted like that rolling office chair, but if you tried something like that with PhysX, it would probably explode. A "no graphics" renderer will be provided for making a dedicated server. You can use any of the Leadwerks renderers with an SDL window. You can replace the device input drivers with your own, based on SDL. Depends on how they store they mesh data. If it's polygons, this would not be that hard. if it's some special format, it would be more difficult. The editor can convert PNG images to DDS in a way that is extremely convenient, and gives you full control of all conversion settings. It will even detect changes to the original png files and automatically reconvert them to DDS with the last settings used for each image. The engine will then reload the DDS textures without you telling it to. This is only in the editor, the engine itself doesn't reload stuff because that would get pretty complicated with a game running. Since I will have a C++ source code it will finally be possible to hire outside programmers for things like this.

I would not count on any of your existing programs to compile verbatim in Leadwerks 3. It's a new engine with some differences in the commands and design. LE2 will continue to be supported, and any bugs will continue to be fixed. It's not in danger of becoming obsolete. If you have existing projects being written in LE2, I recommend you continue using LE2 and maybe use LE3 when you start a new one. The documentation for LE3 will not be in the wiki. It will be an entirely new docs system written provided by Leadwerks.

One of the reasons we are using C++ is to facilitate third party libraries. I am very much in favor of developers creating and selling add-ons, or even integrating some select features into the main engine. We have a plan to allow developers to market their work and create a community economy, but I'm not allowed to talk about it yet.

I'd like to note that all capital has a cost that is proportional to risk. When your code is still in the R&D phase, the risk, and thus the cost, is much higher. Therefore although capital is available, the cost at which I could get it right now is unacceptable. You'd have to kiss streaming terrain goodbye, because it would be a new area of research I couldn't accurately estimate. You'd also run the risk of the company being shut down simply because of an error in predicting development time. Or maybe overall game sales decline and the investors get nervous. Or for no reason at all. It's common knowledge that with venture capital, 9 out of 10 of their investments fail to meet their required rate of return. A 90% chance of failure is not something I want to gamble Leadwerks on. Plus, it's easy to end up owning less than 10% of your own company after a couple rounds of funding. You'll also have a group of lawyers in Palo Alto deciding what features you should get, and it would just be my job to carry out what they tell me to do. Nothing I'm saying is controversial; That's just the way it is. It seems to me like this situation creates an environment of adverse selection: A company with little to lose will be more attracted these kinds of deals. Maybe I don't know much about business, but if 90% of your investments are failing, I think there is a big disconnect between entrepreneurs and investors. It would be fun to make a new social networking site or search engine and try to get some money to build it. But gambling Leadwerks like that? I have no problem with an investor's need to make money, above all else. What I do have a problem with is the possibility of the company being shut down for reasons entirely out of my control, even if the financial potential is still good. What's really scary is a lot of investors follow what's "trendy". The way they look at it is "SEO is hot right now. We should have an SEO company in our portfolio". There's an assumption that there will be one big "winner" in the field, and they want to be the one who finds it. If you have a website that does something with Google search results right now, investors will be all over you. It's great if your particular field is "hot" at the moment, but what happens when it goes out of fashion? It also indicates to me decisions are being made on a superficial basis rather than a good understanding of the technology and market. Add to that the fact I believe we are near the top of the second internet bubble. Twitter has raised more than $100 million by providing a free website one smart person could have programmed. That means they are expecting to make a return of more than a billion dollars. Do I even need to explain why that will never happen? Once more of the C++ core of Leadwerks Engine 3 is done, it will be possible to estimate a specific task and the returns it will generate, like an iPhone port for example. At that point the cost of capital will be lower because the risk is lower and the plan to make a return is less open-ended. You can say I need X dollars to hire Y people and make a return Z within Q months. I'd keep the costs low and pitch it to angel investors. I'm going to use my own money first to get as much contracted work done as possible. I am looking for professional programmers for networking code, water, sky, and Lua game scripts.

I don't care about any imaginary standard, but I do agree that SetEntityPosition(), SetBallJointLimits(), GetMaterialTexture(), etc. do roll off the tongue better.

It's less natural than "PositionEntity" but with 300 commands, a naming scheme will save people the trouble of looking up the exact terminology. I have to look it up myself sometimes.

The engine will be compiled as a DLL or static lib, and C command will be included. You don't need a separate header file. The commands will just be the class name followed by the method name. For anything that returns a value, the first part of the method name will be "get". For anything that sets a value, "set" will be used. For anything that queries a state, "is" will be used: entity->SetPosition(x,y,z) EntitySetPosition(entity,x,y,z) entity->IsHidden() EntityIsHidden(entity)

Here is the amazing first shot of Leadwerks Engine 3. Behold not one, but TWO triangles! It's a dual display of isosceles inspiration. Believe it or not, this screenshot actually demonstrates a feature that's new for LE3...hardware multisampling. Look carefully at the edges of the triangle: This isn't the first time I've done multisampling, but until now it hasn't been possible to use with deferred rendering. It's now possible to combine these techniques with OpenGL4. You'll have our awesome lighting combined with high-quality 16x antialiasing for raytracer-like graphics. Oh yeah, multiple layers of transparency, each with proper light and shadows, will also be supported. I ran into problems getting Code::Blocks to import the glew library. Something struck me when I was Googling around for docs. I became aware that most Code::Blocks programmers are probably coding for Linux, and all the examples I read just assumed I was using MS Visual Studio. I didn't give in to the C++ monster just so I could go off on another "non-standard" (if there is such a thing) development route, so I am back on MSVC. I really don't like the poor (or complete lack of) error handling, but I am just going to have to adjust my coding style to this environment. If anyone knows if either the pro version of MSVC or the Intel compiler will stop on the first error and select the line it occurs on, I would gladly pay for that functionality. As annoying as C++ can be, there are some compelling reasons to write the next iteration of our technology in it. First, I need C++ source code to have something I can sell to professional studios. Second, it is extremely difficult to find programmers willing to work in either BlitzMax or C, and dealing with the interface between BlitzMax and C libraries can get ugly. It's not so technically difficult, but you are doing something in the world no one else is, so there's not any support for it. Having Leadwerks Engine 3 written in pure C++ code allows me to work with other programmers who can handle various tasks like networking, some special effects, and ports to other platforms. It also makes it easier to include external libraries for added features. Finally, only C++ can be used for all the platforms I want to support, including Android, iPhone, XBox, PS3, Wii, etc. C++ programmers will like this a lot because the LE3 command set allows them more power than they have had before. It's possible to write your own drivers for physics, graphics, device input, and have it all work with the core engine. You can also extends existing classes. This is particularly useful for entity programming. Should you switch to C++ for LE3? If you've already got another language you're comfortable with, I don't see any reason to. When you are programming a game, flexibility and production efficiency are more important than the raw speed of the final program. Let's say that C++ gave a 25% speed increase over another language. This is probably not realistic, but for the sake of argument let's use that number. That still doesn't mean much, if the user can get a 300% speed increase by switching the GPU or changing some quality settings. So unless you want to support a lot of extra platforms or you just like C++, I don't see any big advantage when it comes to actual game authoring. I need a C interface for use with BlitzMax, because I intend to continue making the editor with that language. Therefore, our policy of allowing you to "code the way you want", with any language you want, will continue. By the way, Khronos has done a really great job with the design of OpenGL 3.1 and onwards. A few points of interest are that immediate mode rendering is finally done away with: glBegin(GL_TRIANGLES); glVertex3f(1,2,3); glVertex3f(1,4,3); glVertex3f(1,2,4); glEnd(); No more! It doesn't make sense to have three different ways of drawing primitives, and it just makes the drivers overly complicated. You should learn the one right way of doing things, from the start. Also, the shaders have all the remnants of the old fixed function pipeline cleaned out. The GPU doesn't have a "color array" or a "texcoord array". It just has vertex arrays and you decide what they are, and what format they should be in. So I can do things like compress surface normals into four bytes and not worry about needing the color array for something else. I didn't get much into it, but it looks like shaders have a nicer implementation of what used to be called "varyings". Variables are just "in" or "out" in the vertex and fragment shaders. Uniforms remain unchanged. I might have a play at geometry shaders, but two years later I am still not sure what they are for, other than something that would have been nice when stencil shadows were popular. Of course, what I am really looking forward to is the OpenGL4 hardware tessellation. Anyways, I am pretty comfortable with C++, and am happy to be back into graphics, my favorite area of technology. Thanks again to Roland Strålberg for his advice with some C++ details. Have a good week!

I'm in favor of providing a built-in skinnable GUI designed for games. I think we'll get a better result with this than a third party library.

Did you change the vertical sync setting in the options in the editor? Since the CPU manufacturers decided to totally obsfucate their hardware through bizarre naming schemes, I can't actually tell how many cores your CPU has.

Lightmapping requires unique texcoords on all geometry. pureLIGHT would export the whole scene as a single collapsed GMF file. It will export materials itself.

Please keep criticism constructive. I think you will find you can voice the exact same concerns in two different ways, and one is rude while the other is helpful. I'm interested to see where this is going, but I also think more progress should be made before a commercial product is released, or at least a better presentation of what it is.

I cannot think of any reason that would cause a problem.

Sorry to hear that. I don't normally transfer licenses, but don't mind making an exception for you. Do you happen to know their user name on this forum, or have the registration key?

I don't see support for iPhone, Android, XBox, PS3, or Wii: http://www.libsdl.org In fact, 2/3 of the platforms I want to support are unsupported by SDL. Otherwise it would be a great idea.