Josh

I think you can set the light quality setting higher, it seems like there is very little edge filtering on the shadows. I also felt the controller needed more friction with the ground. It slides quite a bit which can make some jumps tricky, like that really hard part in level 3. You have basically as many lights as you want, at no cost, so I would use them! A side scroller with awesome graphics is a niche, but it has little competition, so I would push the graphics to their full extent. I could definitely see this on Steam. Can't wait to see what you do with this next.

There is a section for community tutorials here, and you can upload attachments with your post: http://www.leadwerks.com/werkspace/page/Documentation/LE2/tutorials

In all seriousness, I want the lowest-level thread access possible so I can understand what is happening on all platforms completely. I also don't like compiling more libs into the engine because almost every time I do there is some little thing I have to fix. I take it I can just start calling pthread commands on Mac, iOS, and Android?: https://computing.llnl.gov/tutorials/pthreads/#CreatingThreads

I wasn't thinking about this too much yet, but I don't know. We have some pretty challenging requests for the terrain system, and it will be a big chunk of work just to figure out how it should work. People want really really big terrains, so this might fit into that design.

Leadwerks Engine 2 is single-threaded. The engine performs one task at a time. The engine updates physics, then performs some other tasks, then renders the scene, waiting until each task if finished before moving onto the next one: I have experience programming threads in BlitzMax, and it works pretty much the same way in C++. Leadwerks3D is taking full advantage of threads and multicore CPUs, splitting off any expensive tasks that can be run on separate threads. Multithread programming is a little different than linear programming, and you just have to design things carefully. It's okay for two threads to read a variable at the same time, but if they both try to write to the same variable, or one writes while another reads, you will have major problems. This is made harder by the unrestricted nature of Leadwerks, because the end user might call any function at any given time, and I don't want to make arbitrary rules like "You can't modify surfaces during the main game loop". Mutexes (short for mutually exclusive) are a way around this, as they lock sections of the code to prevent multiple threads from accessing them at the same time, but I try to avoid using them. It's extremely difficult to find all the parts of your code that might need a mutex locked. Also, when you start using mutexes liberally, you lose all the benefits of concurrency, because the threads have to stop and wait for each other. I prefer a design where you gather data for a thread, run the thread without interacting with any other parts of the program, and then get the results a few frames later, or whenever the thread finishes processing. Multithreading has some big benefits for the new engine. Physics Physics in Leadwerks3D are asynchronous, meaning that while the engine renders the scene and executes your game code, it's already calculating the next frame of physics on a separate thread! The diagram below shows how the physics get split off onto its own thread, then split into many threads by the solver, and the two threads meet again the next frame. (It's actually more complicated than that, the engine just keeps running until 16.667 milliseconds have passed, then it waits for the physics thread to finish, if it hasn't already.) Let's say our ideal framerate is 60 FPS, which means our target frame time is 16.667 milliseconds (=1000/60). Whereas before a physics processing time on a single thread of 10 milliseconds would eat up 2/3 of your ideal frame time, now you can have physics that take up to 16 milliseconds, and have no performance cost for a program that is otherwise running at 60 FPS. Below you can see 5000 bodies falling at near real-time speeds: NavMeshes Navmesh generation is a slow process. However, it does not need to be instantaneous. This makes navmesh recalculation perfect for multithreading. As you can see in this video, the obstacles can move around and the AI navigation will react dynamically to the environment. I've never seen a game with dynamic environments like this, so we are breaking totally new ground. As CPU core counts rise the engine will be able to use those cores to handle more complex maps and greater numbers of characters. In the meantime, it will perform well on any dual-core mobile device! Rendering Rendering in Leadwerks3D will split culling up among threads to take advantage of multiple CPU cores. This is not yet implemented, but it's a little easier than physics and navmesh threading, since it doesn't run concurrently to the main engine thread. Below is a diagram showing the complete threading design for the engine: Multithreading in Leadwerks3D is all done automatically behind the scenes, so you can still program however you want, without fear of interfering with other threads.

I didn't even realize you could wall-jump until the second time I played it: 39:7

The default controls were very awkward, Space or up arrow key should be jump. Control should be shoot. Enter should be push or whatever that third thing was. I really liked when 3D details in the foreground came up out of the screen, it felt almost like it was popping out of the monitor.

Because I am part of a vast conspiracy to keep Linux from becoming popular. Every little bit helps.

Eh, I got it figured out. Here's a nice little thread class if you need it: #include "../le3.h" #ifdef WINDOWS namespace win32 { #include <windows.h> } #endif namespace le3 { const int THREAD_RUNNING = 1; const int THREAD_FINISHED = 0; const int THREAD_PAUSED = 2; const int THREAD_READY = 3; class Thread { public: Object* result; #ifdef WINDOWS HANDLE id; int state; #endif Thread(); ~Thread(); virtual void Wait(); virtual bool Resume(); virtual bool Pause(); virtual int GetState(); virtual Object* GetResult(); }; Thread* CreateThread_(Object* EntryPoint(Object* o), Object* o=NULL); } #include "../le3.h" namespace le3 { Thread::Thread() : result(NULL) { #ifdef WINDOWS id = 0; state = THREAD_PAUSED; #endif } Thread::~Thread() { #ifdef WINDOWS if (GetState()!=THREAD_FINISHED) { TerminateThread(id,0); } #endif } bool Thread::Pause() { #ifdef WINDOWS if (SuspendThread(id)!=-1) { state = THREAD_PAUSED; return true; } else { return false; } #endif } bool Thread::Resume() { #ifdef WINDOWS if (ResumeThread(id)!=-1) { state = THREAD_RUNNING; return true; } else { return false; } #endif } int Thread::GetState() { #ifdef WINDOWS if (state==THREAD_RUNNING) { DWORD lpExitCode; if (GetExitCodeThread(id,&lpExitCode)==0) { //Function fails return THREAD_RUNNING; } else { if (lpExitCode==STILL_ACTIVE) { return THREAD_RUNNING; } else { return THREAD_FINISHED; } } } else { return state; } #endif return 0; } void Thread::Wait() { while (GetState()!=THREAD_FINISHED) { //win32::sleep(1); } } Object* Thread::GetResult() { if (GetState()!=THREAD_FINISHED) return NULL; return result; } Thread* CreateThread_(Object* EntryPoint(Object* o),Object* o) { Thread* thread = new Thread; #ifdef WINDOWS thread->id = CreateThread(NULL,4,(LPTHREAD_START_ROUTINE)EntryPoint,o,CREATE_SUSPENDED,NULL); if (!thread->id) { delete thread; return NULL; } #endif return thread; } }

I got started with win32 threads. I think I'd rather use my own class and just use macros to control the different behavior than to use something like Boost. How can I check the status of a thread? I need to be able to tell if a thread is still running. See Thread::GetState(): Thread.h #include "../le3.h" #ifdef WINDOWS namespace win32 { #include <windows.h> } #endif namespace le3 { const int THREAD_RUNNING = 1; const int THREAD_FINISHED = 0; const int THREAD_PAUSED = 2; const int THREAD_READY = 3; class Thread { public: Object* result; #ifdef WINDOWS HANDLE id; #endif Thread(); ~Thread(); virtual bool Resume(); virtual bool Pause(); virtual int GetState(); virtual Object* GetResult(); }; Thread* CreateThread_(Object* EntryPoint(Object* o), Object* o=NULL); } Thread.cpp #include "../le3.h" namespace le3 { Thread::Thread() : result(NULL) { #ifdef WINDOWS id = 0; #endif } Thread::~Thread() { #ifdef WINDOWS if (GetState()!=THREAD_FINISHED) { TerminateThread(id,0); } #endif } bool Thread::Pause() { #ifdef WINDOWS if (SuspendThread(id)!=-1) return true; #endif } bool Thread::Resume() { #ifdef WINDOWS if (ResumeThread(id)!=-1) return true; #endif } int Thread::GetState() { #ifdef WINDOWS #endif return 0; } Object* Thread::GetResult() { if (GetState()!=THREAD_FINISHED) return NULL; return result; } Thread* CreateThread_(Object* EntryPoint(Object* o),Object* o) { Thread* thread = new Thread; #ifdef WINDOWS thread->id = CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)EntryPoint,NULL,CREATE_SUSPENDED,NULL); if (!thread->id) { delete thread; return NULL; } #endif return thread; } }

I am not new to multithread programming, but I have never done it in C++. I want to create a thread to execute a function, and be able to tell when the thread is finished. The code should run on Windows and OSX. If it can run on Android and iOS, that's great, but I don't expect it to. Where can I find a simple example that shows how to do this?

Awesome.

I just changed some permissions to allow regular members to post there. It was set to only allow Leadwerks Engine developers.

No, that isn't a problem. I'd just rather have the report in your name than my own, so I don't get confused later, and I sometimes message people when their problems are solved. I'm not sure why people are so resistant to using the bug tracker, all you have to do is copy and paste your first post in this thread.

3D World Studio stores meshes with Euler rotations. You may need to flip a few signs to get the eulers to match the coordinate system in XNA. I think someone has already done a loader for XNA, though, so you might want to look at that.

The bug tracker will reflect any changes in the status of this issue.

Thank you. Can you please file a bug report here so this can get fixed?: http://www.leadwerks.com/werkspace/tracker/project-2-3d-world-studio/

The way I find visible outlines in CSG calculations is as follows: Each edge occurs between two faces, right? And each face has a normal. A normal either faces towards or away from the camera (or perpindicular to, but we'll call that "away"). For each edge, if one face's normal points towards the camera and one points away from the camera, that edge is a visible outline edge. For arbitrary geometry, this will require some more detailed data structures than just a vertex and indice array, but for cubes you can probably figure out something simpler.

Does this occur with the current version of 3D World Studio, version 5.6?: http://www.leadwerks.com/werkspace/files/file/231-3d-world-studio-demo

Some interesting observations here. It seems like for premade models, it's all or nothing. If a single character has a value of n, a complete pack of characters has a value greater than 10n. So it would be best to focus on producing large sets of complete game assets instead of individual items.

I opened your scene in the editor and set the time of day to 12 noon and don't see any problem: Don't set the light range to 7500. By default it is around 300. With directional lights, this is the depth over which the shadow is rendered, from the point of view of the light camera, when rendering the shadow. The second value of SetShadowDistance() should always be 1.0 for directional lights. 1.1 will render a slightly larger range of depth, skewing the results towards the shadow camera the further away a pixel is. 0.9 would tend to stretch the shadow away from the shadow camera. These values can be useful for point lights, because you can't use a linear shift and get the edges of the cubemap to line up, but multiplicative will work. Without a scene that demonstrates the problem I cannot help you any further.

You should not need to manually cull anything. If you scene is slow, you need to think about cutting it down. The engine can handle an enormous amount of geometry, so I think you must be causing some extreme inefficiency in your scene. I can't say more without seeing a scene file.

My guess would be a problem with the texture file.

I was at a shopping center this afternoon wasting time, and came across a hobby shop. I can't quite articulate what it is about stuff like this that I like, but this is what I want game development with Leadwerks3D to be like. This is why I set up the Leadwerks Asset Store and make the effort to make nice thumbnails with transparency to show off items in 3D. I want more game development to be a process of producing reusable components, and then at the design level, of picking and choosing which components to utilize. This is the kind of stuff I used to do as a kid, which undoubtedly paved the way for my future work in 3D graphics. I particularly like the packaging on the box in the first image: "You can do it!" I should use that. B) Post your thoughts below.

PointEntity() only rotates an entity.