VOGONS

Common searches


Reply 20 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

By the way, SDL 2.0 and SDL 1.x CAN happyly coexist for at least a year, maybe two years. All SDL 2.0 libs have the the 2 in the name.

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 21 of 183, by NY00123

User metadata
Rank Member
Rank
Member

Two more things I should've probably added before:
1. If anybody here has tried the Android package, chances are that you have heard crackling sounds (and possibly a bit slower sound playback as well, although I'm unsure about that). Unfortunately, I don't know what to do with that. It didn't help when I played with the blocksize and prebuffer DOSBox settings (if not more). To emphasize the significance of the issue, I could hear crackling sounds even with a game that runs with no more than cycles=300 and uses just the (emulated) PC Speaker for sound output. To give some more info, with some luck (mainly app restoration from a pause?) the device *can* run Doom in the emulator (E1M1) with a "playable" frame rate (about 10FPS).
Truly, maybe it comes from the fact that many Android-powered setups (if not all) don't really have good (if any) support for true low-latency audio, while DOSBox seems to generate relatively small sound chunks before sending them to the OS.
Note that if you think that some sound tones are missing (like a bass), that may simply be a limitation of your device's internal speaker(s). Simply try raising the volume, or even better - connect headphones that are known to work "well" with a PC/Mac, and then compare.
2. Maybe wd has thought of that before: With SDL 2.0, you generally want to forget about the concept of "color depth". Simply stick to the desktop pixel format (even though there are chances you can change it for a fullscreen window), pick some color format for a texture (either while using OpenGL directly, or for any of the SDL renderer implementations) and use that, possibly letting a GPU (hopefully not a CPU...) do a color format conversion as required.

Dominus wrote:

By the way, SDL 2.0 and SDL 1.x CAN happyly coexist for at least a year, maybe two years. All SDL 2.0 libs have the the 2 in the name.

That is true. On Windows it is probably not a major problem, since any SDL app tends to come with its own copy of the shared library. On GNU/Linux, shared libraries like SDL are generally shared, and it should be possible to have SDL 1.2 and 2.0 installed altogether.

truth5678 wrote:

This GUI does seem to implement at least a couple of ideas I've had, with some differences. One of them is, obviously, the GUI which is shared among multiple platforms (not using platform-specific UI controls). Another one that I've had is easy navigation with various kinds of controls: Keyboard arrows or any kind of a D-pad, mouse, touch and maybe more, possibly with the ability to zoom in some way for anybody using a small screen. Of course things are expected to temporarily change once you want to add/remove/change some input mapping, but otherwise that role should apply.

Last edited by NY00123 on 2013-08-15, 09:19. Edited 2 times in total.

Reply 22 of 183, by NY00123

User metadata
Rank Member
Rank
Member

Oh yeah, one more thing I should probably emphasize in a separate post: If someone thought about integrating RGUI into DOSBox itself, it should be noted that the last revision of RetroArch, including the RGUI sources (as currently found on its GIT repository), is licensed under version 3 (and any later version) of the GNU GPL.

Reply 23 of 183, by truth_deleted

User metadata

"Vsync on" has caused sound crackling in Retroarch (Android version); it may be worth a try even though Doom (E1M1) ran under the vsync cap. Also, Retroarch uses SDL and their audio code may have another workaround for high latency audio. (I've heard that GPLv3 changes the way code is commercialized, but I haven't confirmed this yet.)

Reply 24 of 183, by NY00123

User metadata
Rank Member
Rank
Member
truth5678 wrote:

"Vsync on" has caused sound crackling in Retroarch (Android version); it may be worth a try even though Doom (E1M1) ran under the vsync cap. Also, Retroarch uses SDL and their audio code may have another workaround for high latency audio. (I've heard that GPLv3 changes the way code is commercialized, but I haven't confirmed this yet.)

Having a guess this is related to the VSync issue, I'm afraid that frameskip=2 does not seem to help here, with games that seem to run as expected with cycles=300 and cycles=3000. I further suspect that not all Android-powered devices let you disable VSync at all. In fact, the function eglSwapInterval seems to be available for usage only on some newer devices.

Reply 26 of 183, by NY00123

User metadata
Rank Member
Rank
Member
truth5678 wrote:

Given SDL-2 functions are the same across systems, I wonder if the sound crackling occurs in Windows, too. (Or in Android-x86).

I confirm it does not occur on a GNU/Linux desktop. (To be more specific, Ubuntu 12.04 for x86_64.)

Reply 27 of 183, by truth_deleted

User metadata

The audio functions in SDL_audio.c have a few parameters that could be changed. Under "SDL_RunAudio", there is a parameter set for no audio streaming:
device->use_streamer = 0

Their code appears experimental, but it could be modified to enable/disable the above streaming function. Also, in that function, the thread priority is set to high:
SDL_SetThreadPriority(SDL_THREAD_PRIORITY_HIGH)

If the audio/video threading is causing the crackling, then it may be worthwhile to change the audio priority from high and a corresponding change for the video code. That may diagnose if the threading is involved in the crackling. Another potentially relevant function is "prepare_audiospec" which configures the audio setting, even though it is presumed that these are overriden by dosbox:
prepared->freq = 22050
prepared->format = AUDIO_S16 (change to AUDIO_U8?)
prepared->channels = 2
const int samples = (prepared->freq / 1000) * 46 (resampling value of 46ms)

The SDL2 code has many "FIX ME" comments. 😀

Reply 28 of 183, by okias

User metadata
Rank Newbie
Rank
Newbie

Hello, I updated patchset, actual apply a top of 3858.

Is ongoing some futher integration?

Attachments

  • Filename
    dosbox_sdl2_20140308.diff
    File size
    380.24 KiB
    Downloads
    199 downloads
    File comment
    updated to today git
    File license
    Fair use/fair dealing exception

Reply 29 of 183, by NY00123

User metadata
Rank Member
Rank
Member

Thanks for updating the patch!

Interestingly, it looks like a new stable release of SDL2 is out, being version 2.0.2.

I'm afraid there isn't a lot to add to the patch. A few notes of mine to add, though (a few of them have possibly been mentioned before):
- The possibility of dealing with (host) color formats differing from RGB(A) is still an issue, say when a scaler like hq2x desired. This may require more changes not directly related to the patch itself.
- It'd surely be nice to add back support for mounting folders as CD-ROMs, even with their limits. For the sake of simplicity it is not done for now, though. Sadly, though, physical disc support, along with CD-Audio, is more of a problem.
- As some users have probably seen, the changes made for (very partial) Android support are still true hacks. I think some of them don't necessarily belong to this patch at all, although they're a nice bonus.

Reply 32 of 183, by NY00123

User metadata
Rank Member
Rank
Member

ok, finally I've looked at your update to the patch. It is significantly larger than the last one posted by me in terms of file size (dosbox_sdl2_20130626_2.diff). I guess it's simply coming from the mistake of adding unnecessary files like sdlmain.cpp.rej into the patch. That may happen, I know.

To compare, it looks like my patch (dosbox_sdl2_20130626_2.diff) applies mostly cleanly to the latest revision, with some offsets (including fuzz 1), and three failures: Two in sdlmain.cpp's GFX_SetSize, the other at the very end of the file (exception handling), all of them coming from r3857.
It is actually the case I have a not-yet-ready more up-to-date patch of mine (dating back to November...), again applying with just these three failures. So I can probably start from here, fixing the problems as required.

This update to the patch doesn't add much, mostly a few simplistic extras that may help on Android and a few code comment updates.

Reply 33 of 183, by NY00123

User metadata
Rank Member
Rank
Member

Alright, an update to the patch is now up.

1. First, basic CD-ROM related changes:
- Basic CD-ROM folder mounting is now supported with SDL 2.0. It is still impossible to mount physical discs for purposes like CD-Audio, though. But then, IMGMOUNT is also an option.
- You should get a warning ("Physical CDROMs aren't fully supported. IMGMOUNT may be more useful.") if any of the following command line arguments is passed to MOUNT: -cd, -usecd, -aspi, -ioctl_dio, -ioctl_dx, -ioctl_mci, -noioctl.
- INTRO CDROM is also back for SDL 2.0, although with some changes. For MOUNT, only the basic folder mounting support is described. IMGMOUNT is given as an alternative.
- Note that IMGMOUNT is *not* given as an alternative in case SDL 1.2 is used (same as vanilla DOSBox).

While it may be possible to bring back physical CD-ROM support for SDL 2.0 with CD-Audio on some platforms, there are a few issues with this:
- SDL CD functions are used for checking if a path represents a physical CD-ROM, independently of the actual DOSBox CD-ROM interface used in practice.
- It'll be less portable to support just the interfaces differing from SDL.

2. Next, some small changes for Android, mostly dating back to November:
- The "fullresolution" setting is now disabled, and the whole desktop resolution is picked (minus the virtual bar with soft buttons and co).
- The DOSBox splash screen and mapper UI are now scaled to fill the whole area for display, with aspect correction.
- While there is nothing like a new GUI making support for this more comfortable, the patched DOSBox can now take advantage of joystick support for Android introduced in SDL 2.0.2.
- Technically, the max. number of SDL joystick buttons has been increased to 36, to cover button numbers coming from Android for certain controllers.
- The accelerometer is not listed as an SDL joystick anymore (previously the accelerometer could result in annoyances within the mapper UI).
- SDLActivity.java has been updated. It is still the case that on-screen keyboard support is a bit hackish in a way, and not working well on a lot of situations (say when a key press is followed by a release of the same key immediately).
- Misc. comments added/modified.

It should further be noted that the aforementioned ARMv7 recompiling core patch is now integrated into upstream, so there's no need to apply it separately for performance gains.

Attachments

  • Filename
    DOSBox-debug.zip
    File size
    3.78 MiB
    Downloads
    252 downloads
    File comment
    Android package for testing
    **Rename to DOSBox-debug.apk before installation (ZIP to APK)**
    **Installation from unknown sources should be permitted**
    **instructions.txt from the diff may help**
    File license
    Fair use/fair dealing exception
  • Filename
    dosbox_sdl2_20140316.diff
    File size
    177.71 KiB
    Downloads
    209 downloads
    File comment
    Updated patch against r3858 (March 16th 2014)
    File license
    Fair use/fair dealing exception

Reply 34 of 183, by NY00123

User metadata
Rank Member
Rank
Member

If someone is trying this on Android, chances are someone is going to be interested in the mapper file attached to this post.

Some notes to check before trying out:
- Not all controllers are supported.
- This was tested with a USB non-XInput controller reporting 12 buttons, 4 analog axes (2 sticks) and 1 HAT switch (a D-pad).
- To be more precise, this controller is powered by an adapter, but the basic idea still applies.
- Supported SDL button numbers for this controller, and probably other USB non-XInput controllers: 20-35 (Obviously only 20-31 are used for the specific tested controller.)
- The behaviors of XInput controllers are totally unknown, but chances are SDL button numbers 0-14 are to be used, if not 0-19.
- For any other controller the behaviors are totally unknown.
- You're on your own.

A description of the mapping follows, using the SDL button numbers as written above (20-31), axes no 0-3 and one HAT switch:
- Emulation of primary joystick/gamepad analog stick in DOS: Via axes no. 0,1.
- Emulation of secondary joystick/gamepad analog stick (in DOS): Via axes no. 2,3.
- Emulation of primary joystick/gamepad buttons 0,1: Via buttons no. 20, 21.
- Emulation of primary joystick/gamepad buttons 2,3 (or secondary's 0,1): Via buttons no. 22, 23.
- Emulation of a few keyboard keys: The HAT switch can be used in place of the keyboard's arrow keys in DOS.
- Emulation of more keyboard keys: 24 -> Left Control, 25 -> Left Shift, 26 -> Left Alt, 27 -> Space, 28 -> Escape, 29 -> Enter, 30 -> Backspace.
- Showing the DOSBox mapper UI: Via button no. 31.

Alright, a few instructions for supported environments and controllers:
- The attached file should be renamed to mapper-SVN.map and then located on the Android-powered device where DOSBox reads dosbox-SVN.conf. The exact location should be created after the first launch of DOSBox at the least, and probably looks like /sdcard/Android/data/com.dosbox.emu/files.
- dosbox-SVN.conf should be edited so the value picked for "joysticktype" is "fcs" (i.e., joysticktype=fcs should be written). Otherwise, some features of the controller (say a HAT switch) may be non-functional.
- If the game controller is connected with an adapter accepting multiple controllers, there are chances you'll need to connect the controller to another port.
- As in a couple of preceding patch revisions, use the device's "back" button to show/hide an on-screen keyboard.
- If it's actually working for you, chances are you'll want to play with the mapper file. Just edit mapper-SVN.conf, or at least modify the line involving the mapper UI if you want to display it in some way differing from Ctrl-F1 and "SDL joystick button no. 31".

Attachments

  • Filename
    mapper-SVN-android-gamepad.txt
    File size
    3.23 KiB
    Downloads
    198 downloads
    File comment
    Sample mapper file for gamepad usage on Android
    ***Please read the post before trying***
    File license
    Fair use/fair dealing exception

Reply 35 of 183, by okias

User metadata
Rank Newbie
Rank
Newbie
NY00123 wrote:

Are you asking me? This is an unofficial patch and I'm not a part of the DOSBox dev team, so I don't have the say on that.

Well, DosBox is opensource project, I'm not familiar with structure, but you sure can propose your patch to get merged into upstream dosbox 😀 (mailing list, bugzilla or somewhere 😀 )

Thanks for updating your patch 😀 no idea where these ugly .rej came from 😜

Reply 36 of 183, by NY00123

User metadata
Rank Member
Rank
Member

Just informing that I've updated the patch to be compatible with the last SVN revision. For the sake of simplicity I haven't constructed an executable/package for any specific platform (e.g., Windows or Android).

There isn't a lot to add here. It's mostly about compatibility with the last revision again, code sharing between GFX_SetupWindowScaled (SDL 2.0) and GFX_SetupSurfaceScaled (SDL 1.2), and replacements of mentions of the macro ANDROID with __ANDROID__.

Attachments

  • Filename
    dosbox_sdl2_20140712.diff
    File size
    180.33 KiB
    Downloads
    408 downloads
    File comment
    Updated patch against r3869
    File license
    Fair use/fair dealing exception

Reply 37 of 183, by paolo-sz

User metadata
Rank Newbie
Rank
Newbie

Thanks for the great job NY00123, a very useful patch.

I just want to submit another approach about cdrom support: instead of removing support from dosbox (physical cdrom could be useful on some dos games) why not to add back cdrom support into SDL2?
I wrote a patch (attached) for SDL2.0.3 which include back the cdrom support (this means you cannot use the precompiled libraries but you need to compile SDL by your own too). I simply took the cdrom files from SDL1.x and I made some small changes to initialization routines.
Then I reverted the changes about cdrom you made in your patch (the resulting patch is attached too).
By the way, while the SDL patch is exactly the one I'm using to compile SDL and it is 100% working, the dosbox patch is not exactly the one I'm using (my "strange" environment needs some more changes and I also made some additional changes Full mingw build (32 and 64bits) including zmbv codec) so I'm not totally sure it is 100% working.

Attachments

  • Filename
    dosbox_sdl2_20140712_wcdrom.diff
    File size
    12.92 KiB
    Downloads
    169 downloads
    File comment
    Patch against r3869 with physical cdrom support back in
    File license
    Fair use/fair dealing exception
  • Filename
    SDL2-2.0.3.patch
    File size
    289.83 KiB
    Downloads
    176 downloads
    File comment
    cdrom support for SDL2.0.3
    File license
    Fair use/fair dealing exception

Reply 38 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Great idea, a bit cumbersome when SDL2 progresses but physical CDRom support is hard to let go 😉

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 39 of 183, by truth_deleted

User metadata
paolo-sz wrote:

I wrote a patch (attached) for SDL2.0.3 which include back the cdrom support (this means you cannot use the precompiled libraries but you need to compile SDL by your own too).

Thank you to NY00123 for the heavily enhanced SDL2 version of dosbox and to paolo-sz for enhanced cdrom support. Tested these two patches with dosbox-r3869 and built dosbox using mingw32. Attached is one of the two required patches (the modified dosbox patch with android support removed), a binary dosbox package for win32 (no joystick support), and optional instructions to build dosbox below.

For building your own dosbox, then the SDL2 patch is also required (from above post by paolo-sz). However, the binary dosbox package is sufficient to test the SDL2 build of dosbox with enhanced cdrom support (win32 only). Requires testing of both the binary and the patch by the instructions below, so that the patches are verified against the original versions.

The main goal was to provide mingw32 build instructions, so the binaries are to hopefully show that the instructions are valid and that the amended patch is correct. I will remove the binary on request, after a brief time to test.

SDL2
1. Download latest SDL2 snapshot (SDL-2.0.4-9304.zip) which has mingw32 compatibility: https://www.libsdl.org/hg.php
2. Add dx8 headers(**) to /usr/include/directx/ and libraries to /usr/lib/
2. The above SDL2.0.3 patch applies cleanly to the above SDL2 snapshot version, even though the version is newer: patch -p1 < SDL2-2.0.3.patch
3. ./autogen.sh
4. CFLAGS="-O2" CXXFLAGS="-O2 -mno-ms-bitfields" CPPFLAGS="-I/usr/include/directx" ./configure --prefix=/usr --disable-joystick --disable-haptic
(SDL2 snapshot may require a patch to avoid directx8 related errors in the SDL2 joystick code; disabled joystick and haptic in above configure line, haptic should have been disabled by default for mingw builds, so a patch may be submitted to SDL2)
5. make install

** dx8 headers/libs: http://alleg.sourceforge.net/files/dx80_mgw.zip

DOSBox
1. Download dosbox-r3869: http://sourceforge.net/p/dosbox/code-0/3869/tree/
2. Apply attached patch to dosbox: patch -p1 < dosbox-sdl2-mingw32.diff
3. ./autogen.sh
4. configure line:
LDFLAGS="-static-libgcc -static-libstdc++" CFLAGS="-s -O2" CXXFLAGS="-s -O2 " CPPFLAGS="-I/usr/include -I/usr/include/directx -I/usr/include/SDL2 -D__USE_MINGW_ANSI_STDIO=0" ./configure --enable-core-inline --with-sdl2
5. make

dosbox.exe, sdl2.dll, and zlib.dll are the required binaries to run dosbox in this configuration.

Attachments

  • Filename
    dosbox-SDL2.zip
    File size
    1.39 MiB
    Downloads
    195 downloads
    File comment
    dosbox binary package to test SDL2 support (win32; no joystick)
    File license
    Fair use/fair dealing exception
  • Filename
    dosbox-sdl2-mingw32.diff
    File size
    80.32 KiB
    Downloads
    176 downloads
    File comment
    dosbox patch for SDL2 with cdrom support (win32)
    File license
    Fair use/fair dealing exception