An adaptation to SDL 2.0 (Alpha-level Android build attached)

Here you can discuss the development of patches.

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby Azarien » 2016-3-22 @ 11:55

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.
Azarien
Oldbie
 
Posts: 581
Joined: 2015-5-14 @ 07:14

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby Dominus » 2016-3-22 @ 12:11

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...
User avatar
Dominus
DOSBox Moderator
 
Posts: 7689
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby Azarien » 2016-3-22 @ 14:50

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.
Azarien
Oldbie
 
Posts: 581
Joined: 2015-5-14 @ 07:14

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby Dominus » 2016-3-22 @ 14:55

Best accept that you are not in a position to give the developers any advice on how to proceed.
User avatar
Dominus
DOSBox Moderator
 
Posts: 7689
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby NY00123 » 2016-3-23 @ 20:20

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.
NY00123
Member
 
Posts: 234
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby mr_bigmouth_502 » 2016-4-18 @ 10:02

Switching to SDL2 would make it much easier to compile DosBox on modern Linux distros, just sayin'.
My NEW(ish) desktop:
Image
User avatar
mr_bigmouth_502
Oldbie
 
Posts: 1942
Joined: 2009-5-16 @ 19:43
Location: Canada

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby dugan » 2016-5-04 @ 18:16

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.
dugan
Newbie
 
Posts: 46
Joined: 2015-4-04 @ 03:17

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby Kisai » 2016-9-28 @ 19:03

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
Code: Select all
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/dos ... s-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.
Kisai
Newbie
 
Posts: 99
Joined: 2010-5-05 @ 08:04

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby Dominus » 2016-9-28 @ 20:30

The first thung to do is make sure you have libpng devel packages/source available and that configure finds it.
User avatar
Dominus
DOSBox Moderator
 
Posts: 7689
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby Kisai » 2016-9-28 @ 23:25

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.
Kisai
Newbie
 
Posts: 99
Joined: 2010-5-05 @ 08:04

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby Kisai » 2016-9-29 @ 13:18

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.
You do not have the required permissions to view the files attached to this post.
Kisai
Newbie
 
Posts: 99
Joined: 2010-5-05 @ 08:04

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby AmigaBlitter » 2016-10-27 @ 15:02

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.
AmigaBlitter
Newbie
 
Posts: 6
Joined: 2016-10-27 @ 14:53

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby lightmaster » 2016-10-27 @ 16:38

Hello friend:
Use the private message for that.
Cheers
Image
User avatar
lightmaster
Oldbie
 
Posts: 639
Joined: 2005-10-01 @ 12:09
Location: Sol III

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby AmigaBlitter » 2016-10-28 @ 09:44

Thank you for the reply.
I will use PM as susggested
AmigaBlitter
Newbie
 
Posts: 6
Joined: 2016-10-27 @ 14:53

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby NY00123 » 2016-10-28 @ 15:56

AmigaBlitter wrote: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.
You do not have the required permissions to view the files attached to this post.
NY00123
Member
 
Posts: 234
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby lightmaster » 2016-10-28 @ 20:29

@NY00123 "maybe it's just me, but I'm not sure what reason there is for a" for a patch or a *full source*.
I think , therefore I doubt..
Image
User avatar
lightmaster
Oldbie
 
Posts: 639
Joined: 2005-10-01 @ 12:09
Location: Sol III

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby emendelson » 2016-11-16 @ 15:46

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): 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.
You do not have the required permissions to view the files attached to this post.
emendelson
Oldbie
 
Posts: 747
Joined: 2010-2-14 @ 02:00

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby emendelson » 2016-11-16 @ 18:20

EDIT: Finally got the code fixed:

Code: Select all
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...
emendelson
Oldbie
 
Posts: 747
Joined: 2010-2-14 @ 02:00

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby emendelson » 2016-11-19 @ 01:01

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?
emendelson
Oldbie
 
Posts: 747
Joined: 2010-2-14 @ 02:00

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby dugan » 2017-1-03 @ 02:41

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).
You do not have the required permissions to view the files attached to this post.
dugan
Newbie
 
Posts: 46
Joined: 2015-4-04 @ 03:17

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest