Need somebody to semi-regularly test compilation on windows

[MrNex]

Recently I think I've decided to stop updating the Visual Studio version of the project. It's too much work for too little return. If any one individual wants to turn it into a VS project, it's quite simple-- just import all of the files into a new project & rename the extension from .c to .cpp if visual studio 2012 or older.

However, I haven't been able to compile NGen on windows recently. I am running Arch on my machine now, and none of the windows machines at my disposal have minGW installed on them.

If somebody could compile it on a Windows machine & share the results I would be very grateful!

[Waqar144]

I successfully compiled it on Windows with MinGW32.
But my GPU doesn't go beyond OpenGL 3.3 so...

[MrNex]

Thank you for testing this. I am not sure the Rendering Pipeline uses any features specific to a version greater than 3.3.

If it does, and you know the culprits, perhaps I can implement a solution to cater towards users with limited hardware compatibility. I'm assuming you did not have luck running the program. Do you know what function specifically caused the problem?

Regardless, thank you very much for your assistance. I would really like to get this working on as many platforms as possible.

[Waqar144]

@MrNex
Well, I had to change the version to 3.1(yeah, i know, i had it wrong earlier) to atleast get it running.
Crashed right after LoadShader(),
129 : GLuint shaderIndex = glCreateShader(shaderType);
I have the backtrace, but the backtrace doesn't agree with this:

0 0x00000000 in ?? ()
1 0x0040cb3b in RenderingManager_Render (gameObjects=0x343860)
at Manager/RenderingManager.c:99
2 0x00416357 in Draw () at main.c:334
3 0x6de4b78c in glutForceJoystickFunc () from f:\NGen\freeglut.dll
4 0x00342bb8 in ?? ()
5 0x00401250 in __mingw_CRTStartup ()
6 0x004012b5 in mainCRTStartup ()

[MrNex]

Very interesting... I wonder how the backtrace is saying it could have possibly reached the Draw function before creating the shader program...

I'm not sure it has anything to do with the problem, but I think using freeglut was a mistake. I think this enforces my decision to move to GLFW within the next few days. I'll check out the initialization & draw code again and see if I can find a cause.

[MrNex]

I think I found the problem, the behavior you experienced was my fault. It should be fixed with 0d6ba85

Thank you very much for helping me catch this! Development of the project would not be possible without the efforts people such as yourself.

[Waqar144]

Well, I got it up and running...
I replaced glProgramUniform*() with glUniform*() in RenderingManager_Render and it just started to work.
And Now glutMainLoop() is going on and on......... :)
This certainly is progress 👍

Let me know if I can help you anywhere else. I am no expert but with little help I may be able to solve some tiny problems in your code.

[MrNex]

That is great news! If you were looking forward to playing with the current simulation here are some controls:

M will lock the mouse and enable mouse controls
Q will unlock the mouse
WASD to move
Mouse to look around
Spacebar to jump
Hold spacebar when approaching a wall to either vertically or horizontally wallrun
Let go of spacebar to wall jump
Left click to shoot

Erm.. Don't.. Drag the window ;). Still working on things- clearly!
Thanks again for all of your help! I'll probably replace ProgramUniform with Uniform in the repo- if something that simple is causing compatibility issues.

[MrNex]

If we take that route, I'd prefer to look into pre-processor logic. If that is even possible- so much of OpenGL is determined at run-time. But even considering, I don't think it would be difficult to follow the older pipeline of:
glUseProgram(...);
glUniform(...);

As opposed to
glProgramUniform(...);

I don't believe the older pipeline is deprecated by any means. Please correct me if I'm wrong.

My reasoning is the rendering code already has so much branching and it's just ugly and becoming unwieldly. I'll be going through to refactor at some point in the near - moderately soon future. I'd like to avoid any other branches or complications until it's a bit more.. kind.

[Waqar144]

No, not deprecated.
And yes, if we prefer to support both, then I think the best way to go would be preprocessor logic. Or you could just drop glProgramUniform in favor of the older alternatives.
But I think both should be available. If a machine is capable of running GL 4+ then it shouldn't be forced to use the older versions.

[MrNex]

You are right. If a machine is capable it absolutely should use the newer versions. Thank you for straightening my view on that. I'm going to make this it's own issue & reference this in it.