Josh

The problem has to do with the lighting equation in the fragment shader. If I comment out the lighting code, the box appears. Now to figure out exactly what is wrong...

BTW, 2D drawing works fine. 8O

I'm really baffled. Lots of games run fine on my iPad 3. I've never seen anything like this on any graphics hardware.

Apple's problems in iOS 6 aren't limited to maps. Their OpenGL drivers in iOS 6 are absolutely non-functional. First I was experiencing a BAD_EXC_ACCESS error when rendering certain surfaces. Feedback on the Apple dev forum suggests I am not alone in this. I took a guess and switched my position vertex buffers to use vec4s instead of vec3s, and it appears to have solved that problem (even though both should be fine). Second, all 3D objects just stopped appearing, completely. I've debugged it to the point of absolute barebones, and still can't get anything to show up...but only on the iPad 3 device itself. My iPhone 4 (also running iOS 6.01), the iOS simulator, and even my HTC Evo all appear fine, running the same code. My guess is that the Apple driver team was given a directive to get the speed of their graphics chip up to be competitive with the latest 12-core NVidia Tegra, and that they gained speed by fine-tuning the drivers for specific applications they were testing with, at the expense of compliance with the OpenGL ES specification. In a world where the graphics device performance between all targeted hardware can vary by 1000x, compliance with the OpenGL spec is paramount. Performance at the cost of reliability is not an option. I also have come to the conclusion that OpenGL is just a fundamentally flawed API. Programmable shaders have been around since 2003-ish, and the vendors still can't write drivers that work. I take this as an indication that the OpenGL specification is just too complicated. Anyways, this is one of my more emo blogs, and I will solve the problem, but that's where I'm at today. Considering the amount of non-working **** we deal with on both Android and iOS, it's clear to me that for most developers, cross-platform development is just infeasible. I'm glad we can figure this stuff all out for you, so you can just use our API and not worry about all the mistakes third parties make with their APIs, drivers, and tools.

Yeah, but at that point, does it matter whether the file name is goblin2-3_tex or FIDHJDJHFKJDF? You can just run the publish tool from the editor again if you want to modify something. I don't really expect people will be poking around in the projects/android/res/raw folder anyways.

You guys won't believe this. You actually can't have two files with the same name, ignoring the file extension. For example, you can't use both "goblin2.tex" and "goblin2.mdl". I guess my original random name design was best.

Sorry for the delay.

I'm planning on the same physics features as Leadwerks 2, and then soft bodies and real breakage are two good candidates beyond that.

Not even I can do that...

One small change I am going to make this morning is to leave the file names the same, by default, unless a duplicate file name is encountered. If that happens it will have a dash and number added to the end like this: truck.mdl truck-2.mdl I think this might turn out to be handier in some situations, and it works the same. It will check for existing file names, so if you really do have a file with that name, it will increment the suffix and check again.

Is supported in our physics library but its not a high priority for the initial release.

In my previous blog I talked about the Android file system and APK package system. The end result was I copied all the project assets into the res/raw folder. However, I learned two additional things that changed my plan a little: Android files can only be lower-case. Any folders in the res/raw folder will not get copied...it just packs in the files in that directory, with no sub-directories! That's a big problem if we want Leadwerks to be able to load files the same on each operating system,but I came up with a solution. In the asset copy step, took the asset files and gave them a random name like "jfuendjhgdjkhfndlrhgjfkd". I stored their original path and their new nonsensical path in a text file. When the engine starts, it reads this text file and sets the files up in a virtual file system, so calling Model::Load("Models/Characters/Goblin.mdl") will load the gobbly-gook file behind the scenes, and the user will never know the difference. This is implemented and it works right now. I'm going to try to automate the final publishing step as much as possible to save everyone time. I also learned how to change the name of the Android application so we can just auto-generate the Eclipse project for you based on the values you enter in the project creation wizard.

For an RTS game you would have a lot of repeatedly used AI and behaviors. I'd probably use Lua for that.

Today I am working out the file system for Android applications. In the past we just manually copied all our assets to a "/Leadwerks" folder on the device itself. This approach is okay for testing, but it won't work for distributing apps in the Google Play store. Android uses APK files to store all applications in. An APK file is really just a ZIP file, and all your assets go in a /res/raw directory in the ZIP package. To access the Android file system from C++, we had to take the following steps: 1. Retrieve the file path to the application APK file (with Java). 2. Pass this file path to C++. 3. In C++, load the APK file as a standard zip package. 4. Change the current directory to the APK folder path + "/res/raw". All this occurs before the App::Start() function is called, so as soon as you start, you're ready to access all the files your game needs. It's nice when things work out neatly like that.

http://www.leadwerks.com/werkspace/page/tutorials/_/programming/introduction-to-animation-r11

Wow, they actually have a fancy name and a diagram for such a simple idea?

The Asset class destructor actually looked like this before my changes: Asset::~Asset() { this->assetreference->instancecount--; if (this->assetreference->instancecount==0) delete this->assetreference; } So it was really the same thing, just with a lot of extra classes in an attempt to continue using "delete" when it really isn't appropriate.

This makes the problems you listed go away. For example this code will only load the texture once, and at the end it will delete the texture: Texture* texture = Texture::Load("myimage.tex"); material->SetTexture(texture); material2->SetTexture(texture); texture->Release(); texture = Texture::Load("myimage.tex"); material3->SetTexture(texture); texture->Release(); material->Release(); material2->Release(); material3->Release(); In your entity pointer target example you could have incremented the reference count, used Release() instead of delete, and you would have been safe. (I renamed the IncRefCount() function to AddRef() to match the COM syntax, which uses an identical system). Your wizard update function might have looked like this: if (activetarget->GetKey("health")<=0) { activetarget->Release(); activetarget = NULL; } Setting the target might be like this: void Wizard::SetActiveTarget(Entity* entity) { if (activetarget) activetarget->Release();// decrement the ref counter of the old one, if it exists activetarget = entity; if (activetarget) activetarget->AddRef();// increment the ref counter of the new one so we can hold onto it }

I think object interaction can get very convoluted. We solved this problem by implementing a flowgraph to provide a visual framework with which scripted objects in a scene can interact, based on what functions are exposed in the attached scripts. This way users can control object interactions with fine control, without worrying about the exact code in the scripts.

Here's my list, as it stands today: Lua Interpreter project for iOS and Android (iOS is done, Aria is working on Android) Improve flowgraph visual style (will finish today, probably) Documentation (Chris is filling out the syntax, then I will go in and write descriptions) Brush rendering batches (to make editor rendering faster) Brush collapse on load (in engine only) Undo system

That's exactly what it does. So you'll implement your own ref counting system, and then instead of a standard one built into the engine, we'll have a dozen non-standard approaches, all trying to make up for lacking functionality. :\

It uses events.

Also, native code is faster and more flexible than the walled garden of managed code. 98% of AAA games (not an actual statistic, but probably accurate still) are built with native code, not C#. Even most iOS games are built on native code. I would also be hesitant to rely on a closed-source proprietary compiler like Mono. The company has a rocky past, and I don't know if managed code is very future-proof. So native code (C++) is where I would put my bets, with Lua for fast and easy scripting (still running in C++).

You do not need to call IncRefCount(). It's just used internally. You would effectively be writing your own engine at that level. If I load a model, for example, and then delete the model, it's reasonable to expect the model's materials, textures, and shaders to also get deleted if they are no longer in use. I looked up COM and it's identical to what I am doing. Maybe I will even make the syntax match it exactly.

The alternative to having a memory management system like this is either memory leaks or invalid pointer deletion crashes. Or I could just make every call to the asset load functions uniquely load the data, and your video memory usage would increase 100 times.