EDIT 7/1/2018 After debating about the usefulness of CMake, I'm deprecating it for these reasons:. Linux devs seem to don't need at all. Windows devs simply use the solution in vs2015. Mac devs?. this approach is half-baked as it requires vcpkg and does not provide the same level of comfort of the manually crafted solution (with everything in) Therefore, expect the CMakeLists.txt to stale compared to aforementioned environments. They're not gone, they just won't get updated anymore. I wanted to finalize the CMake list but have been encountering a few problems, since the branch is 2000 commits behind master I've started (mostly) from scratch, with now the goal to push it as soon as possible so it doesn't rot in the repo as a couple of other things:) The first thing is SDL2, does it builds without SDL1?
Edit: Apparently it does, the only thing is that headers were poorly referenced, i.e. Sdl.h instead of SDL2/sdl.h, a quick edit effectively removed all the errors (will know for sure once build succeeds) The second thing is PC98 emulation, I don't understand how the VS solution builds properly, since files such as control.h are not in the repo, I somehow copied it from the original emulator but it was until it shows that many others are missing. So have you done anything special to the PC98 code brought over?
Now regarding my new CMake, it's definitely much better:. stripped across many lists, the main list now only contains the principal stuff (600 lines removed). it does use vcpkg and all dependencies are available through it. should allow to ditch that vs2015 folder once and for all Why have you kept it (the solution), is it because for simplicity or are there some tricks involved in it? Is custom-SDL1 deprecated by now since SDL2 works well? I maintain the ability to compile with SDL2 but the custom SDL1 is still a major focus for me. Having the freedom to modify SDL 1.x as I see fit has allowed me to fix keyboard layout and graphical problems on Windows, Mac OS X, and Linux.
I like to keep the vs2015 folder so that people used to VS2015 have a way to compile DOSBox-X from source. I want to make sure that compiling from source is not very difficult. I've added a lot to the PC-98 emulation over time, including cleanup and bug fixes. I've cleaned up a lot of the code and fixed most of the compiler warnings, then I've added -Wall -Wextra and -pedantic to reveal many other subtle bugs that might affect runtime. I've updated the requirements for the code, and I've made it mandatory to compile with a C compiler that supports C11. I've replaced the Windows-only IDRMENU resource with a C menu framework that allows the same menus to work on Windows, Mac OS X, and Linux. For Mac OS X menus, a new.mm Objective C file was added.
For Linux, menus are drawn by DOSBox-X itself on the SDL surface, or with OpenGL quads and a font texture if the output is set to OpenGL. For SDL2 builds, the SDL drawn menus are the only option. Since SDL2 is actively maintained, I will not be hacking up the SDL2 source code the way I have hacked up SDL1. Part of the menu work is that some of the menu items are automatically tied to mapper shortcuts.
Phn Mm Dosbox For Mac Free
The menu items will automatically show whatever key binding you've assigned through the mapper, so there's no problem with misleading shortcut text if you've changed any mapper bindings from the default. To clean up the mess of keyboard shortcuts, a 'host key' modifier was added (inspired by VirtualBox) and most of the shortcuts were changed to work from that host key, or were automatically given no binding. I also fixed the 'hold' modifier, which I understand was a long-standing issue with DOSBox. I have been maintaining the ability to compile with MinGW on Windows instead of VS2015/VS2017 as well. The code has been updated so that MinGW builds are almost equivalent in function to what VS2017 can provide including Direct3D9 output support.
At the request of I also maintain a build mode where using an older MinGW toolchain it is possible to compile to run under MS-DOS and the HX DOS extender (HXGUI) and the code contains support for that (SDL1 only). I personally do not use CMake, but you're welcome to commit changes to the master branch to add CMake files for those who would rather compile with CMake instead of GNU autoconf or VS2015.
Had to get my hands really dirty, but now it builds, basically not all the PC98 files were included in vs2015. In regards to your additions to SDL1, does that mean SDL2 is not able to achieve the same level of features? You've done an amazing job to say the least, don't understand much of it but it's neat! The new menu approach is definitely the right way and building under DOS is just stellar!!! CMake rocks in the sense that whatever changes you do on it are available to all of its platform generators, if say you update a CMakeLists by adding new files, you simply rebuild the CMake-provided ZEROCHECK project and the VS solution asks to be reloaded.
I will see if I can come up with SDL1 support for it but can't make any promises as it's still really vague to me (just as Linux is, too btw). In regards to pre-VS2017 support, it's definitely able to target XP as I've shown before: i.e. VS2017 is free and can run on Windows 7, upgrade path is really easy Here's the new CMake, simpler and friendlier: There is still one error but the fix for it breaks the vs2017 version: However, just figured out that neither builds do run over-here, yours and mine: to be continued.