TheCherno
commented
8 years ago Hi aritzhack, firstly thanks for all the work you're putting into this. Using CMake is a good idea, and feel free to let that generate a VS solution as well. I will still be checking in the VS solution / project files though, since that is the primary development environment for Sparky.
Don't worry about CLI, since that's really only intended for tools (such as the Level Editor, which will be Windows only), so we don't need that for Linux. If Linux tools were to exist, they would be written in C++ anyways. The point is, CLI will never be required for the engine runtime.
I would recommend frequently merging master into your branch as you work on this, to reduce the difficulty of merging all of this when you're done. As for coding conventions, there aren't any official docs on that (yet), so my advice would be to just look at the existing code in Sparky, and try and blend in. I think I've demonstrated pretty much every convention that I use, so just follow those.
As for your questions:
- DirectX/OpenGL are chosen at runtime (on Windows), so there shouldn't be any macros which enable/disable those APIs. For Linux, you should just be able to not compile the files starting with the "DX" prefix (in sp/platform/directx), and you won't get any DirectX code compiling. Macros however will be required for the API-independent classes, such as Shader. In the .cpp file, you'll need to make sure that
sp/platform/directx/DXShader.hdoesn't get included for Linux, and that the switch statements that check theRenderAPI::DIRECT3Dcase don't get compiled. My recommendation for that would be to use theSP_PLATFORM_WINDOWSmacro. since (at least for now), only Windows will be using Direct3D. - The
m_UniformDatamember doesn't actually exist, that code must be left over from the first iteration of theMaterialandMaterialInstanceclasses. In other words,GetUniformdoes not work, and won't even compile (if used). So just don't worry about that for now, it will need to be fixed to retrieve data from them_VSUserUniformBufferandm_PSUserUniformBufferbuffers.
Please let me know if you have any other questions, and good luck! :)
ghost
cubedtear
Ilohama
DreamHollow
sp/platform/posixIntentions
I am currently making progress on compiling Sparky-core, its dependencies and Sandbox on Linux Mint with gcc. I am using CMake in order for the build to be as portable as posible (thinking about future CI, too). Every so often I am also testing the VS project in Windows 10, to ensure I do not break anything.
For now, I am only intending to build and test Sparky (i.e. the dependencies, sparky-core, and Sandbox). The SparkyCLI (or the CLI tool, now that it is made) would make sense for Mono, but for now I think it's enough to get the engine up and running by itself for now.
Since CMake is cross-platform, I am going to try to make the CMake script able to generate not only the binaries, but also fully functional and well-structured Visual Studio solution files. Also, in order not to have to update the CMake build script each time, I am thinking about making a small tool to convert VS solution files into the CMake scripts.
I am working on my fork, which was based on 42a8de8ae3c60d23e42c39cd94c3c684ac8a721c and is updated to e79a25dd7f6e15c3212f4568b75b7868c25c42bf. However, I am going to do a clean fork and commit all the changes in one/two commits when it is all finished, as I am committing small and broken changes when I switch computers/OSs.
Progress
As of writing this, CMake scripts seem totally functional. All static and dynamic libraries are built without any problem, including Sparky-core. Sandbox builds aswell, and I get a window, but there are some platform-dependant classes (those in
sp/platform/posix) that have not been implemented yet, because I wanted to make everything compile ASAP.There are some problems with the
newanddeleteoperator overloading and FreeImage, which I am currently investigating.Notes
I do realize my code may very well not follow the coding conventions @TheCherno uses. I have yet to configure my IDE. Once again, my fork right now is just to get it to work, no matter how dirty it has to be. I will focus on putting it all nicely afterwards.
I have not tested the CMake scripts in Windows. Making them work there will likely require some changes, due to how libraries are treated in Windows vs Linux.
Questions
SP_DIRECTX/SP_OPENGL), or should justSP_PLATFORM_WINDOWS/SP_PLATFORM_UNIXbe used?sp/graphics/Material.h, the functionsGetUniform(whatever)referenceGetUniformDeclaration()andm_UniformData, which just appear in that file. What is their purpose?