What will make it easier for people to help?

[cnlohr]

@phiresky @Bp103 @fiendfan1 - y'all have made a commit or two. I'm curious what all would be useful and/or may encourage you guys to continue to develop/commit, or if you guys were just passing through.

[phiresky]

Hi. I am already continuing on my fork, cause I'm not sure you'd agree with the things I did to your code. It's compiling and when running it should be almost exactly how it was before. (Except I made the FOV wider). What I did for now:

• Made the levels/rooms an external text file with a simple format, so it doesn't have to be compiled in and is simpler to edit. The problem is the dynamic things, they are currently still compiled (but more structured). I was thinking about using some scripting language (this one looks really nice) but not sure.
• I removed lots of dead functions / code bits and replaced some c things with c++(11).
• I removed tcc, the code reload functionality is currently missing
• I added a Vec3 class making many things shorter and more readable
• Replaced lots of outdated GL functions with newer versions.
• Changed your bracket coding style to the one without newline before opening '{'. Mostly because the netbeans formatter did it, can be easily reverted.
• Removed/Integrated GLUTCore class and other things I thought were unneccessary

What I was planning to do:

• Completely reproduce runtime reloading functionality (easy for static things, not sure if scripting language or tcc again for dynamic things)
• convert quaternion functions to c++11
• Support for WebGL in browser (this is why I replaced GL functions with newer versions for support of emscripten)
• Maybe use SDL instead of GLUT
• Better Room from text file creation code. Currently using vectors of lambdas returning lambdas putting them into other vectors.. yeah.

[phiresky]

Also I removed the windows compatibility DEFINEs cause of maybe using SDL. emscripten "almost" works when compiling with emmake make clean &&emmake make CPPFLAGS=-DEMSCRIPTEN&&/usr/lib/emscripten/em++ -s LEGACY_GL_EMULATION=1 -o noeuclid.html noeuclid.o OGLParts.o RTHelper.o Map.o Common.o GameMap.o -lGL -lGLU -lglut --preload-file Shaders/Pass1Physics.frag --preload-file Shaders/Pass1Physics.vert --preload-file Shaders/Pass1.frag --preload-file Shaders/Pass1.vert --preload-file Shaders/Pass2.frag --preload-file Shaders/Pass2.vert --preload-file Shaders/Pass3.frag --preload-file Shaders/Pass3.vert --preload-file tileattributes.txt &&emrun noeuclid.html

but fails cause of lacking support of 3d textures.

[phiresky]

I also just switched to cmake and finally got Windows working (again?)

[cnlohr]

What was the rationale behind dumping the tcc? It's pretty much the only way to effectively edit and work on the map, as anything else has extremely long development cycles.

Was it just to acquire more language features? I don't really see why these changes can't be dumped back into mainline other than the dropping of TCC - which it sounds like we could dump back in without too much issue.

I had played with adding LUA support, but realized manually binding everything, or using one of the bindings engines was a lot more work, and much slower to work with than I expected. I gave up after about a week.

I am always concerned about performance, but considering we're 100% GPU logged, I don't see any big deal there.

Are you willing to consider keeping it all mainlined?

[cnlohr]

Also, I keep forgetting OpenGL 3 is now the standard >.<

[phiresky]

Mostly to make it easier to read for me, I thought it would be easier to not drag it along with my changes and rather add it again afterwards if necessary. I also think compiling c++ is not really a permanent solution for levels.

I added ChaiScript yesterday for testing, only took a few hours (and mostly because I had a bug in CellUpdate -.-). This is all I had to change. Problems I see so far:

1. Multiplies compile time because ChaiScript is completely in the header.
2. Speed? No idea how fast it is. but so far it seems to work well: This line prints the time and grows a blob somewhere.

[cnlohr]

I am glad you agree that compiling C++ is not a permanent solution. Chaiscript looks acceptable. Though I am a C guy, if you're up for working together with it, I would be more than happy to abandon my current path for a C++/Chaiscript direction.

I'll give a whirl at building this tonight.

[cnlohr]

Also, what was your rationale behind using CMake instead? I've always found it to only be useful on /really/ big projects. Aaand oh my it does take a long time to compile!

[cnlohr]

Sorry, just one more comment -- On the room with the game of life - any idea what could be making it 1/2 the speed? All the other rooms feel okay, but that one, when looking at a wall is 18 FPS, while on my version it's 35...

[phiresky]

Mostly for finding the include paths and library names dynamically (e.g. -lgl for linux and -opengl32 for windows) and for having it detect changes in every file, including headers.

Yes, the compile time with Chai is terrible. Also nobody else seems to care about it, I can find nobody who has the same problem, even though it should not be hard make it an external file.

I actually reconsidered using C for scripting instead of Chai.. I readded it. It worked for a simple script but right now I'm having problems and this approach is not very debug-friendly. But, it compiles in 2.9 seconds again!

On the room with the game of life - any idea what could be making it 1/2 the speed?

Did you compile with -O2? Cause I didn't have that in, it might be the reason. Otherwise I have no idea, I don't think I changed anything in that code yet.

[phiresky]

I figured out what the problem is: tcc compiles structs in some other way than other compilers making it impossible to transfer the vec3 objects into/out of the scripts. (example).

Not sure how to proceed, maybe keep c (if it works in windows). Currently looks like this

[cnlohr]

I prefer your solution to splitting apart the scripts to my old solution, of an all-inclusive script. I would keep it C. Binding the vec3 object to TCC should be easy. The only real difference I would expect is the C++ vtable at the beginning of the structure. So, if you pass the vec3 as (&myVec3.x), it should be fine.

I'm trying to figure out how to add -O2... still dinking with it.

I do not mind putting in effort to make things windows compliant, myself. I do have access to a windows PC periodically.

[cnlohr]

Got -O2 working, it looks like that was the main offender.

[phiresky]

Look at the stack overflow example: http://stackoverflow.com/questions/26536367/compatibility-of-compiled-gcc-and-tcc-structs

It also happens with an almost empty struct and only c, so I don't think it's a vtable.. sizeof() also reports 12 on both.. (I don't actually know anything about c/c++ compilers though)

[cnlohr]

.< Somehow the build is broken. I have such difficulty with figuring out how to get CMAKE to insert the right flags in the right places. I miss my makefile sniff

[phiresky]

Might be because the other files are not copied to the build directory anymore (removed it so they aren't duplicated. You have to run it in the source folder as build/noeuclid

[cnlohr]

I am getting this now:

/usr/bin/ld: //usr/local/lib/libtcc.a(libtcc.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libdl.so: error adding symbols: DSO missing from command line

Also, I am going to tinker with your Vec problem.

[phiresky]

You could also run cmake . in the root directory once .. I kind of like a clean source folder. Yes, flags are fairly messy.. but just adding them after "-g -Wall" in line 3 should work.

I had that too... don't know what I did to fix it though. Do you have the latest git pull? with -ldl and -ltcc?

[cnlohr]

I got the TCC problem working. You can check out the post I made on stack overflow.

Also, here is my new compile line: Linking CXX executable noeuclid /usr/bin/cmake -E cmake_link_script CMakeFiles/noeuclid.dir/link.txt --verbose=1 /usr/bin/c++ -g -Wall -Os -g CMakeFiles/noeuclid.dir/RTHelper.cpp.o CMakeFiles/noeuclid.dir/Room.cpp.o CMakeFiles/noeuclid.dir/Common.cpp.o CMakeFiles/noeuclid.dir/scripthelpers.cpp.o CMakeFiles/noeuclid.dir/Map.cpp.o CMakeFiles/noeuclid.dir/noeuclid.cpp.o CMakeFiles/noeuclid.dir/GameMap.cpp.o CMakeFiles/noeuclid.dir/OGLParts.cpp.o -o noeuclid -rdynamic -lGLEW -lglut -lXmu -lXi -lGLU -lGL -lSM -lICE -lX11 -lXext -ldl -ltcc /usr/bin/ld: //usr/local/lib/libtcc.a(libtcc.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libdl.so: error adding symbols: DSO missing from command line

[phiresky]

That exact line works for me. So it's probably something else.. Maybe try rm -rf build/* and cmake again?

Hu, that was fast.. I spent a while printing random memory to try and find out what the hell happens. Nice

[cnlohr]

AH! Apparently the order of -ldl and -ltcc matter. -ltcc must be first.

[phiresky]

Apparently not for me. But I had that same error once and somehow it stopped. Fuck C/++ compilers, lets port to java.

[cnlohr]

Considering my side of the repo has the most watching and where I'm making these issue tags - do you mind merging back and working from my mainline? If for other reasons you would prefer not to treat mine as mainline, that is okay.

On the java end: I did make a dumber version of this that ran in WebGL. There's just a lot of very difficult to get around restrictions :(

[phiresky]

Apparently WebGL 2 has some nice additions - maybe then.

Yes, we should merge back.

[cnlohr]

The last I remember seeing was a discussion about supporting more than 4 textures, or was it 3D textures... I can't remember, one of the two, and everyone in the thread unanimously agreed that it was not going to happen any time soon... Maybe no time soon has come?

[cnlohr]

I committed two small things to my build. I fixed the library order for me and updated the mouse sensitivity.

[phiresky]

There's a map of the 256 different available blocks above Room 4. It will say what block you are standing on.

I did not see this above room 4 even in your older build (but I think I removed the relevant code)

[cnlohr]

It was in the common "run every time" code in test.c

[phiresky]

Yes, it's this, right? But how did that "say what block you are standing on?

[cnlohr]

It was this code here:

if( IsPlayerInRange( 2, 40, 63, 16, 16, 4 ) ) { int lx = ((int)gPositionX) - 2; int ly = ((int)gPositionY) - 40; sprintf( gDialog, "OnTile %d\n", lx + ly * 16 ); }

[phiresky]

https://github.com/cnlohr/noeuclid/blob/master/GameMap.cpp#L190-193 still there. Never saw it when running

[cnlohr]

You and your snazzy syntax. I can't do anything more on it tonight - good luck debugging.

[phiresky]

:D What do you mean? How I put every vector in {} or how I did some weird c++11 lambda stuff that makes compiler errors completely unreadable when something is slightly wrong?