Josh

Well, we're through the "OMG will this even work" phase. Aria got FreeType to build on all platforms, so you can load TTF files directly on Windows, Mac, Android, and iOS devices. I set up the accelerometer input on iOS today, so you can call Device::GetAcceleration() and retrieve a Vec3 telling you which way is down. Acceleration is returned relative to the screen orientation, so you don't have to worry about which way the device is rotated. This isn't my proudest screenshot, but it demonstrates that it works. Gravity is pointing in the negative Y direction, relative to the landscape screen orientation. Multitouch is working on iOS and Android. I am not 100% happy with the way events are handled at this point, but the hard parts are done. I also got cross-platform threads working. I like the Windows implementation of threads better than POSIX, but our Thread and Mutex classes work the same on everything. I use these internally to optimize routines in the engine, and you are welcome to try them, but be warned! Multithreaded programming is not for the faint of heart, and there's a lot of ways you can hurt yourself! I generally avoid use of mutexes at all, and just try to design my routines so that I send a bunch of data to get processed, then get the results. Otherwise it's just too complicated. I had an interesting discussion last week with one developer here, and it led to the decision to start using static class functions for creation and loading commands. For example, instead of CreateThread(), you will call Thread::Create() in C++, Lua, and C#. This gives us a uniform API across all three languages, and it resolves the problems that arise from C#'s lack of global functions. The goal right now is to get all the platform-specific stuff totally resolved and 100% tested so that we can move on and be totally platform-agnostic. That means from now on I can just write code without worrying about whether it's running on Android, Mac, Windows, or whatever. Not much else to say at the moment. Here's a screenshot of the code log to show what we've been working on:

That's why I like Xcode.

Consider it done.

It just depends on the hardware. There is no engine limitation.

I don't know what happened to your post. I actually have a game pad I bought in order to implement this. There is existing code on this forum to do it with C++ or BMX in Leadwerks Engine, and Leadwerks3D will have it built-in.

I'll add this.

Yep. Visual and physical geometry have nothing to do with one another. AFAIK Bullet is one guy.

I implemented direct WAV file loading, and will add OGG as well. The MP3 file format has licensing issues, and we are not going to support it. However, if you use a third-party MP3 converter, the editor will detect whatever converters you add and use them (see more below). We're using OpenAL for sound, but have a more in-depth implementation than in the past. Sound source management is important because you only get so many sound channels on most cards, and this is handled automatically, based on sound range. It's actually quite elegant because sounds are stored in the world octree, and only sounds that intersect the listener are evaluated. This makes it very very fast, and sounds can have any arbitrary range value. You can also get the length of a sample and skip to a certain time. I decided it was important to be able to load TTF files directly. The FreeType library is quite large and isn't set up to compile for ARM processors. Aria has been working on that, which is good because dealing with compiling issues and other people's code is not my strength. I just got word that it was working on the last platform, so I will check it out tomorrow. The direct loading of WAV, OGG, and TTF files got me thinking about textures...could we justifiably load images files directly, instead of automatically converting them in the background? I wrote a BMP texture loader, and although I got the loading and mipmap generation down to 28 milliseconds for a 1024x1024 BGR image, I don't think it's the right way to do things. Textures and models are complex files, and it's best to have the editor automatically convert them to our own TEX texture format when a change on the hard drive is detected. The only disadvantage is that if you are coding and working in Photoshop, you have to either leave the editor running or open and close it, if you want your TEX files updated. Or you could drag the image file onto the appropriate converter, but we know from experience that is unacceptable. I think automatic conversion of these files is best because: Not all conversion code can be included in the engine library. The Autodesk FBX SDK, for example, isn't even available for ARM systems. Some libraries like FreeImage, which is needed to load PSD files, are enormous. FreeImage compiled as a static library is 17 mb! That is way too much bloat for a mobile app. Automatic conversion means you can add support for new file formats just by dropping a converter in the "Tools" folder. I want to show you how the directories are laid out in the Leadwerks3D installation folder. Instead of switching your asset path around in the options whenever you want to load assets from a directory, we're going to use a concept of "projects". When you select a project, Leadwerks3D starts loading all assets from that directory, and sets the project's "Maps" folder as the default open/save directory for maps. When you are ready to make a distributable game, Leadwerks3D will read all the maps and scan source code files for asset files, and copy only the asset files you use into your final distributable game. Root directory: Templates for all supported languages: A sample C++ project: C++ and C# project files for Visual Studio, Xcode, and Eclipse are stored in a "Build" directory, each with a subfolder for the platform. This is how we manage the Leadwerks3D source code, because all those compilers can create a ton of extra files you wouldn't want residing in your main project folder: Finally, I started the OpenGL2 renderer tonight, which is aimed to be identical to the OpenGLES2 renderer. This is my primary focus for now, as it is important to have one uniform renderer that looks the same on all platforms. Of course advanced graphics is our specialty, and I have already done all the research for new effects when I finish the OpenGL 3.2 and 4 renderers. Deferred rendering will work on OSX Lion, multisampled deferred rendering is already working on Windows, and other stuff like per-pixel motion blur is done. We're nearly to the point of having a usable game programming library for four platforms, and only have one more library to compile for mobile. It's coming along nicely! B)

It's done like this in Lua: test --[[ test test test ]]-- test

It works here.

I would, but that involves another file format change. If I knew that was going to happen, I would not have relied on it in the first place.

Please post your files so we can try ourselves.

I'm thinking a 2D drawing tool would be nice, with the ability to form concave shapes and have them triangulated correctly.

No, it's a significant reworking of the way collision shapes are handled. If introduced into LE2 it would definitely create new bugs, so I'd rather just focus on the new engine. It's also using a newer version of Newton, so it would probably require a reworking of all .phy files, and that went very badly last time I did it. The joint strength issue is sort of a non-issue, in my opinion, because the person who posted it was using joints between bodies with big big differences in mass. That's going to cause problems no matter what. I have found the existing joints to be very stable, and if anyone can show me otherwise I will look at it. If joint stability is a concern, then I don't see PhysX offering any advantage there...from what I have seen it would probably be much less stable. As far as visualizing joints, that's not something I need the physics lib to support, I just add it myself. PhysX might have some built-in helper function for that, but honestly we're talking like one hour's work to set it up for all joints. The people who are most likely to make use of it are the flight sim people. I have gotten a ton of serious requests from flight sim companies...for some reason they are attracted to LE, but they want even bigger worlds. That's something we can do uniquely well in the future, and no one else is going to pursue it because they are designing engines to run with 256 mb shared memory. Also, if we can offer big worlds, it does mean a lot of sales. It's not my business to tell people what they can and can't do. I like the idea of driving on a limitless road and stopping to kill mutants.

Speaking of, I just updated Newton from the repository and it looks like version 300 has soft bodies, or at least an early implementation. I'm pretty satisfied then. There are some weird things about physics in LE2, but I think careful planning can avoid those issues we experienced before.

Maybe you have only a back-facing polygon, so there is nothing to cast a shadow and block the light?

Shadows?

Brush geometry uses lightmaps, not vertex lights. I opened one of your maps and it had no lighting information, so press the lighting button and do that first, then export.

I don't understand this question.

Does anyone know how to register a new MIME type and create an ActiveX control that calls a local DLL on the user's machine? I am not trying to download and call a DLL, just call an existing one. It should work on IE, FF, and Chrome.

I recommend using it, but if you don't want to, you can look at the source.

Discuss here: http://www.leadwerks.com/werkspace/topic/3135-physics-library/page__view__findpost__p__36554

I am using Newton because: -PhysX guarantees all the cool open-world stuff I want to do down the road is impossible. There's just no way we can do it. I talked to the guy in charge of PhysX at NVidia. It can only handle 40-50,000 bodies, not millions like we are used to. -I have been able to get scaling working with Newton, it just took a lot of careful design that's hidden from the end user. -I have the source to Newton, and the only area I find it lacking in is soft bodies. It's possible I can some day add my own soft body implementation in Newton. It's impossible for me to ever add 64-bit float support or vegetation into PhysX, because it's closed source. PhysX development revolves around consoles, so the memory constraints of those guarantee large worlds are not a priority. This is pretty much what NVidia told me, in different words.

I think I know what is happening. Previously, the base texture was ignored and now that I fixed that, it appears black if there is no base texture. I should add a white texture that gets used in its absence.