Jump to content

frednaar

Members
  • Posts

    15
  • Joined

  • Last visited

Posts posted by frednaar

  1. Problem with adjusting scale universally is that you just end up moving the decimal point but the precision problems remain. Say you reduce it by a factor of 10, your near camera object, say you're on the runway, runway markings which might be 1m away, are now 10cm away in real-world and game units. In Leadwerks there's a slight problem, load up the editor, turn on debug physics mode, add an object to a scene and then scale it. Have a look at what happens. *spoiler* the physics shape doesn't scale - oh my */spoiler*

     

    I believe decimal precision errors on floats (and doubles) happens when you use large numbers as the computer moves (floats) the comma to make space for higher digits and deletes lower digits rounding them up or down, this is why you have errors when you move away from the origin but not close to the origin

    I believe the phys file should be adjusted accordingly before importing the mesh into the engine (you have to import a very small jet...) .... but well you are the expert ... I am just exploring LE as you know...

     

    This could also be an idea for a different flight sim, where you fly around garden chairs and tables, this should make for fun dogfights...

  2. After looking at terrain issues in many off the shelf engines for a flight sim I came to the conclusion that possibly the best approach would be a combination of scaling terrain distances down (i.e. using 1m scale on the engine to represent 10m or even 90m) and --if necessary-- reset the world center after player XYZ position reaches certain values (this last step might not be necessary)

     

    This approach might impact on physics but physics can also be easily "scaled down" by increasing for the same amount the object mass (and therefore, forces and moments being equal, scaling down accellerations and velocities),

     

    You would also need being able to access the physics engine moments of intertia (which are accesible in Newton but for some reason not accessible in Leadwerks yet, even though josh could easily add them to the engine), this will affect how fast an object rotates after an inpulse.

     

     

    As Flex says a simulation is a way of cheating anyway but in a credible way, so why not have your jet plane being scaled down to a bee flying over your backyard...

     

     

    Fred

  3. I sent an email to the author of the above book regarding performance of his code which is C# managed + GLSL (throught OpenTK) and here's the reply

     

    "The performance of our C# code is pretty good since most of the heavy rendering tasks are pushed onto the GPU. I don't have the exact numbers, but I want to say our clipmapped terrain example gets around 200 million triangles per second on my laptop with an NVIDIA GeForce 260M. "

     

    So I guess a Native C++ implementation of this (while using the freely available shaders that come with the code) could even improve that.

     

     

    Fred

  4. Mono is not a scripting language per se, it is the Novell Multi platform equivalent of NET Framework and it supports just in time (JIT) compilation

     

    This is like ASP.NET where your code is not executed as a script but compiled just in time (i.e. when it changes or when application starts) so the performance should be similar to compiled Lua.

     

    The framework thanslates any supported language (C#, VB, LUA, Javascript, BOO etc...) into intermediate language which is then compiled by mono in real time upon launching the application (as I understand).

     

    My idea rough idea was about integrating the Mono runtime instead of creating a NET wrapper with P/Invokes . That would allow to program LE with compiled code performance in several languages with a single effort, as well as using Mono Develop as a fully featured code editor.

     

    As Brent says it could possibly be a community project....

  5. I think what most people don't understand is the difference between scripting and coding.

    LE uses Lua for scripting, and it uses Lua and all other languages for coding.

     

    In case of the mono runtime as I understand you would be doing both due to JIT compilation ?

     

    Quote from the above link...

    Mono offers the same functionality that developers have used to extend their application with a safe environment for scripting language with Just-in-Time compiled code.

     

    Scripting languages tend to be interpreted, and as such are not as fast as native code. Mono expands the option of scripting language users to use languages that are suitable to be JIT-compiled into native code. The performance is typically much better than those of a scripted language and many of the high-level language benefits are still available to the developer.

    ....

    Higher-level constructs and game play are typically implemented in a scripting language. The problem that game developers face with scripting languages is that they are usually the major performance bottleneck in a game. After spending years fine-tuning their C, C++ and assembly language code and taking advantage of every little trick in their GPUs, the game play ends up running very slow because the scripting language is just not as fast as it could be.

    ....

    The Unity3D game design engine uses Mono to provide scripting capabilities to the applications and games built with it by supporting Boo, C# and UnityScript (a strongly-typed version of Javascript which helps make the code faster).

     

    Anyway I highly respect any decision made by people 1000 times more experienced than I am... I just throwed an idea as I'd really like to see LE3 meet a huge success...

  6. Hi,

     

    possibly Josh already knows about this article

    Scipting with Mono

     

    this is the way Unity got C#, Javascript and Boo to work in his engine. Even though I am a professional C# programmer I don't know enough about C++ integration to understand how much this would fit into LE3 development

     

    Since I believe many people would like LE approach much more than Unity approach as I did, from the marketing point of view integrating the same scripting languages plus LUA and BMax might give LE3 sales a boost and make c# programmers happy too :D ...

     

    Also multi platform deployment (OS, Linux etc...) would be easier for the average programmer ....

     

    Bye

    Fred

  7. Hi,

    I am starting to go beyond the samples using LE.Net and LEO.net wrapper (thanks a lot for then please keep the good job!),

     

    I am reading an excellent book which is helping me a lot putting things together, It is based on C# and TAO OpenGL but can be quickly integrated into a LW project (which is what I am doing now)

     

    C# Game Programming: For Serious Game Creation

     

    Here's the aUthor's blog and link to source code svn

     

    BLOG

     

    Highly recommended for people who knows C# and wants to start in game programming.

     

    bye

     

    Fred

×
×
  • Create New...