Rekindled Phoenix

I would highly recommend .Net WPF applications, vector based replacement to WinForms. Using a collection of Custom Controls (similar to Winforms) and mouse-drag events you could easily make a WPF application. Because of the design, the drawing of vector based shapes like the lines and rounded boxes in your picture are much easier to create than inheriting DirectDraw code which forces you to use custom Paintbrushes. *shudder* Take a look at what you can do with WPF http://images.google.com/images?q=wpf+application I have had to design several WPF applications using both code and XAML (not XML), designed specifically for .Net WPF applications. It is ages beyond WinForms, and I would never go back. (It also allows you to take advantage of the GPU using DirectX if you are so inclined to adapt a 3D version, but that is probably unnecessary.)

That is wonderful news. I'm really glad the new API will be abstracted so that dedicated servers may run in a production (non-rendered) setting. Not to mention future updates to the engine can use whatever renderer they want! This would allow you to choose physics engines, and give the user much more flexibility. Thank you for your prompt reply Josh

Okay, so if I wanted a Server with Physics elements displayed on the clients window, I am forced to render to a buffer. Josh, when could this be patched / updated? Would it take alot to add an optional command so that a graphics buffer isn't required, but the physics and engine entities still update?

ALSO the ability to run physics updates without forcing a window to be rendered. (Networking Servers)

I'm confused. So you can load models in memory, but in order to instantiate them in the virtual world you have to call Graphics()? I specifically remember Aggror's Server only running in a console. http://leadwerks.com/werkspace/index.php?/topic/1242-ball-game-example-third-person/ How did he get it to work???

Rivers that are Node based like roads, or... Realtime deforming water that uses terrain! Yaaaaaaaaay! http://www.gamedev.net/community/forums/topic.asp?topic_id=526062

Is it possible to update the graphics / physics in a world without needing to visually display anything? I'm programming a Server / Client Network library to share with the community, but it seems I must have a render window. Someone on the old forums created a Multiplayer LE server where you controlled a sphere and knocked other players off. That only used a console window, which proves that it's possible... If so, could you paste some example code?

What do you mean coordinate picking vs. coordinate comparison? Do you mean engine ray-casting picks? I have found that keeping a collection of clickable regions / textures per pixel is the simplest way to handle UI. Application Callbacks and .Net Events have overhead with additional threads, this is just simple math with no heavy lifting. ButtonMinX < MouseX < ButtonMaxX Resizing elements: ? I've been working on resizing objects for different resolutions to avoid restraints. I start by creating a base size for an object, as a example we can imagine a loading bar with 200x50 pixels. As the resolution changes compared to your base minimum resolution, your buttons and clickable space may alter with simple math. Do you guys think that it's better to enlarge UI elements based off resolution or keep them a particular size and just let those who own HD screens squint? I just wish that the engine came with this naively as an option. It's nice to be able to customize, but if you just want a "placeholder GUI" for demos, you have to code the entire thing yourself. FACEPALM Josh, can this be a priority in LE 3.0?

This post caught my eye because I've written a GUI that handles 3x3 textures, click, and hover events for my projects. If the documentation / business requirements stated what you wanted Josh, I'm sure a few programmers (including myself) would be up to the task. Though, would this be using LE Source or a plugin DLL / library?

Can't we call LoadScene() and either... 1. Cycle through another loop as a separate thread waiting for a callback to tell us the scene has loaded all necessary layers. or 2. Allow LoadScene to display a predetermined loading screen specified to the engine by a property / MAT object.

River creator just like the roads! (Which has already been created, just not part of the engine natively)

Thank you for all your hard work!

Wow this look fantastic! I can't wait to try this out at home

That solves part of the problem. Thanks ZioRed Have you tried moving the object over 100 units away from the camera or waited 30 seconds after the collision occurs? The collision events work fine in my code, but now the object is culled or reallocated and ends up killing the process. Why would distance cause a problem?? Soon I'll compile a working demo, upgrade to VS2010, and update the C# Wrapper to 1.32.8

I guess the problem is that you are compiling the DLL in .Net 4.0. Is there a specific reason for this? Unless you are using multi-line lambdas, I don't see a valid reason to compile past 3.5. Think about what your user is going to have to download to play. This would force all XP and Vista users to install .Net 4 in order to play the game, which means a couple hundred MB with 3.5+ http://en.wikipedia.org/wiki/.NET_Framework "54 MB for .NET 3.0, 197 MB for .NET 3.5, and 250 MB for .NET 3.5 SP1" "NET 4 installer ... being 54 MB and not embedding full runtime installation packages for previous versions" Meaning... 300MB+ EDIT: Does C# really not have optional parameters before 3.5??

Thanks TylerH, I've found the GameEntity class and converted it to VB, and still am having issues. When the physics body 'AmmoBody' collides with the terrain, OnCollision() within the GameEntity object are fired and so is my DeclareCollisionToScreen() method. Though, the main thread never seems to return to the render loop, throwing an access violation exception. Here is my code: Is this the correct way of implementing collision detection using your GameEntity class? TylerH, could you provide a working example? VB 'Create a physics body Dim AmmoBody As Body = Body.CreateBox(0.2, 0.2, 0.2) 'Set it as a GameEntity class object Dim GameEntityObject As New GameEntity(AmmoBody.Pointer) 'Create handler to throw event Dim CollisionDelegate As New GameEntity.CollisionEventHandler(AddressOf DeclareCollisionToScreen) AddHandler GameEntityObject.Collision, CollisionDelegate 'Method that's fired Sub DeclareCollisionToScreen(ByVal Sender As Object, ByVal e As CollisionEventArgs) DrawText(e.Entity0.ToString, 50, 50) End Sub C# (Online converter) //Create a physics body Body AmmoBody = Body.CreateBox(0.2, 0.2, 0.2); //Set it as a GameEntity class object GameEntity GameEntityObject = new GameEntity(AmmoBody.Pointer); //Create handler to throw event GameEntity.CollisionEventHandler CollisionDelegate = new GameEntity.CollisionEventHandler(DeclareCollisionToScreen); GameEntityObject.Collision += CollisionDelegate; //is converter correct here? //Method that's fired public void DeclareCollisionToScreen(object Sender, CollisionEventArgs e) { DrawText(e.Entity0.ToString, 50, 50); }

That's odd. I can't use any of the DLLs past 1.32.4

Authentication for the SVN repository would be best to ensure what Lazlo is worried about doesn't become truth. Though, I don't think there is a rush to do so, the engine is still developing. Again, anyone else have issues with 1.32.6+ ??

Thanks for the update ZioRed, but for 1.32.6+ ... whenever I import it says 'system cannot find the reference supplied' VB VS2008 Express - Vista x86

When you save a file outside of the editor and return to the window, your updates or replacement of the file should reflect the new model. This is invaluable when porting assets from Blender where you are constantly making tweaks to the texture, and can save hours of time. This can be done In several different ways: - Iinitiating an event when the player re-enters the window. Then checking a Base64 encoded byte hash of the file, comparing both. - Use a filewatcher and detect an updated file event LINK: Windows FileWatcher - Give a squirrel a hammer and update each time it smashes your hard drive. That is how many source code development suites compare files, including 'FileGrabber', an in-house backup program at my work. I'd really like to see something like this implemented in the near future, as it would speed up the content pipeline to production. If the Unity editor can do it, I'm sure Leadwerks can as well.

This is something similar to the way I'm handling onscreen click events. Your implementation is more thorough than mine.

Even with implementing 'FreeEntityCallback', the LE unmanaged code frees and entity with a managed delegate, and my application crashes. How do I 'detach' the managed delegate from the object before the application frees the memory space?? With access to only the delegate / callback in managed code, how do I tell LE to remove the handler for that object so it doesn't crash my program? Could someone please update the headers, and if possible, provide a working code example?

Again these are really professional looking models. I can tell you that I am bursting with anticipating for the release of this game. Keep posting screenies!

I'm a big fan of dragons, and I keep coming back to this screenshot. Awesome work NA.

It's been a while. Would you be able to work on this sometime soon? I'm holding out on the LE Control until it's got a stable release.