Josh

There's not really any practical limit: There are constraints, and one of them is the shadow updating. The lesson posted above will help with that. If you are experiencing poor performance with a simple scene, I suspect the problem may be something very simple.

Unless you have a huge number of surfaces per mesh, the geometric complexity should matter very little. With Leadwerks you take an initial performance hit to get lighting and effects running, but it scales really well as you add more objects.

I can compile it, but it seems incomplete and unsupported.

Has anyone here done much work with wxMax?

Works for me.

I use this to merge a series of bitmaps into an AVI. It's the only tool I found that can produce AVIs over 2 gb with this method.

You need this program if you are recording movies from the editor: http://www.fxjoinersplitter.com

The sickle and hammer look a bit 2D. Soviet artwork tends to be very round and muscular. http://t0.gstatic.com/images?q=tbn:0b2oq8U7bqrThM:http://i4.photobucket.com/albums/y131/JaronGilinsky/hammer.jpg It 's a weird combination of rounded shapes made out of angular surfaces.

How did you make the skybox?

Look for this at GDC 2011, hopefully running in LE3.

Well, he did say "guys".

Archon, if you purchase 2.32 now and upgrade to 3.0, it will be cheaper than just buying 3.0. The price may increase when 2.4 is released, so buy 2.32 now and get the free upgrade to 2.4. alphabit, the upgrade period ended officially over three months ago, but I will send you a link to upgrade if you like.

We have something better in the works for 2.4.

There is a way to do this with lighting intact. The roads are one example. Will look at it when I get out of bed. i'm typing on my phone right now . actually i m just speaking into it

i don't think it's possible to do a project of this scale without funding. but it will go a lot smoother if i lay some ground work first

Version 2.4 is a free upgrade from 2.32. My goal is to reduce risk before external funding and additional programmers are added into the mix. It's like the difference between the people who experienced the teething problems of ~2.22 and the developers who joined after the much more stable version 2.31. It's easiest to add people to an already establish structure, where they each have their own subsystem to work on. My estimates for porting the source to C++ have ranged from 6 weeks to 9 months. I have no idea how much effort it will be. I could estimate it, but any arbitrary number would be as valid as another. Therefore I think it is important for me to make some headway on this myself before involving anyone else.

I feel like you guys are owed an explanation of our long-term strategy, and now that I have definite plans I am happy to reveal them to you. I've been spending a lot of time in the Silicon Valley area, and have learned a lot about business. We've been investigating external investment. I believe we could raise pretty much any amount of money we want, based on the fact we already have an existing business that is self-sustaining, and we have a great strategy. However, money does not necessarily equal success, and funding brings more restrictions. If we raised $10 million, our investors would expect a $100 million return, and everything we did would have to be geared towards that. If you recall the Blade3D story, you know what can happen when these deals go bad. I believe the wisest strategy for the development of Leadwerks 3.0 is for me to buckle down and write the majority of the C++ code, then add additional programmers once the foundation is in place. This allows me to carefully design the core functionality without external pressures. It ensures I don’t trust the engine core to some programmer that may not understand our design objectives. Finally, it forces me to tame that beast that is C++. Even if my future is more of a management role than programming, I still need to be able to evaluate future employees’ work. Once I feel the project is ready for more programmers, we may seek funding, but we’ll be in a less risky position at that point. Another thing I have learned is how great networking is. It’s fun, and it can lead to valuable contacts. I live two hours from San Jose, so there is no excuse for me not to be more involved in the game industry. From now on, I am going to attend more IGDA and other events. I may find some good programmers to hire later on, or it may lead to new partnerships like the one I will be announcing with version 2.4. For many developers, Leadwerks is your portal into the game industry. If I am more in involved with what is going on, then by extension you will be, too. Leadwerks 3.0 will be written in C++, but will still support all the languages we do now. Every part of the code that interfaces with the hardware will be abstracted out as a “driver”. This includes graphics, sound, the file system, and networking. To add support for a new platform, we will just write a new set of drivers for that hardware. The editor will continue to be written in BlitzMax because development time will be shorter and the end result will be fast and cross-platform compatible. To begin with, I am most interested in Windows and Android, but eventually plan on supporting everything. The abstracted driver design we are using makes it possible for separate teams to work on porting the code independently. I’ve received a lot of great feedback from the community, especially on the tools and workflow. The design of version 3.0 makes it easier for users to just click and drag some items around to make a game, but you can still drill down to the script and programming level, when you need more control. The most intriguing aspect is how it lets advanced programmers work together with designers, and they all can make valuable contributions to a project. Leadwerks Engine 2.4 will be out soon, and will include a brand new lighting feature that has never been done before, by any engine. The bug tracker is presently clear of reports, but if anything comes up in the future, it will be fixed and patched. After 2.4 is released, I will be going on a short vacation, and when I return work on Leadwerks 3.0 will begin in earnest. We will begin offering the 3.0 beta for sale at a generous discount only to existing Leadwerks Engine 2 developers. When will it be done? I don't know, but I will have a better idea after working with the C++ code for a while.

Agreed. I think something like SyncEntity() is ideal, where it is just automatic, and then other info would just be raw data. Physics and entities are the only part of networking that I think the engine should have a heavy hand in.

There's going to be more high-level options, but it's being done in a way that won't cramp your style. As always, Leadwerks is designed for producing games, and won't be dumbed down to appease novices. Ease of use is important in terms of efficiency. If I can make it easier for you to set up your game rules and then start producing levels, in a way that doesn't inhibit flexibility, then that is the kind of high-level interaction I can get on board with. I think 3.0 will appeal more to beginners than the current version does, but that's because it gives you levels of interaction. In fact, an expert programmer can work with a few beginners, and everyone will actually be able to contribute meaningful work to make a game.

Some of these assets will be available for use with Leadwerks on the main site. I am setting up a store for content packs.

It's interesting that this scene is unplayable without LOD models, but runs fine with LOD.

I agree 100%. Many people would have said "a puzzle game with physics? It's been done." But look what it evolved into.

I don't think he was talking trash. I have pointed out as much in my blogs. It's a common problem for all developers. My own experience before I committed to a definite design with Metal is that I enjoyed imagining infinite possibilities, and committing to a concrete idea changed that. From that point on, I was working on something where I knew exactly what the end product would be, and the fun of imagining what might be was lost. Of course, as I built a structure up I had more fun with what I created. My favorite part of production was testing AI in that orange foggy level. Towards the end of it, you will have things you wished you had done differently, and you will have features you wish you had added, and you will feel like it's not as good as it could be. At that point you need to finish it, release it, and then start a new project. As they say, "It doesn't mean sh** if it doesn't ship".

Given how badly networking code ports across platforms and how little our professional users care about these two features (they usually already have some library they want to use) I am not too worried about the decision to not focus on these. I think we will eventually have some built-in official solutions, but it's not a high priority. I'd like to focus on what we do best, and not try to recreate libraries that have already been done and aren't that difficult. The GUI will be implemented at the script level. Building that into the core engine doesn't make sense to me. I do have some network code that is a little unique, and it is really handy for syncing entities across a network, but I am not ready to reveal it.

Lumooja is correct. This bug is fixed in the current version.