Search results

I don't have anything advanced just yet - just the fact of compilation itself. Yes, I've tried wineg++ and regular gcc. wineg++ is more promising but has a number of changes to be made for "Windows" and std headers to be compatible with each other If you want to try it as well - attached is a...

Do you plan to PR the new APIs into main Orbiter repo?

What is the strategy for API compatibility in OpenOrbiter? Is the objective to maintain compatibility with Orbiter 2016 as much as possible, or is it possible to make breaking* changes? Specific issues I'm looking to address are: return types of some functions - int vs intptr_t, int vs size_t...

16.11.2 works for me without issues for me, I've even managed to start compiling Orbiter under Linux (failing now, obviously)

Had to align a lot of moving parts, but it's available now: PR#109. "Integration" (Scenario) tests are runnable from Visual Studio Test Explorer alongside .cpp-based unit tests

Still working on adding tests. GTest proved to be too finicky ultimately - they add 10-20 seconds to "configure" time and do not preserve working directory, which randomly break test discovery. I've switched effort to push Catch2 framework instead. In addition, trying to add capability to run...

CMake just doesn't suppport this directly: https://discourse.cmake.org/t/how-to-make-a-visual-studio-solution-with-x64-x86-support/880 Only way to switch within same VS instance is to use CMakeSettings/CMakePresets (which is why I am pushing for it). Otherwise, having separate build directories...

FWIW, I'm using a CMakePresets.json file in the solution directory (PR), it allows to switch x86/x64 debug/release directly in Visual Studio without having to regenerate the solution. It doesn't have a problem with additional "Debug"\"Release" directory P.S. PR with x86 artifact is open - let...

If orbitersim organisation is not attached to your paid plan (if you have one), you will not get a bill, it will just start failing. If it is... Well, at least the bill should not be that huge;) There is an action which in theory allows to keep "last N" builds, I'm trying it out on my fork. If...

Main concern is potentially running out of space for artifacts, which is why I didn't include them from start. I'm not sure what the limit is, @martins or @dbeachy1 will probably know, as GitHub "organisation" owners In case there's enough space - it's trivial to do, here's a PR

Have not tried it myself, but should be possible, according to SO: https://stackoverflow.com/questions/2209929/linking-different-libraries-for-debug-and-release-builds-in-cmake-on-windows

Sure - I've created 'gtest' branch on my fork - if you add it as remote to your repository, you should be able to check it out (in both senses) I've added 2 trivial tests there to try it out - there would be 2 ways to run them: Via Visual Studio - if you open Orbiter source directory...

You are right - I have tried to substitute Orbiter_NG.exe for Orbiter.exe - forgetting that NG is a thin wrapper, not the full binary. Copying correct executable to root does the trick - thanks! A couple more questions (while I have your attention): Do you have any objections if I introduce...

I am trying to add tests to Orbiter public repository by using CMake and GoogleTest. GTest download, build and Visual Studio integration all work correctly - however, I'm at impasse with handling Orbiter's own dependencies. As soon as I add anything from OrbiterSDK into test code, test project...

FYI: GitHub repository CI now has x64 builds published (available in "Artifacts" section after clicking on a build)

Glad to be of help, Dr. Schweiger:salute: As a side note - intptr_t is indeed 32-bit in x86 builds+correct "pointer" size in x64 - we might actually be able to just use it instead of the OAPI_MSGTYPE #define? Backward compatibility should be preserved well in theory. Side note #2 - a lot of...

I have created a PR yesterday adding GitHub Actions build in both x64 and x86 - this should help both to validate incoming PRs to the repo and iterate on x64 build. Wonder if unit tests are possible

"I know this machine as well as I do my 3 fingers"

While working on some project, I had a strong need to launch several Orbiter windows. Although there is a workaround for the stable version (using a hardcoded address, courtesy of Orb IIRC), there hadn't been one which would help for beta versions. Here's my final solution to the single-launch...

☺ Read: http://en.m.wikipedia.org/wiki/Moon_illusion There's no "magnification" by atmosphere.