Does not work on 15" MacBook Pro running OS X Yosemite

[Ivoah]

When trying to run noeuclid on my MacBook Pro, it opens just fine, but the display is borked:

[phiresky]

What's the output in the console?

[Ivoah]

https://sr.ht/HaPf.txt

[phiresky]

Thats weird. Are you sure your tileattributes.txt and rooms.txt are unchanged?

[Ivoah]

Yep. The only thing I changed was the Makefile to get it to compile on Mac

[phiresky]

Mh, might be something to do with line endings. Though I thought they were \n like in linux.

[Ivoah]

Mac OS X is built on Unix, so the line endings shouldn't be an issue. Also, it works on my other Mac.

[phiresky]

Wait, it works on a different mac? Same version? Is maybe the locale setting different? Could be because of decimal point parsing..

[Ivoah]

The two macs have different graphics cards, could that be it? The computer it works on has a beta OS on it, but noeuclid worked when it had the same OS version as my laptop

[phiresky]

The Output of vertex shader 'doPhysics' not read by fragment shader is probably caused by that, yes. But I don't think the malformatted line errors could have something to do with that.

[Ivoah]

I grabbed the version off my mac mini and compiled it, and I still get the line formatting error.

EDIT: I get the malformed line error on my mac mini too, but it still runs

[cnlohr]

The fact that there are so many warnings having to do with line formatting is concerning. It looks like you may be having a newline termination issue? Maybe? I'm not entirely sure. Can you post the md5sum of rooms.txt and tileattributes.txt along with so we an verify there is no corruption?

[Ivoah]

Samantha:noeuclid Ivo$ md5 rooms.txt tileattributes.txt 
MD5 (rooms.txt) = 4f2c2ce51c960382ff7dac4b2a99d2cc
MD5 (tileattributes.txt) = 0a19e824bbcf0c9a9e4811043b4180b8

[cnlohr]

Good. That is the time. Does your output still report similar errors? Also, can you paste the output from Makefile so I can look at the flags?

[Ivoah]

Here's a recording of me cloning and building noeuclid, including the edit to the Makefile for compiling on Mac: https://asciinema.org/a/dhsxrlzf64xoo0ckr7mc76her

[phiresky]

I just inspected the failing lines. In rooms.txt, it only happens for EmptyBox and PaintRange calls that are missing the last (optional) parameter, which is checked with (line>>std::ws).eof().

For tileattributes.txt it only seems to be happening for the lines that do not have a space at the end: these (and also have optional fields missing). That check is also done using (line >> std::ws ).eof()

So I'm guessing your OSX stdlib treats string>>ws as fail if it is at eof. Please try running this program with -std=c++11:

#include <sstream>
#include <iostream>
using namespace std;

int main() {
    stringstream l("nows");
    stringstream l2("ws ");

    string tmp;

    l >> tmp;
    l2 >> tmp;

    l >> std::ws;
    l2 >> std::ws;

    cout << l.fail() << " " << l2.fail();
}

For me, it outputs 0 0

(Note that the line numbers the program currently outputs for rooms.txt are wrong, here are the corresponding ones)

[phiresky]

Which would also mean that your problem has nothing to do with those line errors (as indicated by you writing those also happen on a computer where it runs correctly)

[Ivoah]

O.o https://sr.ht/pytI.txt

[phiresky]

Well, thats not the output I expected. :+1:

[phiresky]

Try compiling with c++ instead of cc

[Ivoah]

headdesk Running a.out prints "1 0"

[phiresky]

Okay, problem identified. So according to the standard

Stops when [...] end of file condition occurs in the input sequence in which case the function calls setstate(eofbit) but does not set failbit.

If I read that correctly, thats a bug in your compiler/lib. What compiler/version are you using?

[Ivoah]

Samantha:Programming Ivo$ clang -v
Apple LLVM version 7.0.0 (clang-700.0.72)
Target: x86_64-apple-darwin15.0.0
Thread model: posix

[phiresky]

Okay. Well I dunno about mac compilers. You could try installing gcc, but those errors can probably be ignored.

I also don't really see why this could be causing it Linking shaders response follows:WARNING: Output of vertex shader 'BasePosition' not read by fragment shader, but maybe @cnlohr knows that better.

What GPU are you using?

[Ivoah]

I have two

AMD Radeon R9 M370X:

  Chipset Model:    AMD Radeon R9 M370X
  Type: GPU
  Bus:  PCIe
  PCIe Lane Width:  x8
  VRAM (Total): 2048 MB
  Vendor:   ATI (0x1002)
  Device ID:    0x6821
  Revision ID:  0x0083
  ROM Revision: 113-C5670E-777
  gMux Version: 4.0.20 [3.2.8]
  EFI Driver Version:   01.00.777
  Displays:
Color LCD:
  Display Type: Retina LCD
  Resolution:   2880 x 1800 Retina
  Retina:   Yes
  Pixel Depth:  32-Bit Color (ARGB8888)
  Mirror:   Off
  Online:   Yes
  Built-In: Yes
SyncMaster:
  Resolution:   1920 x 1080 @ 60 Hz
  Pixel Depth:  32-Bit Color (ARGB8888)
  Display Serial Number:    H1AK500000  
  Main Display: Yes
  Mirror:   Off
  Online:   Yes
  Rotation: Supported
DELL U2410:
  Resolution:   1920 x 1200 @ 59 Hz
  Pixel Depth:  32-Bit Color (ARGB8888)
  Display Serial Number:    C592M02ACUKL
  Mirror:   Off
  Online:   Yes
  Rotation: Supported
  Connection Type:  DisplayPort
  Television:   Yes

and

Intel Iris Pro:

  Chipset Model:    Intel Iris Pro
  Type: GPU
  Bus:  Built-In
  VRAM (Dynamic, Max):  1536 MB
  Vendor:   Intel (0x8086)
  Device ID:    0x0d26
  Revision ID:  0x0008
  gMux Version: 4.0.20 [3.2.8]

[cnlohr]

You can safely ignore the warning. I am surprised I left that there. BUT I have a lot of unstaged commits I forgot about. They are in now.

Try pulling from the new version, 58dca99

[Ivoah]

It still doesn't work. The screen looks the same as before.

[cnlohr]

Oddly enough for a split second after my Intel card started playing it, it looked exactly like that then it looked good. There has been someone else who ran into bizarre problems where the camera cocked sideways and stuck. @phiresky I am toying with beginning development of this again but I am having a really hard time with some of these bizarre issues.

[phiresky]

That screenshot is what it looks like when the rooms are not loaded yet or the position is not set (you are set to (0,0,0), directly outside the world boundary boxes). I got it a few times during development, but then the rest of the game is still working.. @Ivoah do you "fall" in the broken game? does anything except the counter change, or is it completely static? Can you move the view by moving the mouse?

(happens e.g. with this change:

diff --git a/rooms.txt b/rooms.txt
index 34f364b..bd57880 100644
--- a/rooms.txt
+++ b/rooms.txt
@@ -11,7 +11,7 @@ Room 0
 # Time in seconds until player dies of old age
 Time 100
 # Start coordinates
-Start (3 3 64)
+#Start (3 3 64)
 # Corners of the exit box
 Exit (4 4 61) (1 1 1)

)

@cnlohr that would be great. As far as I see most bizarre issues are caused by shader incompatibility / OS problems. If you have any problems with my code changes open issues or email me.

[Ivoah]

Everything is static except for the timer in the upper left corner.

[Ivoah]

Actually, that's not true. There is motion in the blue '+' I'm uploading a vid to YouTube and I'll edit it here when it's done.

EDIT: https://youtu.be/Ja08LpfSIb4

[phiresky]

While you're at it, please try changing this:

diff --git a/Room.cpp b/Room.cpp
index a0a29d9..5e2db12 100644
--- a/Room.cpp
+++ b/Room.cpp
@@ -3,7 +3,7 @@

 extern GameMap gamemap;
 void Room::reset() {
-    gPosition = start;
+    gPosition = {100,100,100};
     GameTimer = maxTime;
     begin();
 }

and say what it looks like then.

That overrides the setting of the start position, just to see if that works

[Ivoah]

Looks the same

[phiresky]

Did you recompile? Try setting gPosition = {100,100,100} in noeuclid.cpp line 64

[Ivoah]

Still the same, and yes I did recompile it.

[phiresky]

Oh, the above position setting did not have any effect. Try setting this in GameMap.cpp instead

@@ -89,7 +89,7 @@ void GameMap::update() {

     if (gOverallUpdateNo == 0) {
         curroom = startroom;
-        gPosition = rooms[curroom].start;
+        gPosition = {100,100,100}; // rooms[curroom].start;
     }

if that does not change anything send the output of this

diff --git a/noeuclid.cpp b/noeuclid.cpp
index ac08e77..bd920fa 100644
--- a/noeuclid.cpp
+++ b/noeuclid.cpp
@@ -288,6 +288,7 @@ void LoadProbes(bool isRerun) {
     mod(gPosition.y,GLH_SIZEY);
     mod(gPosition.z,GLH_SIZEZ);

+   cout << "load probes "<<gPosition<<endl;
     if (!gGodMode) {
         gh.MapOffset = gPosition;
     }
@@ -638,6 +639,7 @@ void DoneProbes(bool bReRun) {
 clend:
     probes.clear();
     gPosition = newp;
+   cout << "after probes: "<<gPosition<<endl;
     gDirection = gpForward->Direction.vec();
     gTargetNormal = gpForward->Normal.vec();
     gTargetCompression = gpForward->InAreaWarp.vec();

[Ivoah]

The first fix didn't help

load probes (3 3 nan)
after probes: (3 3 nan)

[phiresky]

Is that output constant? Even the very first instance?

[Ivoah]

the first one was

load probes (3 3 64)
after probes: (3 3 nan)

but after that it's constant

[phiresky]

Okay, now we're getting somewhere. So the shader pass causes the z coordinate to be set to NaN. @cnlohr do you know what can cause that?

[cnlohr]

I do not! But it sounds like something we should guard against. I know from the one time it happened on my computer (ever) and description from someone else their view got stuck in this 90 degrees off view, so it sounds like a different issue. Would you mind ammending the code to check for this error, with prompt and reset the NaN'd value to the last valid value? (it'll be a day or two before I can get back into development)

[phiresky]

Sorry, I can't right now. It would probably also be better to further reduce the scope where the error occurs so the check/fix is closer to the actual problem.

[Ivoah]

Bump, any more work on this? I'd really like to get noeuclid running on my laptop.

[Ivoah]

I have more info on this. The problem only occurs when using the high performance discreet GPU. Everything works fine when it's forced to use the integrated GPU.

[phiresky]

I think that confirms that it's caused by the shaders not compiling correctly, though I would have expected some error messages then. I don't really have an idea how to approach that problem, sorry.

[cnlohr]

I don't think we're going to get this one solved for that specific hardware. If you do eventually find the solution, please comment.