kandi background
Explore Kits

OpenSAGE | open source reimplementation | Game Engine library

 by   OpenSAGE C# Version: v0.3.0 License: LGPL-3.0

 by   OpenSAGE C# Version: v0.3.0 License: LGPL-3.0

Download this library from

kandi X-RAY | OpenSAGE Summary

OpenSAGE is a C# library typically used in Gaming, Game Engine applications. OpenSAGE has no bugs, it has no vulnerabilities, it has a Weak Copyleft License and it has medium support. You can download it from GitHub.
OpenSAGE is a free, open source re-implementation of SAGE, the 3D real time strategy (RTS) engine used in Command & Conquer: Generals and other RTS titles from EA Pacific. Written in C#. Not affiliated with EA.
Support
Support
Quality
Quality
Security
Security
License
License
Reuse
Reuse

kandi-support Support

  • OpenSAGE has a medium active ecosystem.
  • It has 975 star(s) with 102 fork(s). There are 67 watchers for this library.
  • It had no major release in the last 12 months.
  • There are 40 open issues and 81 have been closed. On average issues are closed in 256 days. There are 14 open pull requests and 0 closed requests.
  • It has a neutral sentiment in the developer community.
  • The latest version of OpenSAGE is v0.3.0
OpenSAGE Support
Best in #Game Engine
Average in #Game Engine
OpenSAGE Support
Best in #Game Engine
Average in #Game Engine

quality kandi Quality

  • OpenSAGE has 0 bugs and 0 code smells.
OpenSAGE Quality
Best in #Game Engine
Average in #Game Engine
OpenSAGE Quality
Best in #Game Engine
Average in #Game Engine

securitySecurity

  • OpenSAGE has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.
  • OpenSAGE code analysis shows 0 unresolved vulnerabilities.
  • There are 0 security hotspots that need review.
OpenSAGE Security
Best in #Game Engine
Average in #Game Engine
OpenSAGE Security
Best in #Game Engine
Average in #Game Engine

license License

  • OpenSAGE is licensed under the LGPL-3.0 License. This license is Weak Copyleft.
  • Weak Copyleft licenses have some restrictions, but you can use them in commercial projects.
OpenSAGE License
Best in #Game Engine
Average in #Game Engine
OpenSAGE License
Best in #Game Engine
Average in #Game Engine

buildReuse

  • OpenSAGE releases are available to install and integrate.
OpenSAGE Reuse
Best in #Game Engine
Average in #Game Engine
OpenSAGE Reuse
Best in #Game Engine
Average in #Game Engine
Top functions reviewed by kandi - BETA

Coming Soon for all Libraries!

Currently covering the most popular Java, JavaScript and Python libraries. See a SAMPLE HERE.
kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.

OpenSAGE Key Features

✓ .map

✓ .w3d

✓ .wak

✓ .wnd

✓ .csf

✓ .ini

✓ .ani

✓ .dds

✓ .tga

✓ .const

✓ .apt

✓ .wav

✓ .mp3

✓ Render 3D models loaded from .w3d, including animations

❏ Render maps loaded from .map (in progress)

❏ Render particle systems (in progress)

❏ Render GUI loaded from .wnd (in progress)

❏ Scripting engine (in progress)

❏ APT virtual machine (in progress)

❏ AI - Path finding, base building, fighting

❏ Physics engine

❏ Weapons

❏ Locomotors

❏ Input (keyboard, mouse)

❏ Network play

❏ Much more…​

✓ Windows

OpenGL 4.3

Direct3D 11

✓ Mac

Metal 2 (requires macOS High Sierra)

✓ Linux

OpenGL 4.3

This project is not affiliated with or endorsed by EA in any way. Command & Conquer is a trademark of Electronic Arts.

This project is non-commercial. The source code is available for free and always will be.

OpenSAGE is nowhere near playable yet, but when it is and you want to play Generals or Zero Hour with it, you will need to have a legally acquired installation of one of those games. OpenSAGE uses data files from the original games. You can purchase [Command & Conquer: The Ultimate Collection through Origin](https://www.origin.com/twn/en-us/store/command-and-conquer/command-and-conquer-the-ultimate-collection/ultimate-collection).

This is a blackbox re-implementation project. The code in this project was written based on reading data files, and observing the game running. In some cases (for example refpack decompression) the code was written based on specs available on the Internet. I believe this puts the project in the clear, legally speaking. If someone at EA disagrees, please talk to me.

If you want to contribute to this repository, your contribution must be either your own original code, or open source code with a clear acknowledgement of its origin. No code that was acquired through reverse engineering executable binaries will be accepted.

No assets from the original games are included in this repo.

[Arda](https://github.com/feliwir/arda)

[smx-smx/openSage](https://github.com/smx-smx/openSage)

Community Discussions

Trending Discussions on OpenSAGE
  • Floating point determinism for gamedev in .NET Core
  • How do I get Visual Studio 2017 / msbuild to use the latest DirectX shader compiler?
Trending Discussions on OpenSAGE

QUESTION

Floating point determinism for gamedev in .NET Core

Asked 2019-Mar-14 at 06:20

Background

We're working on an RTS game engine using C# and .NET Core. Unlike most other real-time multiplayer games, RTS games tend to work by synchronizing player inputs to other players, and running the game simulation in lockstep on all clients at the same time. This requires game logic to be deterministic so that games don't get out of sync.

One potential source of non-determinism are floating point operations. From what I've gathered the primary issue is with the old x87 FPU instructions - they use an internal 80-bit register, while IEEE-754 floating point values are 32-bit or 64-bit, so values are truncated when moved from registers to memory. Small changes to code and/or the compiler can result in truncation happening at different times, resulting in slightly different results. Non-determinism can also be caused by accidentally using different FP rounding modes, though if I understood correctly this is mostly a solved issue.

I've also gotten the impression that SSE(2) instructions do not suffer from the truncation issue, as they perform all floating point arithmetic in 32- or 64-bit without a higher precision register.

Finally, as far as I know the CLR uses x87 FPU instructions on x86 (or that was at least the case before RyuJIT), and SSE instructions on x86-64. I'm not sure if that means for all or most operations.

Support for accurate single precision math has recently been added to .NET Core, if that matters.

But when researching whether or not floating point can be used deterministically in .NET there are a lot of answers that say no, although they mostly concern older versions of the runtime.

  • In a StackOverflow answer from 2013 Eric Lippert said that if you want to guarantee reproducible arithmetic in .NET, you should "Use integers".
  • In a is discussion about the subject on Roslyn's GitHub page a game developer said in a comment in 2017 that they were unable to reach repeatable floating point operations in C#, though he did not specify which runtime(s) they used.
  • In a 2011 Game Development Stack Exchange answer the author concludes that he was unable to attain reliable FP arithmetic in .NET. He provides a software-based floating point implementation for .NET, which is binary compatible with IEEE754 floating point.

The question

So, if CoreCLR uses SSE FP instructions on x86-64, does that mean that it doesn't suffer from the truncation issues, and/or any other FP-related non-determinism? We are shipping .NET Core with the engine so every client would use the same runtime, and we would require that the players use exactly the same version of the game client. Limiting the engine to only work on x86-64 (on PC) is also an acceptable limitation.

If the runtime still uses x87 instructions with unreliable results, would it make sense to use a software float implementation (like the one linked in an answer above) for computations concerning single values, and accelerate vector operations with SSE using the new hardware intrinsics? I've prototyped this and it seems to be work, but is it unnecessary?

If we can just use normal floating point operations, is there anything we should avoid, like trigonometric functions?

Finally, if everything is OK so far how would this work when different clients use different operating systems or even different CPU architectures? Do modern ARM CPUs suffer from the 80-bit truncation issue, or would the same code run identically to x86 (if we exclude trickier stuff like trigonometry), assuming the implementation has no bugs?

ANSWER

Answered 2019-Jan-01 at 15:31

So, if CoreCLR uses SSE FP instructions on x86-64, does that mean that it doesn't suffer from the truncation issues, and/or any other FP-related non-determinism?

If you stay on x86-64 and you use the exact same version of CoreCLR everywhere, it should be deterministic.

If the runtime still uses x87 instructions with unreliable results, would it make sense to use a software float implementation [...] I've prototyped this and it seems to be work, but is it unnecessary?

It could be a solution to workaround the JIT issue, but you will likely have to develop a Roslyn analyzer to make sure that you are not using floating point operations without going through these... or to write an IL rewriter that would perform this for you (but that would make your .NET assemblies arch dependent... which could be acceptable depending on your requirements)

If we can just use normal floating point operations, is there anything we should avoid, like trigonometric functions?

As far as I know, CoreCLR is redirecting math functions to the compiler libc, so as long as you stay on the same version, same platform, it should be fine.

Finally, if everything is OK so far how would this work when different clients use different operating systems or even different CPU architectures? Do modern ARM CPUs suffer from the 80-bit truncation issue, or would the same code run identically to x86 (if we exclude trickier stuff like trigonometry), assuming the implementation has no bugs?

You can have some issues not related to extra precision. For example, for ARMv7, subnormal floats are flushed to zero while ARMv8 on aarch64 will keep them.

So assuming that you are staying on ARMv8, I don't know well if the JIT CoreCLR for ARMv8 is behaving in that regard; you should probably ask on GitHub directly. There is still also the behavior of the libc that would likely break deterministic results.

We are working exactly at solving this at Unity on our "burst" compiler to translate .NET IL to native code. We are using LLVM codegen across all machines, disabling a few optimizations that could break determinism (so here, overall we can try to guarantee the behavior of the compiler across the platforms), and we are also using the SLEEF library to provide deterministic calculation of mathematical functions (see for example https://github.com/shibatch/sleef/issues/187)… so it is possible to do it.

In your position, I would probably try to investigate if CoreCLR is really deterministic for plain floating point operations between x64 and ARMv8… And if it looks okay, you could call these SLEEF functions instead of System.Math and it could work out of the box, or propose CoreCLR to switch from libc to SLEEF.

Source https://stackoverflow.com/questions/53989518

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install OpenSAGE

You can download it from GitHub.

Support

For any new features, suggestions and bugs create an issue on GitHub. If you have any questions check and ask questions on community page Stack Overflow .

DOWNLOAD this Library from

Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from
over 430 million Knowledge Items
Find more libraries
Reuse Solution Kits and Libraries Curated by Popular Use Cases

Save this library and start creating your kit

Explore Related Topics

Share this Page

share link
Reuse Pre-built Kits with OpenSAGE
Compare Game Engine Libraries with Highest Support
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from
over 430 million Knowledge Items
Find more libraries
Reuse Solution Kits and Libraries Curated by Popular Use Cases

Save this library and start creating your kit

  • © 2022 Open Weaver Inc.