Armagetron Forums

Search for eCamera::Timestep. That's the function you can put this stuff into. Or eCamera::Render. Render has the advantage that you don't have to worry about ordering: Put your code at the top. It will then run between both Timestep calls (one for each view, one of them doing an update you don't ac...

You get the basic stereoscopic shift by, well, shifting one of the cameras to the side by the distance of the eyes. What you do is that you set up basic side-by-side splitscreen and modify the code for the second view so that instead of the usual camera update, it just copies all values from the fir...

delinquent wrote:I wonder if Arma uses libSDL? I think it does, IIRC.

It does.

Splendid lurking! You may want to have a look here: https://bugs.launchpad.net/armagetronad/+bug/1850536 dlh uploaded some test builds. For those with suicidal thoughts for whatever reason: You are NOT alone, there are places and people that can give you help, usually easily found in your local phon...

is nonexistent for the time being. Sorry to the users. The technical issue that triggers this change of status is that MacOS dropped support for 32 bit applications, and our builds only have that. The only system I had available for building was a PowerBook, and while that might have been able to do...

Yeah, just modifying gCycleMovement::rubber on the spot is also possible. For consistency, you have to do it in one of two ways. If you want continuous changes, you need to apply them in one of the Timestep() family of functions, it's not too important for your purposes which one (TimestepCore is th...

Modifying rubber individually for each player is not currently possible, at least not in the vanilla source. So you will have to modify the code yourself. A couple of pointers: We already detect the two situations you speak of in the method gCycleMovement::CalculateAcceleration() (in gCycleMovement....

Merge done, there were some conflicts that I violently resolved by sticking to the version from the fortress_ai branch. As a result, tutorials and challenges that rely on AIs following paths are now broken; those did not exist yet when the branch was started.

Nah, those are INSTANTIATION failures. While those can still be the fault of the header, this one even seems to be a static assertion meant to provide a readable compiler error message (and failing, because that is a surprisingly difficult task; good thing there is static_assert now in the standard)...

Should be fixed in the main source now. Binreloc just reads /proc/self/maps, which contains a list of memory segments belonging to the current process and which file they belong to, and the bit in memory it looks for moved from one type of segment to a new kind.

Huh, what do you know? Apparently, it's a general problem now. Binreloc stopped working for me, too (Manjaro, which is basically arch). I just never noticed because I always start the game without relying on executable path resolution, and then binreloc is not needed. Well, that was bound to happen ...

What system is this on, precisely?

As a workaround, you can try disabling binreloc here by passing "--disable-binreloc" to configure.

Nah, it's working as intended after all. Without -I-, all includes are supposed to be system includes. There's a solution suggestion here, just add -I- in a place where the automake additions get added before it: https://github.com/nickg/nvc/issues/5 Sadly, it completely breaks C++ compilation on Ub...

"Supposed to", yeah :) The problem here is the "-I../../" command line argument to the compiler. In the olden days, you'd say gcc -IA -I- -IB and if there is a #include "bla" in the source, it would look both in A and B, but a #include <bla> would only look in B. We don't have a -I- in there at all,...

THAT version file isn't supposed to be included! Can you look for a line containing '#include' and 'version' in /usr/include/c++/v1/cstddef and post its surroundings? I'd like to know how this happens. To work around the problem, you could try moving the version file out of the way after running con...