Open chosenofbear opened 9 years ago
Here is a handy link full of instructions on how to disable the _CRT_SECURE_NO_DEPRECATE
warnings directly in your IDE without sprinkling defines all over the code.
Same with NOMINMAX
, it makes no sense to work around broken compilers inside the code, just add it as a global define in your project.
Most of your problems in this PR can either be worked around in your IDE or fixed in mkxp by generically changing code. The crossplatform.h
header however is a big "this project supports compilation via MSVC" signpost, and that makes me a bit nervous, because it would really be a half-hearted commitment on my side. I only use Linux so gcc is my bread and butter, and MinGW works well enough that I can put out experimental win32 builds without mostly having to touch the platform; also I can keep using Unix'isms without too much worry (although I really shouldn't rely on them). Clang is a non-issue as it's modern and mirrors gcc's interface.
I really don't like adding platform specific code (screenshot support was removed because SDL2 doesn't offer a way to get the user's desktop path, and I don't want SDL'ish stuff in mkxp if possible). It would be nice if something would offer a cross-platform chdir
(well technically gcc/mingw is doing that right now), I think PhysFS would be the place for it. But for the most part I just don't want to set a precedent.
One question about the future of this project is that if we only want to port the RM interpreter to Linux, or also want to provide the developers and players a better platform. The original RM interpreters have many problems (such as the slow Ruby 1.8 in XP and the incapability of changing window size). I have seen a lot of efforts done by the RM community to enhance the original interpreter, such as writing customized scripts, using WinAPI and modifying the RGSS dll. None of those efforts are as effective as writing a brand new open source interpreter. I hope this project can have more enhancements instead of simply copying all existing RM features no matter if they are useful or not. It can benefit many RM developers and players in that way.
One question about the future of this project is that if we only want to port the RM interpreter to Linux, or also want to provide the developers and players a better platform.
My motivation for mkxp was definitely the former; I want to be able to "preserve" existing RPG Maker games. Ethan Lee did a nice writeup about his goals with FNA for XNA game preservation, and while that's a different engine, I share this philosophy for mkxp.
It seems you really like some of the existing RM games (me too :) ), I just feel a little pity because so much effort could have created a new open source RPG game development tool (which does not exist so far) and a better tool will help create more great new games. Old games will eventually fade away. That is a sad but true fact.
I just feel a little pity because so much effort could have created a new open source RPG game development tool (which does not exist so far) and a better tool will help create more great new games. Old games will eventually fade away. That is a sad but true fact.
Yes, but the current RPG Maker / RGSS system is not the way forward. It is a horrible engine loaded with design flaws, extremely Windows-centric, and simply a dead end. Trying to extended and bandaid it is not the way forward. A new effort for a better RPG development platform should start clean and have open frameworks / cross platform design at its foundation. To be honest, I don't think we can expect something like that out of Japan-focused Enterbrain anytime soon.
SDL_sound fork is here: https://github.com/Ancurio/SDL_sound
Off-topic but could you maybe send me a binary built with msvc? It would save me a lot of hassle. Thanks in advance.
@khkramer How can I send that to you? It actually works exactly the same as the the mingw compile provided by the author.
Are you using CMake? I think https://github.com/cremno/mkxp/commit/180ba8a87e8c2e8602a3a9ed863243f328245e01 is a better solution to silence the warnings and prevent the definition of the min/max macros.
Tested with Visual Studio 2013.