VOGONS

Common searches


Reply 60 of 183, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie

There should be an official SDL 2 branch of DOSBox being developed in parallel, until it is stable and tested.
It is time.

If you think it is too hard to maintain two branches, then you should rethink the tools you use, because I am afraid the ones you have hinder the development.

I'm thinking of Git. It is easy to make branches and merges in Git.

Reply 61 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Proper words are essential... *should* sounds a lot like entitlement.
"Should rethink" even more so AND belittling...

I'm sure your post really makes the developers do all that...

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 62 of 183, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie

Proper words are essential... *should* sounds a lot like entitlement.
"Should rethink" even more so AND belittling...

I am not a native English speaker, and am not sure what would be a better word. What I am sure about is that DOSBox development isn't going as smooth as it could.

Reply 63 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Best accept that you are not in a position to give the developers any advice on how to proceed.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 64 of 183, by NY00123

User metadata
Rank Member
Rank
Member

Hey there,
Thanks for your interest in this patch!

I should begin by stating the following. It is true that there are more general concerns not related to SDL 2.0, which (may) lead to the lack of a new "proper" release of DOSBox, and/or certain DOSBox modifications even without a release:
- The fact that DOSBox v0.74 is in such a state that it doesn't need a lot of updates by DOSBox devs, especially with regards to compatibility with games.
- Before a proper release is done, the DOSBox devs want to make sure that, at least in general, compatibility with games isn't broken in comparison to an earlier DOSBox release (unless there's a good reason).
- It may feel like it's difficult to make certain changes without writing a whole new emulator, as briefly stated in this interview from 2013: https://sourceforge.net/blog/potm-201301.
- There is less motivation to update DOSBox itself nowadays, following the availability of paid mobile ports of DOSBox (e.g., for Android), as well as taking advantage of DOSBox for offering games in digital stores. There may be other, similar reasons.
- Tech support (for users of DOSBox, say in these VOGONS forums) isn't necessarily fun.

As for SDL 2.0 itself, there are also great chances that the DOSBox devs (maybe not all of them, I have no idea) aren't exactly thrilled with the way SDL 1.2 was abandoned before SDL 2.0.0 was released, so they may be a bit careful with the idea of moving to SDL 2.0.

I can surely see enough reasons for having an interest in using SDL 2.0. Some examples I have at the moment:
- On Linux (more precisely X11), SDL 2.0 doesn't fully grab the keyboard and mouse anymore (say in fullscreen windows). This means, for instance, that window manager hotkeys like Alt-Tab can be used as expected.
- SDL 2.0 supplies SDL_Renderer, which can be used for 2D accelerated rendering. By default, behind the scenes, Direct3D is used on Windows, and OpenGL (ES (2.0)) on other platforms, but SDL 2.0 lets you a different renderer driver if any is available. A software renderer driver is also available.
- Note that SDL 2.0 still lets you do hardware acceleration with OpenGL as before (without SDL_Renderer). Multiple profiles of OpenGL 3.0 can further be used, as well as OpenGL ES.
- While I don't think it's really useful for DOSBox, SDL 2.0 supports multiple audio output devices. One feature that was planned for SDL 2.0 but is probably on-hold at the moment, is audio capture support. While it may be useful for a small selection of DOS games, I don't believe that many games take advantage of it.
- With SDL 1.2, DOSBox uses SDL keycodes for all keys, unless the usescancodes setting is toggled on (which is the default). In the latter case, some platform-specific SDL scancodes are used. With the SDL 2.0 patch, SDL scancodes are used anywhere in sdl_mapper.cpp and are (hopefully) portable. In theory, scancodes represent key locations and not labels, so you should - again in theory - always get the US keyboard layout by default, with the option to internally map it differently for some other language.

It isn't the case there won't be problems at all, though:
- The lack of keyboard grab can be a disadvantage, depending on the situation. By default, the Ctrl+Alt+Arrow key combinations are used for changing workspaces in Ubuntu (or at least certain versions of that). This may lead to problems if these are used in-game. While Ubuntu 14.04 has just one workspace, these key combinations are still defined for workspace switching, which again leads to some unexpected behaviors in-game.
- Despite what I've stated above regarding SDL2 scancodes, there may still be some different behaviors depending on the keyboard layout. With some layouts on the Windows platform, Alt Gr may behave like Ctrl + LAlt, even if SDL2 scancodes are used. Forcing US English layout for the given process (using some Windows API function) may solve this as a workaround.
- It is better to assume that joystick / game controller support is incomplete. Not only I don't really use such an input device these days, but SDL 2.0 adds support for joystick hot-plugging, which DOSBox doesn't take in account at the moment, even with the SDL2 patch.
- As stated beforehand, SDL_cdrom was removed from SDL 2.0. It is true that the last revision of the SDL2 patch should include a usable copy of SDL_cdrom with a few changes, so it's less of a problem now, but this may still be a concern.

There may be more points which I haven't had in my mind as of typing this, but the above is already more than enough for a post.

Reply 66 of 183, by dugan

User metadata
Rank Newbie
Rank
Newbie

I think that a large reason that this work isn't really mergeable is that it's not only a port to SDL2. It's also a port to Android. NY00123's work here is a huge part of what I took for My DosBox Fork, and one of the first things I did with it was strip out all the code for compatibility with either Android or SDL1.

I think this should really be broken up into several patches: one just for SDL2, and then three optional patches to apply on top of that: Android support, SDL1 backward-compatibility, and physical CD-ROM support.

I'd be happy to help with that, but not today.

Reply 67 of 183, by Kisai

User metadata
Rank Member
Rank
Member
dugan wrote:

I think that a large reason that this work isn't really mergeable is that it's not only a port to SDL2. It's also a port to Android. NY00123's work here is a huge part of what I took for My DosBox Fork, and one of the first things I did with it was strip out all the code for compatibility with either Android or SDL1.

I think this should really be broken up into several patches: one just for SDL2, and then three optional patches to apply on top of that: Android support, SDL1 backward-compatibility, and physical CD-ROM support.

I'd be happy to help with that, but not today.

I actually had no problem just applying this patch straight to r3998.

That said, there is a problem, and I'm trying to figure out if it was introduced by the patch or if it was introduced somewhere in the trunk of dosbox. That being if you try to use video capture, it crashes.

Specifically it crashes at

memcpy(capture.video.index, "idx1", 4);

So I patched around it and other than producing no usable video, I played a game start-to-finish. I then went to find a reference 3998 built by anyone else and... can we please delete EMUCR from the wiki, all their downloads contain malware.

Anyway compared to http://www.columbia.edu/~em36/wpdos/dosbox-vdos-lfn.html 3998's dosbox-vdos-lfn also crashes when capturing video in the same place. That version uses SDL 1.2

So this leads me to believe that the problem is not in the patch but somewhere in DOSBOX.

Reply 68 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

The first thung to do is make sure you have libpng devel packages/source available and that configure finds it.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 69 of 183, by Kisai

User metadata
Rank Member
Rank
Member
Dominus wrote:

The first thung to do is make sure you have libpng devel packages/source available and that configure finds it.

The screenshots, and wav and midi capture all work. It's just the video capture that doesn't. I'll probably grab the sources for a much earlier vanilla build and see if it happens there, but the fact that it happens in someone elses independent build means there is a problem that both builds produced.

My build is with MSVC++ (Community) 2015

When I patched around it, the MSBC debugger says that capture.video.index is null. So I don't think it's libpng. The resulting avi files when patched around are empty. If I load it in VLC it has the codec headers only.

Reply 70 of 183, by Kisai

User metadata
Rank Member
Rank
Member
Kisai wrote:

My build is with MSVC++ (Community) 2015

And somehow it just went away when I re-patched everything again. Ghost in the Machine. If anyone else wants to give it a go there's three builds attached:
r3998-SDL1, which is just straight up a svn compile
r3998-SDL2, which is the patch in this thread only
r3998-SDL2-MT32, which is the patch in this thread plus munt

SDL sound is not compiled in, as that's when bugs start creeping in.

Attachments

  • Filename
    DosBox-r3998-bin.7z
    File size
    1.43 MiB
    Downloads
    196 downloads
    File comment
    DosBox r3998 versions SDL1, SDL2 and SDL2+MT32
    File license
    Fair use/fair dealing exception

Reply 74 of 183, by NY00123

User metadata
Rank Member
Rank
Member
AmigaBlitter wrote:
Hello everyone, […]
Show full quote

Hello everyone,

i'm new to this forum.
I would like to know if a full source code of DosBox SDL2 is avaiable somewhere.

Thank you very much.

Hey there,

Welcome to the forums!
Further thanks for your interest in the SDL2 patch.

To lightmaster, maybe it's just me, but I'm not sure what reason there is for using a PM.

In theory, downloading the DOSBox sources from SVN and then applying the patch (with a tool like 'patch') should do the job.

However, it turns out that the patch does not cleanly apply to the latest revision of DOSBox from SVN (apparently since r3998).
So I've attached a minor update to the preceding patch (i.e., dosbox_sdl2_20150713.diff) which should be compatible with r4000. There is no other change to it.

Attachments

  • Filename
    dosbox_sdl2_20161028.diff
    File size
    480.75 KiB
    Downloads
    254 downloads
    File comment
    Updated patch compatible with r4000
    File license
    Fair use/fair dealing exception

Reply 76 of 183, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

I doubt anyone else will be interested in this question, but I'm asking just in case someone feels curious. For my DOSBox-based project, I've ripped a Windows-only PasteClipboard feature (plus additions to the system menu) from the commercial dbDOS code in my a customized sdlmain.cpp (with a few lines added to keyboard.h and keyboard.cpp) and got it to work in SVN.

I've got the SDL 2.0 adaptation to build in VS2010 with SDL2 code replacing my old SDL1.2 code, and I've been trying to squeeze the PasteClipboard feature into the SDL2-based version. I seem to be almost there, and the big hangup is in adapting the SDL 1.2 SDL_GetWMInfo code into SDL2. I'm not a programmer, and I only stumble around in source code, so I haven't been able to get this to work. But I've got to the point where the build fails with only this message:

1> sdlmain.cpp 1>..\src\gui\sdlmain.cpp(2969): error C3861: 'SDL_GetWMInfo': identifier not found 1>..\src\gui\sdlmain.cpp(2970 […]
Show full quote

1> sdlmain.cpp
1>..\src\gui\sdlmain.cpp(2969): error C3861: 'SDL_GetWMInfo': identifier not found
1>..\src\gui\sdlmain.cpp(2970): error C2039: 'window' : is not a member of 'SDL_SysWMinfo'
1> D:\Development\DOSBoxWP-SDL2\SDL2-2.0.5\include\SDL_syswm.h(194) : see declaration of 'SDL_SysWMinfo'
1>
1>Build FAILED.

I've attached a copy of my non-working keyboard.h, keyboard.cpp, and sdlmain.cpp. If anyone is generous enough to look at this and let me know what needs to be replaced, I'll be very gratful. The added bits have comments with "dbDOS" and "emendelson" in them.

Again, this is based on SVN with the SDL2 patch applied, and only SDL2 code available in the library and include directories.

Attachments

  • Filename
    SDL2ClipboardFails.zip
    File size
    35.98 KiB
    Downloads
    184 downloads
    File comment
    sdlmain.cpp, keyboard.cpp, keyboard.h
    File license
    Fair use/fair dealing exception

Reply 77 of 183, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

EDIT: Finally got the code fixed:

SDL_Window* window;
SDL_SysWMinfo systemInfo;
SDL_VERSION(&systemInfo.version);

if(SDL_GetWindowWMInfo(window, &systemInfo) !=1) return;
if (!::OpenClipboard(systemInfo.info.win.window)) return;

But I've got another question about this patch, for a separate post...

Reply 78 of 183, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

Another question about this impressive work:

I built and ran this successfully under Windows, using Visual Studio 2010. I've found only thing so far that goes wrong: The Alt-Enter keystroke switches to full-screen mode, but the screen is blank (all black). Alt-Enter switches back to windowed mode, but nothing is visible in full-screen mode. Is that something that could be fixed easily?

Reply 79 of 183, by dugan

User metadata
Rank Newbie
Rank
Newbie
dugan wrote:

I think that a large reason that this work isn't really mergeable is that it's not only a port to SDL2. It's also a port to Android. NY00123's work here is a huge part of what I took for My DosBox Fork, and one of the first things I did with it was strip out all the code for compatibility with either Android or SDL1.

I think this should really be broken up into several patches: one just for SDL2, and then three optional patches to apply on top of that: Android support, SDL1 backward-compatibility, and physical CD-ROM support.

Attached is version of this patch that only has the update to SDL2. I've stripped out support for SDL 1.2, Android, and physical CD-ROMs.

As mentioned, this is how my started my fork. I later intend to contribute the OpenGL 3 engine I made for it, which is based on this, and then the OpenGL 3-based shader engine, which is based on that.

I'm aware of emscripten ports that use SDL 2. I haven't looked at them, but I'd imagine that this would be a good base for one.

The codebase (particularly in sdlmain.cpp) is a lot cleaner now, with all that stuff removed. In fact, it's now no worse than what's in svn.

As my testing of this version of the patch goes: It works fine with GOG's Gabriel Knight release, with the ISO IMGmounted to D:. On Linux it works perfectly, and on OS X it works, uhm, as well as my fork does (both have issues with fullscreen).

Attachments

  • Filename
    dosbox_sdl2_only_r4000.diff
    File size
    166.81 KiB
    Downloads
    248 downloads
    File comment
    Only the update to SDL2. Apply against r4000.
    File license
    Fair use/fair dealing exception