search

MrNex / NGen

3D Game & Simulation Engine written in C
Other
13 stars 4 forks source link

Need somebody to semi-regularly test compilation on windows #7

Open MrNex opened 9 years ago

MrNex commented 9 years ago

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 commented 9 years ago

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

MrNex commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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

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 commented 9 years ago

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 :+1:

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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.