Canardia

Couldn't the frame be done with scalable vector graphics instead of using bitmaps? With bitmaps it will look quite different on 640x480 and 1920x1080 displays. Of course you can scale bitmaps also, but then you need some good algorithm that it doesn't look like it was scaled in PaintBrush

DirectX 11 doesn't bring anything which is not in OpenGL 3, it's the hardware which matters. In most cases the new features of DirectX have been already in OpenGL for years, for example the hardware tesselation has been in OpenGL 2.0 since 2007, but in DirectX only since 2009: http://www.opengl.org/registry/specs/AMD/vertex_shader_tessellator.txt

Yes, basically all you need for your home entertainment and game development is just one laptop under your TV, or on your desk. But you just need one, adjust the cables according to that. You save a lot of time with juggling discs and cables when you just have one system for all. No need for a CD player, DVD player, BluRay player, Consoles, just one laptop where you write games and play games. No Console can do that, no DVD player can do that, only a PC laptop can do that.

Although I own a console, I would never play a game on it. It's just a poor excuse to gimp games to have autoaim because the console controllers are not as accurate and easy to use as keyboard and mouse. Consoles are good as long they can play BluRay movies and lay flat on top of the VHS video cassette player. But as soon consoles need to stay upright, and can't play BluRay movies, they are not worth a penny. The PC took over the game platform role from Amiga years ago, so it should keep to its purpose, and it does. I would not support people who want to play games on consoles, it's just ethically not right in my world view. The PC is for playing games, nothing else is.

Yes, I dropped support for BlitzMax, since it's a community project anyway, and I don't have time to support all languages. Nobody needs to use gamelib, but I think it's just a waste of time and resources to reinvent the wheel each time again. If you make a better library, go ahead, then I can stop developing gamelib also and use the better library. But so far I haven't seen anything better. I just want to use libraries which can be reutilized, to avoid rewriting the same code over and over again, for each person. And I don't understand why some people don't want to do that also.

Well, what I see often in the forums is that people ask questions and write code which already has been standardized. I would rather use the standardized code and help to improve it, than rewrite the same code over and over again each time.

But still you have time to rewrite gamelib from scratch I know, it lacks of a updated BlitzMax version, and I can only blame the people who use BlitzMax for that, and don't convert all C++ libraries to BlitzMax. My dream is to have a simplistic and efficient programming interface for LE, which works in all languages.

I think the handling of DLL files is too OS specific to be part of LE. On Windows, the handling of DLL files don't differ much from EXE files, and should be handled as such. Assets, including shaders.pak, are handled with the abstract path system, which is clearly not OS specific, but only LE specific.

It seems your 3rd person cam is missing freelook mode (usually activated by hitting the middle mouse button once), you can copy it from gamelib

Then just copy the 2D functions from gamelib (color, line, rect), as they won't change anyway. The inaccuracy of the 2D functions in LE is just caused by raw/wrong usage of OpenGL functions. A line's horizontal width can never be 0 (vertical can be), and although OpenGL allows it, it's just a theoretical setting which has no practical use, so gamelib adjusts it to be at least width 1, and then it works accurate in all situations. Besides it makes sense to use direct OpenGL commands in the language you are compiling for such functions anyway (which LE allows to be used seamlessly with its own OpenGL commands), since then the full power of C++ inlining and assembler level optimization comes to shine, which is much faster than calling any DLL functions which are calling other functions which are calling other functions. That's why gamelib's 2D functions are 5 times faster than LE's, even if LE would be doing exactly the same thing.

Torque has been always a horror for programmers (I have TGE and TGEA), and I've heard from Torque3D owners (who regret their purchase), that Torque3D is no improvement regarding the spaghetti code. Unity seems quite popular, but it is too outdated for modern virtual reality simulations (it doesn't even have deferred rendering and global illumination). I'd rather use Unigine then, but that's too expensive for Indie developers, so the only choice left is Leadwerks Engine (it's getting GI also, or even SSRT).

Then you can also make a game launcher exe, which does the same thing as the batch file. That SHOULD be good enough even for commercial games. And such launcher exe might be needed anyway, when you change some settings in the game, which need a restart of the game. Yes, GameLib uses Leadwerks commands, but since the Leadwerks Commands are rather API/SDK style commands to do elemental functions, GameLib uses them to create more high level game related functions. For example GameLib's MouseLook() command, which does the same with one line of code as you would need to code yourself with 10-20 lines of code using raw Leadwerks commands.

We should have 3 kinds of tutorials: 1) How to start with LE (doesn't exist yet, although the official tutorials cover an essential part of that) 2) How to use LE (looks like this tutorial is gonna do that) 3) How to make a game with LE as fast and efficient as possible (Power Tutorial tries to cover that)

Is to make games as easily as this: http://fuse.microsoft.com/kodu/ Editor can get very close to that, by creating Thingoids and Models for it. You can make those kind of ad-hoc menus in Editor using Thingoids, and have Models have their own logic so you just place them in Editor, and they get alive.

The simplest way, without modifying the system, would be to make a batch file, like mygame.cmd to start your game: @echo off path c:\games\shared\dlls mygame1.exe Now you can put engine.dll, newton.dll, jointlibrary.dll and any additional dlls you need for all your game projects into c:\games\shared\dlls. Alternatively, you could also modify the system path under My Computer/Properties/Advanced/Environment Variables/System Variables: PATH=<existing entries>;c:\games\shared\dlls

GameLib is a community-created collection of commonly used classes and functions in Leadwerks Engine projects: http://leadwerks.com/werkspace/index.php?/topic/483-leadwerks-community-gamelib/

You have been always able to put the dll's in any directory, just add that directory to the system path (your game can set also its local path in its own environment, so it doesn't change the system path). Gamelib has improved 2D functions, which are 5 times faster and accurate. You can use gamelib, or copy whatever functions you want from it.

They keep moving in straight lines and rotating, that's why I think they are physics bodies without gravity and collision.

I don't know how Josh is exactly doing it, but that's how I imagine it is done, plus how I would do it with the collisions and gravity additionally, and the ragdoll player. The CalcBodyVelocity function is designed to position a physics body accurately, so why should it not do what it's designed to do? And last time I tried it, it worked fine.

It is very exact, plus the position is just half of the truth, the server should tell also movement velocity and rotation velocity.

It doesn't really make any sense to use SetPosition with physics objects (except for initial positioning before the game has started). Then you can use meshes as well. SetBodyForce works accurately, and moves the physics object to the wanted position. It doesn't warp it there.

Of course it's not using SetPosition, but SetBodyForce. Else they would warp from place to place and stop, instead of smoothly moving to their place and continuing the movement when no command is given.

The client still does physics, but no collisions and no gravity. So all physics objects in the client always move in a straight line, until they get a new position from the server, then they move in a straight line to that position. With collisions and gravity enabled, they would also move in curves, and probably wouldn't need much corrections from the server at all. The only time they would need corrections from a server is when a player collides with the objects, but the player positions are done currently on a higher frequency network channel anyway, so it wouldn't matter how slow the objects are updated, they just do their own physics mostly.

Yeah, that's what I would improve too. I would also make the oildrums have collision enabled, and sync them not 10 times per sec, but maybe only 1-2 times per sec, or maybe even every 5 secs. That would require that instead of using the character controller, you would replace it with a real physics body also, like a cube or cylinder. Then it would respond to physics forces more realistically, and doesn't need to be manually pushes around so much. The best would be of course to have a ragdoll physics body for the character.

There is a slight delay anyway with the default character controller acceleration settings. I didn't notice any additional delay due to network lag, but only the normal physics acceleration.