Fix build in Visual Studio (2013)

chosenofbear commented

2015-06-17 13:17:38 +00:00

(Migrated from github.com)

Tested with Visual Studio 2013.

Ancurio commented

2015-06-17 13:55:18 +00:00

(Migrated from github.com)

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.

[Here is](http://stackoverflow.com/questions/119578/disabling-warnings-generated-via-crt-secure-no-deprecate) 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.

Ancurio commented

2015-06-17 16:11:25 +00:00

(Migrated from github.com)

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.

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.

chosenofbear commented

2015-06-17 17:44:53 +00:00

(Migrated from github.com)

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.

Ancurio commented

2015-06-18 00:52:20 +00:00

(Migrated from github.com)

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.

> 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](https://plus.google.com/+flibitijibibo/posts/MK8u4cV1N9e) about his goals with FNA for XNA game preservation, and while that's a different engine, I share this philosophy for mkxp.

chosenofbear commented

2015-06-18 01:25:16 +00:00

(Migrated from github.com)

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.

Ancurio commented

2015-06-18 04:27:29 +00:00

(Migrated from github.com)

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.

> 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.

Ancurio commented

2015-06-18 05:16:00 +00:00

(Migrated from github.com)

SDL_sound fork is here: https://github.com/Ancurio/SDL_sound

khkramer commented

2015-06-21 10:16:50 +00:00

(Migrated from github.com)

Off-topic but could you maybe send me a binary built with msvc?
It would save me a lot of hassle.
Thanks in advance.

Off-topic but could you maybe send me a binary built with msvc? It would save me a lot of hassle. Thanks in advance.

chosenofbear commented

2015-06-23 13:21:46 +00:00

(Migrated from github.com)

@khkramer How can I send that to you? It actually works exactly the same as the the mingw compile provided by the author.

cremno commented

2015-06-23 15:27:04 +00:00

(Migrated from github.com)

Are you using CMake? I think 180ba8a87e is a better solution to silence the warnings and prevent the definition of the min/max macros.

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.

This pull request can be merged automatically.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.

git checkout -b chosenofbear/master master

git pull origin chosenofbear/master

Step 2:

Merge the changes and update on Forgejo.

git checkout master

git merge --no-ff chosenofbear/master

git push origin master

Fix build in Visual Studio (2013) #111

Step 1:

Step 2: