Canardia

The flashlight could also go out of batteries or when you least want it (electrical contact failure when zombies are incoming). It could sometime slowly dim out (player is using lead batteries), or it could go out at once (player is using alcali batteries), or it could last much longer and go out pretty quick (player is using lithium-ion batteries). In case of electrical contact failure, the player could punch it against his hand, leg or head (!), but it would have a chance to completely break then also. He could also remove the batteries and brush them and reinsert them (takes longer, but doesn't have a chance to break the light bulb).

I disagree with that, because I have a different opinion. I think it's OK to have different opinions about things. I think it's not OK to judge people's opinions and tell them what they should do, because of their different opinions

What would be even cooler would be an option to show also the title of the map. The title would be a property in the sbx file. Editor could then have an option for what to show in the window title: 1) nothing 2) filename 3) title 4) filename and title

What do you mean, bug testing is nice, some people even pay lots of money for it!

I'm working with multiple similar maps, and it's sometimes hard to remember which map I have loaded. I suppose it would be just 1 line of code to make Editor to show the currently loaded filename of the map in the window title of the Editor window.

Use Twofish, it's the fastest and most secure encryption: http://www.schneier.com/twofish-performance.html

There are some bug fixes for gamelib and LEO which haven't been released yet, and cause both to crash. The reason is that the new bug in LEO fix causes other (old) bugs B) But Roland is looking now at the LEO issue, and the gamelib issue has been fixed (but not published yet). The Project Wizard itself is OK, only the LEO example might need to be changed when Roland is ready with his research.

Anyway, I tried the demo, and it doesn't go dark enough, seems there is some hardcoded lower limit for ambientlight. The shadows look wierdly triangulated when using 1024x1024 res shadows with high quality shadow mode. When changing the options, they don't activate before you restart the game. In the default "no shadows" mode the flashlight goes through walls. There is no FullHD resolution (1920x1080).

Excellent, I see that you have thought of all customer needs B) No, I just clicked on the youtube video. Now I see that there is a demo too!

It seems the flashlight doesn't cast any shadows. I hope the game has an option to turn full shadows on, else I wouldn't buy it B) I would also like to have an option to adjust the ambient light to 0.01/0.01/0.01, since my monitor is tuned correctly and I don't want to mess up with the monitor tuning to play a game.

You can create a new copy of the model and have non-instanced models. You can even do it while loading the scene, so you don't waste disk space. That's something I planned to have in gamelib also.

Visual quality must improve: Shadows must be sharp when near the object, and blur to distance of object Shadows must start exactly at the object, and not have some gaps [*]Visual limits must be removed Shadows of objects further than 500 units away from camera must be still visible [*]Visual speed must improve When using camera with over 500 units range, the FPS goes down remarkably in big outdoor scenes Fullscreen mode at FullHD resolution (1920x1080) is too slow with heavier scenes Note: I might also upgrade my GeForce 8800 GTS 640MB to overcome the mentioned speed issues

I was just starting to write a simple Menu system in C++, but if you can convert PGUI2 into C++, then I don't have to write everything from scratch. It has been asked by many people to have somekind of UI system, and LCP1 needs it also.

If you look at the cloack of the right side picture, it has more detail than on the left side pic. It's just the ambient light setting which is set too bright. A fully implemented GI, will also cast shadows of the light bounces, so there will be always more details than without GI.

Leadwerks Engine SDK menu option is missing from the Downloads menu.

There is also a weight info, but I still need to add the weighted score column.

GI and a decent AO is basically the same thing. GI illuminates areas, while AO makes more shadows, so the result is the same with a corresponding ambient light setting. I hope the new SSDO will be finished soon and give better results than the old SSAO, then LE would be the only engine on the market besides CE3 which has realtime GI. Then the gap to other engines would widen even more on the 3D engine comparison chart (LE is already now #1 on the chart, while CE3 is 2nd).

The main point of C++ is the huge standard library support, which Lua has also. You can even make a video player in Lua with a few commands.

Couldn't remember it either, but a quick look at the wiki explained it very well: http://www.leadwerks.com/wiki/index.php?title=Cameras#CameraUnproject

It's hard to convince hardcore programmers to use anything else than C++. Lua is the only exception, since it's the best scripting language, and it fits very well as a scripting expansion to C++.

In C++ you can say: DrawText(0,0,"Visible: %d",result); No need for sprintf with DrawText.

That can be written much shorter: int i=5; char buffer[30]; sprintf(buffer,"SCORE %d",i);

I tend to have 3 different kinds of moods towards bugs in the engine: 1) Report bug and continue working on other things 2) Report bug, then ignore bug and if someone asks what's up with screenshots, just say it's a bug in the engine 3) Report bug, then work around bug with hacks, and use the hack as standard method in future also I think option 1) and 3) are good, while 2) can get your motivation down since the bug keeps bothering you no matter how hard you try to ignore it. I actually prefer 3), although I think most people would say that 1) is the best option. With option 3) I can continue working fully on the game, and am not restricted with doing other things only.

HiRes renders can be taken quite easily: 1) Make a graphics window of 1000x1000 2) Set camera zoom to 32x (or whatever the correct factor is) 3) You can now make a loop which rotates the camera to each of the 1024 (=32x32) sectors which each are 1000x1000 pixels, and save the BackBuffer() to disk 4) Now you have 1024 png files, which you can merge into one huge 32000x32000 pixel png file I just realized, that you can use the same technique for extreme good looking anti-aliasing, which works also with deferred rendering. You can have 4x, 9x, 16x, 25x, 36x, 49x, 64x, 81x, 100x, etc... HRAA (=HiRes Anti-Aliasing)

You can use a physics ball to move around, and you can set the entitytype to 0 to disable collisions: http://www.leadwerks.com/wiki/index.php?title=Programming_with_C/C%2B%2B#Moving_around