VOGONS

Common searches


dosbox-staging (DOSBox Git repo)

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 123 of 236, by llm

User metadata
Rank Newbie
Rank
Newbie

so no Problem with C+11 under OS/2 - even a little bit C++14 😀

@the primary dosbox developers
is there a list of used first class/second class operating systems that needs support
and the used development environments for these?

First class: - most downloads, user-feedback
Linux?
Windows (7,8,10) - what is used for release builds? mingw/VS2010?
Mac?
...
Second class: - also in use but not that hardcore needed
OS/2, ArcaOS (Version?)
...
maybe as orientation see build/and on the page below older build versions: https://www.scummvm.org/downloads/ (i know that scummvm is less hardware demanding, there are many platforms that are not capable to run dosbox smooth)

just to get a clear overview what is needed for dosbox-staging to build on the CI

Reply 124 of 236, by dreamer_

User metadata
Rank Member
Rank
Member

4th patch series

…was just submitted for inclusion in SVN. You can follow the discussion in here: https://sourceforge.net/p/dosbox/patches/284/ (yes, this is the same thread as series 2 and 3, as the discussion on series 3 stalled).

This series consists of all the changes from series 2 (slightly revised), series 3 and all new relevant commits.

You can browse these patches on GitHub: https://github.com/dreamer/dosbox-staging/com … ...b86c178e67d0 (or just checkout branch po/svn-patch-series-4).

Some news from dosbox-staging.

  • We have automatic snapshot release builds (they are built on every push to master and every new branch from now on).
  • Nightly Coverity builds are enabled; we are giving out defect reports read access to everyone who asks (we can't make them just open for some Coverity reason).
  • All defects fixes we implemented are included in patch series 4. These include fixes for resource leaks, integer overflows, uninitialized values and others. We also have some small bugfixes and not-so-small code cleanups. In total there are 78 patches in this series.
  • We sent or pointed out fixes to other upstreams as well (dr_libs, stb_vorbis), and some of them implemented the findings already (fixes to these libs are included)

Download links:

Last edited by dreamer_ on 2019-12-11, 11:59. Edited 1 time in total.

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 126 of 236, by dreamer_

User metadata
Rank Member
Rank
Member
llm wrote:

the links are dead

Hmm, they do work for me… Thanks for pointing it out. (investigating)

[edit]
Should be fixed now. Attachments to release drafts on GitHub seem to downloadable only by project maintainers.

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 127 of 236, by Yesterplay80

User metadata
Rank Member
Rank
Member

Would the patches I use for ECE be of any use to you, or do you only want to integrate your own patches into dosbox-staging? In case you have any use for them, here are those I use for ECE, also included are the scripts I use to compile it under Windows and Linux, though they shouldn't be necessary, the patches are numbered in the order they're applied.

Attachments

  • Filename
    patches.zip
    File size
    706.78 KiB
    Downloads
    14 downloads
    File license
    Fair use/fair dealing exception

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 128 of 236, by dreamer_

User metadata
Rank Member
Rank
Member

@Yesterplay80, thank you so much! The patches you maintain were already helpful to me in the past, and having them properly imported will make it much easier to work with in the future 😀

I imported these patches to the repo, they are on branch po/ece-r4301-1 (commits 77a46...ab12a); during import I cleared trailing whitespace errors and filled authorship information for patches, that I knew (e.g. Add Nuked OPL3 emulator v1.8). If you have a list of threads where other changes were discussed, I can add the same info to other patches as well.

Since they are in Git, they can be accessed e.g. like this:

$ git clone https://github.com/dreamer/dosbox-staging.git
$ git checkout po/ece-r4301

… but also re-exported from Git back to patches, if needed:

$ git format-patch -14

This generates 14 numbered patches (see attachment); these patches can be applied one-by-one with `patch -p1`, or all at once with:

$ git am ../ece-patches-git/*.patch

Which will automatically apply them in the correct order, fill-in authorship information, commit messages, etc. But when working with pure Git, it is much easier to just do: `git rebase origin/svn/trunk`.

Aaanyways, I can't apply them to the master branch directly, as even the first patch will cause conflicts with SDL2 work, but once SDL2 will be merged in, the work on cleaning-up and integrating other patches in this series will start (except krcroft's patch, because it was already carefully split into smaller chunks and merged-in over several PRs 😀 ). That being said, some of them do not conflict with SDL2, so if anyone cares about them very much, then the fastest way to see them in master branch is by sending a PR 😉.

Attachments

  • Filename
    ece-patches-git.zip
    File size
    712.45 KiB
    Downloads
    7 downloads
    File license
    Fair use/fair dealing exception

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 129 of 236, by aaronp

User metadata
Rank Newbie
Rank
Newbie

git cherry-pick is the best way to grab commits from one branch and apply them to another, right? I maintain my own pkgbuild with select patches, which I think are all patches that are already in ECE, but some I don't use (like fluidsynth, which causes issues for me and I just enable fluidsynth with a systemd user service anyway). This might make it easier for me than a bunch of separate patches.

Also I'm looking forward to SDL2 so I can play something besides strategy games on dosbox again. Booting into real dos on pcem is making me really appreciate dosbox. 🤣

Reply 130 of 236, by dreamer_

User metadata
Rank Member
Rank
Member
aaronp wrote:

git cherry-pick is the best way to grab commits from one branch and apply them to another, right?

Correct 😀 You can pass several commit ids to `git cherry-pick`, and it will apply the commits in order (it is very similar to rebase in practice).

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 131 of 236, by dreamer_

User metadata
Rank Member
Rank
Member

SDL2 support was merged to dosbox-staging master - going forward, only SDL2 will be supported (there's no way to switch back to SDL1-based build). This allowed us to do a lot of code cleanups and allows for implementing new features, that would be impossible with SDL1.

We could really use some more testing - especially on Windows and macOS (e.g. we would really love to hear if Metal backend for macOS works!). To enable Metal on macOS, use: output=texture texture_renderer=metal

Does anyone know how to package DOSBox for macOS? It would be really handy if we could generate snapshot packages the same way we do for Linux and Windows.

SDL2 fixes so many issues, that it would be hard to list them all…

So far we found 3 regressions though:
- (Linux) using vsync with any hw-accelerated backend destroys performance on x86_64 and ARM builds
- (Linux) very rarely, resolution is slightly off resulting in incorrect scaling (e.g. 320x199 instead of 320x200) or breaking aspect=true
- (Windows) when using fullscreen=true, game window is broken after leaving fullscreen with Alt+Enter

Attachments

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 132 of 236, by Ringding

User metadata
Rank Newbie
Rank
Newbie

Building the macOS bundle should be quite straightforward and consists mostly of copying files in the right places. I would be surprised if the script that does this is not included with the DOSBox sources. Maybe I can look into it over the next few days.

Reply 133 of 236, by dreamer_

User metadata
Rank Member
Rank
Member

Just small end-of-the-year summary for the project 😀

Since the repo was created, we made 331 commits, implementing a range of changes - not only big ones (new CD-DA emulation stack, SDL2), but also multiple fixes for tiny bugs or weird edge-cases, and a number of code cleanups - bringing overall number of GCC -Wall warnings from ~360 to ~170 and fixing ~70 static analysis issues (hard to tell the exact number, because Coverity scans are not operational ATM).

Out of these, 78 commits were sent as patches upstream to SVN, but only ~4 were merged in so far - hopefully, we'll pick a bit of steam in incoming months 😀.

master branch includes all changes from SVN trunk (r4302 ATM)
po/ece-r4302-1 includes all ECE patches (rebased to r4302, with some additional metadata included in the commit messages)

Happy 2020, everyone! 🥳

Attachments

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 134 of 236, by aaronp

User metadata
Rank Newbie
Rank
Newbie

Great work! I can confirm that the port to SDL2 fixes the input issues on Linux! There's also the plus that you can now use alt+tab and media keys in fullscreen, though it doesn't currently detect a loss of focus and pause emulation.

Also! It's much easier for me to merge in patches and maintain my own local branch using git, which is a big plus.

Reply 136 of 236, by latalante

User metadata
Rank Newbie
Rank
Newbie
aaronp wrote on 2020-01-01, 01:11:

Great work! I can confirm that the port to SDL2 fixes the input issues on Linux! There's also the plus that you can now use alt+tab and media keys in fullscreen, though it doesn't currently detect a loss of focus and pause emulation.

Under Xorg and Xwayland, dosbox loses fullscreen.
It only works properly under Wayland. Finally, I can quickly and easily leave the full-screen dosbox and return to it.
The main advantage of the SDL2 port is the native operation under Wayland.

There are also bugs leaving the full screen (alt-enter) from Jazz Jackrabbit Holiday Hare ends with general protection fault.

Reply 138 of 236, by dreamer_

User metadata
Rank Member
Rank
Member
awgamer wrote on 2020-01-01, 12:25:

Is the incorporated mt32 emulation in the same process or threaded? Running munt would still be the way to go with it being a separate process if the former.

It's only on ECE branch ATM (not on master) - I haven't looked into details of threading yet. Implementing mt32 on master branch will require more work - munt is not packaged by any repository (not for Linux, not in brew for macOS, not in vcpkg for Windows), so we'll need to implement some buildsystem changes first to make it easy to (conditionally) compile.

I agree, that running mt32 emulation on the same thread as the main emulation would be unacceptable (same goes for fluidsynth patch BTW).

aaronp wrote on 2020-01-01, 01:11:

(…) though it doesn't currently detect a loss of focus and pause emulation.

The behaviour that I'm seeing on Linux is:
- When in the window mode, alt-tab does not pause the game at all (this is expected and ok IMO)
- When in fullscreen, alt-tab does pause the video, but emulation is still on (you can hear sounds). This is unexpected, and am inclined to treat this as a bug.

I noticed behaviour on Windows 10 is a bit different; the code switching pause on/off when losing focus is a bit hairy and it's totally possible I introduced a regression but can't see it on my DE.

Looking for opinions here:
What should be the DOSBox behaviour when losing focus (when in window and when in fullscreen)? Once decided, I will try to make it consistent across platforms.

latalante wrote on 2020-01-01, 11:28:

Under Xorg and Xwayland, dosbox loses fullscreen.

Huh? I know about one Gnome bug which results in dosbox "losing" fullscreen - maybe that's what you are seeing. What desktop environment (and version) are you using? The bug I'm talking about happens in Gnome 3.30 and 3.34 (not in 3.32!), it looks as if fullscreen windows was moved down a bit, leaving part of wallpaper visible in the top of the screen.

latalante wrote on 2020-01-01, 11:28:

It only works properly under Wayland. (…) The main advantage of the SDL2 port is the native operation under Wayland.

I wouldn't call it main advantage, but at least it works (even if it's buggy ATM) 😉

Under Wayland, there are two cases to consider:
- (default) running via XWayland - this works ok, I saw no problems (0.74-3 via XWayland is totally unusable)
- Native Wayland - this works, but is extremely buggy ATM - we'll need to address the issues.

To test native Wayland, you need to start dosbox-staging this way:

$ SDL_VIDEODRIVER=wayland ./dosbox <args>
latalante wrote on 2020-01-01, 11:28:

There are also bugs leaving the full screen (alt-enter) from Jazz Jackrabbit Holiday Hare ends with general protection fault.

I haven't noticed that (I did some testing using Jazz) - was this under Wayland/XWayland?

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 139 of 236, by latalante

User metadata
Rank Newbie
Rank
Newbie
dreamer_ wrote on 2020-01-01, 13:38:
latalante wrote on 2020-01-01, 11:28:

Under Xorg and Xwayland, dosbox loses fullscreen.

Huh? I know about one Gnome bug which results in dosbox "losing" fullscreen - maybe that's what you are seeing. What desktop environment (and version) are you using?

i3
Edit:
I checked under another wm - notion, under it fullscreen is not reachable at all (the dosbox window falls into the focus loss loop).
It looks like the returning demons from this thread. I remember that the only effective remedy for this was to reverse this commit.
https://gitlab.freedesktop.org/xorg/xserver/c … accb7c79bc00f6a

dreamer_ wrote on 2020-01-01, 13:38:
latalante wrote on 2020-01-01, 11:28:

There are also bugs leaving the full screen (alt-enter) from Jazz Jackrabbit Holiday Hare ends with general protection fault.

I haven't noticed that (I did some testing using Jazz) - was this under Wayland/XWayland?

Under Wayland/XWayland (sway) and xorg (i3).
fullresolution = desktop
output = opengl

Archlinux.
traps: dosbox[67300] general protection fault ip:5715ef sp:7fff01ab56e0 error:0 in dosbox[400000+375000]

Edit:
Attempting to build it yourself ends with a configure error:

./autogen.sh ./configure [...] ./configure: line 5867: syntax error near unexpected token `noext,' ./configure: line 5867: `AX_C […]
Show full quote

./autogen.sh
./configure
[...]
./configure: line 5867: syntax error near unexpected token `noext,'
./configure: line 5867: `AX_CXX_COMPILE_STDCXX_11(noext, mandatory)'