DCS update engine request--- scripting engine to C++

[pappachuck]

For Example, there are transcoding capable A.I such OpenAI Codex that can translate code, debug, test, and deploy.

I think now is the time to transform DCS into a modern game. Scripting is limited and inneficient. Also, going into C++ expands the horizon on possibilities from Graphical upgrades, audio, better models, better physics, ....

 

Codex also can help you guys code with new toys like Vulkan.

I absolutely love DCS and would love more than anything see it evolve and come around as the most modern Flight Sim with the best engine in market.

 

Quick programming language translation using OpenAI Codex

 

https://www.youtube.com/watch?v=RUCUxFHtJvw&t=128s

[StevanJ]

This is very wishful thinking..

If they did this, I could optimise and patch DCS myself..

[cfrag]

On 9/23/2021 at 12:19 PM, pappachuck said:

Scripting is limited and inneficient.

 

Mhh... even if that was true, how would using a different coding language change that? DCS's scripting restrictions are architectural design, and not determined by the programming language. C++ would change nothing. I'd love to hear your argument on what is currently inefficient in DCS scripting and how a different language (as opposed to architectural changes) would fix that. 

 

On 9/23/2021 at 12:19 PM, pappachuck said:

Also, going into C++ expands the horizon on possibilities from Graphical upgrades, audio, better models, better physics

 

Why? How is that true? I'm not even sure what you mean by half of that. Specifically, what does

• Horizon on possibility (OK, I'll bite: What horizon inherently defined by using Lua can c++ expand on?)
• Graphical Updates (the scripting environment isn't connected to the graphical pipeline. How will switching to c++ change that?)
• better physics (the physics engine isn't exposed to the scripting engine. How will switching to c++ change that?)

(lets skip the rest, you get the idea) mean when it relates to Lua vs c++ in the scripting environment? Perhaps I'm just unimaginative - do you have some concrete examples? Can you point to a single issue on that list above and tell me how switching to c++ over Lua would change anything? 

 

More to the point, I believe you may misunderstand what OAIC does. It can translate Lua to C++. That's not difficult; any first-year IT student can write a similar parser in a couple of hours (lazy students can download the source for a Lua->C translator from GitHub and add c++ specifics in minutes). The problem then is that the resulting C++ code must be compiled by a c++ compiler, then bound to c++ libraries and then run on a c++-LLVM - which is what Lua already does (it currently compiles to Lua bytecode, links to Lua-specific libs and runs on a Lua LLVM). So you end up where you started, except now your source code is in c++ - what is the benefit of switching to c++?

 

I'm sure there are some good cases that can be made to open the scripting environment on an architectural level to threading, storage, networking, control authority, mesh access, physics engine, graphics, audio etc. But that has nothing to do with the actual scripting language we use; and it will invariably open up a ton of security concerns. The scripting environment is locked down for good reasons, and I'd hate to compromise my computer by using a game that can load custom missions that has willy-nilly read/write access to my storage and network. If you come up with a good proposal, I'll be there and cheer it on. Switching to c++ "because reasons and horizon of possibilities" isn't one.

 

 

Edited September 27, 2021 by cfrag

[gamerbwoi]

9 hours ago, cfrag said:

 

Mhh... even if that was true, how would using a different coding language change that? DCS's scripting restrictions are architectural design, and not determined by the programming language. C++ would change nothing. I'd love to hear your argument on what is currently inefficient in DCS scripting and how a different language (as opposed to architectural changes) would fix that. 

 

 

Why? How is that true? I'm not even sure what you mean by half of that. Specifically, what does

• Horizon on possibility (OK, I'll bite: What horizon inherently defined by using Lua can c++ expand on?)
• Graphical Updates (the scripting environment isn't connected to the graphical pipeline. How will switching to c++ change that?)
• better physics (the physics engine isn't exposed to the scripting engine. How will switching to c++ change that?)

(lets skip the rest, you get the idea) mean when it relates to Lua vs c++ in the scripting environment? Perhaps I'm just unimaginative - do you have some concrete examples? Can you point to a single issue on that list above and tell me how switching to c++ over Lua would change anything? 

 

More to the point, I believe you may misunderstand what OAIC does. It can translate Lua to C++. That's not difficult; any first-year IT student can write a similar parser in a couple of hours (lazy students can download the source for a Lua->C translator from GitHub and add c++ specifics in minutes). The problem then is that the resulting C++ code must be compiled by a c++ compiler, then bound to c++ libraries and then run on a c++-LLVM - which is what Lua already does (it currently compiles to Lua bytecode, links to Lua-specific libs and runs on a Lua LLVM). So you end up where you started, except now your source code is in c++ - what is the benefit of switching to c++?

 

I'm sure there are some good cases that can be made to open the scripting environment on an architectural level to threading, storage, networking, control authority, mesh access, physics engine, graphics, audio etc. But that has nothing to do with the actual scripting language we use; and it will invariably open up a ton of security concerns. The scripting environment is locked down for good reasons, and I'd hate to compromise my computer by using a game that can load custom missions that has willy-nilly read/write access to my storage and network. If you come up with a good proposal, I'll be there and cheer it on. Switching to c++ "because reasons and horizon of possibilities" isn't one.

 

 

 

 

Both Java and Lua are compiled to bytecode, rather than being native binary code.

This makes them both slower than native binary code.

Since games are all about frame rate — the faster the software runs, the better.

C and C++ compile to binary code.

They run fast.

Game engines and games therefore get written in C and C++, because they are trying to make the hardware perform at the limits of what’s possible.

Edited September 27, 2021 by gamerbwoi

[cfrag]

17 minutes ago, gamerbwoi said:

 

Both Java and Lua are compiled to bytecode, rather than being native binary code.

This makes them both slower than native binary code.

Since games are all about frame rate — the faster the software runs, the better.

C and C++ compile to binary code.

They run fast.

Game engines and games therefore get written in C and C++, because they are trying to make the hardware perform at the limits of what’s possible.

 

 

That is all understood, and true within limits (if we replaced the Lua VM interpreter with Lua JITC we could get up to 99% of the speed compiled c/cpp gets). Yet OP asserted: 

 

On 9/23/2021 at 12:19 PM, pappachuck said:

Scripting is limited and inneficient.

 

and that

 

On 9/23/2021 at 12:19 PM, pappachuck said:

going into C++ expands the horizon on possibilities from Graphical upgrades, audio, better models, better physics, ....

 

I fail to see how replacing Lua with C++ as coding language would give any of the listed benefits. Going compiled code would merely accelerate script execution -- which can be had much easier by replacing the LuaVM Interpreter with a Lua JIT Compiler. Unless ED radically changed the scripting environment that embeds the running code, "all" we get is faster scripts with the same limitations. Most times though, scripting isn't the bottleneck. I've seen missions that install callbacks that get invoked 100 times per second (most mist-based missions do so by default). In the current environment, scripts run fast enough. And if we could get a separate thread for scripting, execution speed would be a moot topic.

 

Again - I'm open to proposals on how to improve the scripting environment: access to the render pipeline, mesh data (model and world), storage (!!! please, we need the ability to persist data for missions so we can save & resume !!!), network, audio, threads, etc. But this has nothing to do with the programming language that we write the source code of the scripts in. Because computer languages are merely the way we express our thoughts to the computer. This is then transformed into something the computer can understand by the compiler. Looking at the resulting binaries after compilation, you'd be hard pressed to tell the difference whether the source code was written in c, cpp, c#, Lua, D, Eiffel, Oberon, Ada, Forth, Pascal or any other compiled programming language (if you used a LLVM system like CLang, it'd be impossible because all source code is translated into a meta representation first). Given the same algorithm written in Lua, C++, Oberon and Swift, the resulting binaries are almost identical after compilation (with a good optimizing compiler, that is).

 

The source language is just a tool and should be chosen for purpose;  Lua is exceedingly well suited for it's purpose in DCS (easily accessible, small footprint, type safe, secure, managed memory). C++ may also be used for scripting, but it would be much, much more difficult to use for many casual mission builders (difficult and obnoxious semantic, gigantic footprint, type unsafe, memory unsafe) and comes with no tangible benefit (well, perhaps multiple inheritance, but if you need that in a DCS mission script, you ain't in Kansas any more, Dory). In DCS, the scripting language itself is not the issue, and IMHO Lua should be kept. The scripting environment (the framework surrounding the scripts and provide API to the script) may be worth taking a look at, though.

 

 

[TLTeo]

Buuuut the parts of the DCS code that actually matter (and do physics, and graphics, etc etc) are already in C++? And it's not like lua is *that* limited either - the A-4 folks coded a freaking a2g radar with it, before ED had their own!

Edited September 27, 2021 by TLTeo

[Tippis]

On 9/23/2021 at 12:19 PM, pappachuck said:

Also, going into C++ expands the horizon on possibilities from Graphical upgrades, audio, better models, better physics, ....

…arbitrary code execution on the client, data loss, lawsuits, all the good stuff.

 

The use of scripting languages for the purpose of scripting content is limited by design, and any inefficiencies are marginal given how small a portion it represents of the overall processing, while at the same time vastly increasing the accessibility to the end users. The expansions you're envisioning are not covered by the scripting engine; are already all done in C++; and can already be changed by replacing the associated DLLs. That's modding, though, not scripting, and there are very good reasons not to open that up to the users.

Edited September 27, 2021 by Tippis

[Buzzles]

5 hours ago, gamerbwoi said:

 

Both Java and Lua are compiled to bytecode, rather than being native binary code.

This makes them both slower than native binary code.

Since games are all about frame rate — the faster the software runs, the better.

C and C++ compile to binary code.

They run fast.

Game engines and games therefore get written in C and C++, because they are trying to make the hardware perform at the limits of what’s possible.

 

DCS's core engine is already C++.

Are you aware that pretty much every game engine has seperate timing loops for the rendering loop and the 'game' loop? It's basically the default design where they execute the game loop at a desired target rate (ie, 30 times a second), and any spare cycles are given over to rendering.

You'd not want to strongly couple script execution with the game loop either, and I'd expect the scripting engine loop in DCS to be seperate and have it's own timing window. You don't want the scripting to slow down game loop. You'd normally only do external script execution only a few times per second too.
 

At which point given such big windows, executing in a couple of ms in c++ vs a few tens of ms in lua makes no difference, both are just executed once in the window. One is definitely easier to code and maintain though, and offers more flexibility for non devs.

 

Edited September 27, 2021 by Buzzles

[Mars Exulte]

*sees above reasoned arguments*

  Wrong! Everybody knows when encountering a new advertisement the only acceptable response is to repeatedly throw your wallet at the screen. All these technical facts are just what the regressive traditionalists holding us back want you to think!

[Tippis]

11 minutes ago, Mars Exulte said:

*sees above reasoned arguments*

  Wrong! Everybody knows when encountering a new advertisement the only acceptable response is to repeatedly throw your wallet at the screen. All these technical facts are just what the regressive traditionalists holding us back want you to think!

Look, if you're not getting a check in the mail for shilling on behalf of the nebulous backwards tech council, how else are you supposed to pay for your module and increasingly bloated HOTAS setups? Think of the children!