Canardia

Yeah, I guessed so. I planned to do a wrapper in C# so that the same game code runs on all 4 engines. I think you would benefit from the results too, in case Ultra is slower in some benchmarks (which I suppose will not happen ).

Will you run the benchmarks for Godot 4 and Source 2 too? They both support Vulkan.

One thing I noticed in your code: when slope is exactly 5 or 10 you paint snow.

Not sure, but according to this description, auto variables are slower and constantly reserve and release memory than statically typed variables - even if both are resolved at compile time: What is the difference between an auto and non auto variable? Automatic variables create a new each time when program's execution enters in the function and destroys when leaves. Static variable create once, when program's execution enters in the function first time, destroys when program's execution finishes, they do not again. I would always try to keep variable declarations before the iteration, just to be sure.

Yeah, I read in the Ultra features that various bindings will come, including C#. I really want just one engine which suits all my needs, in private and business. And for business I need to ask @Josh about the licensing.

Why is the lower texture corner rounded?

I was playing around today with implementing a UltraEngine.dll for C#. Using the extern "C" convention worked, but it can't export classes. So now I'm trying to do a C++ CLI/CLR dll which can be used directly from C# including mouseover explanations on each class and its methods in Visual Studio 2022. The reason why I'm using C# along with C/C++ is that it has better integrations with various APIs, so Ultra can be used for business apps too.

Has anyone tried Atlas OS yet? It's an open source OS which replaces Windows 10 and promises to give better performance for games: https://atlasos.net/

I would say your experience struggling with low end machines led (pun: Leadwerks) to study and learn how the best performance can can be achieved with software on current hardware. Therefore your fast pace with getting things done speaks of solid knowledge.

I suggest a SetDoF function, which sets the camera near and far blur range and amount. It was done in LE 2.5 pretty well.

I got this log using event.text: Loading shader family "Shaders/PBR.json" Loading font "Fonts/arial.ttf" Loading shader family "Shaders/unlit.json" Entering main loop: Loading shader family "Shaders/Sky.json" Loading posteffect "Shaders/PostEffects/Refraction.json" Warning: Not enough shader samplers. Using fallback render path. Intel(R) Iris(R) Xe Graphics Exiting main loop. Deleting font "Fonts/arial.ttf" Deleting shader family "Shaders/Sky.json"

When creating a new project, I get a blank dark gray screen when running the program. I updated my drivers to: Vulkan API 1.3.218 - Using Vulkan Device #0: Intel - Intel(R) Iris(R) Xe Graphics

And that GetAngularVelocity() returns (0,0,0) too I guess.

I think the user should only debug his own game code related bugs, and rest assured that the engine is bug free Yes, for engine level debugging such LLVM debugger is better than gdb, but that's what unit tests are invented for also.

If you do a google search on "how to debug games", the first answer is this: http://en.wikipedia.org/wiki/Debug_menu There are some really nice benefits of using a in-game debug menu: 1) You can debug the game even with rarely occuring bugs, when the remote user sends you a screenshot of the menu (or presses some button to send the error report to you). 2) You have the same debug menu on every platform, and don't need to setup complicated debuggers for mobile and other platforms. 3) You can be sure that you are debugging the same code which caused the error, and not some debug compiled version which lacks usually of all compiler optimizations and other settings which often prevent the bug to occur.

I wouldn't say so, because that's what most game developers do: they add a debug hug (which actually was also in LE2 built-in into Framewerk), so they can see the behaviour of different variables in difference scenarios and over longer time. Can't do that by looking at single-step debug code.

I haven't had any problems using a Notify() (SDL_MessageBox) function in GNU C++ as debugging too. Usually debug code behaves differently then release code (often debug code does not show the error at all), so there is no point debugging something different than what is having the problem.

Yay, finally LE works with Code::Blocks and GNU C++ again!

kNet is the best.

Yes, your main function will work as usual, including its command line parameters. Your main function should be always: int main(int argc, char* argv[]) Don't use variations of this, for example argv**, because they are not compatible with some 3rd party libs.

There an much easier way, just insert this line into your source code, no need to change compiler settings or change the main function: #pragma comment(linker, "/SUBSYSTEM:windows /ENTRY:mainCRTStartup")

Some people don't upgrade their software if it works fine. New versions usually bring new bugs and new problems. The only reason I upgraded from XP to 7 was because my new PC had 16GB RAM. Win7 is still horrible and slow, but at least it can use my RAM. Win8 is even more slow and horrible. I think Microsoft has a clear direction: more horrible, more slow is the goal for the next Windows version.

That's good news! VS2012 is so much better than VS2010, although still not as good as Code::Blocks+MinGW.

With physics you can make a game without arts and game logic. That is of course the extreme end example, but linearly it reduces the costs to make a game when you need arts and more game logic.

Just make the mingw32 version and it runs on all windows, and even in Linux WINE.