VOGONS


DOSBox 0.74-2 has been released

Topic actions

Reply 20 of 54, by NY00123

User metadata
Rank Member
Rank
Member

Congrats on the last maintenance release!

While I'll still use this or that custom SVN-based build for most, it's good to have a branch known to be stable in terms of games compatibility.

Reply 21 of 54, by Xian97

User metadata
Rank Member
Rank
Member

Thanks for the update, this caught me by surprise as I didn't even know it was being worked on after all these years.
It is a great idea to have a stable release with all the current fixes incorporated before going on to the next point release.

Reply 22 of 54, by scrutinizer

User metadata
Rank Newbie
Rank
Newbie

Great news!
Unfortunately the dynamic core still crashes on 64bit Linux only on very specific occasions.
The 100% sure way to reproduce it is to try to run imgmount from within Windows 3.11's command prompt.
It would result in an immediate crash: "Exit to error: DynrecCore: illegal option in dyn_mov_seg_ev".

This does not happen with 0.74 32bit.

Reply 24 of 54, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author
scrutinizer wrote:
Great news! Unfortunately the dynamic core still crashes on 64bit Linux only on very specific occasions. The 100% sure way to re […]
Show full quote

Great news!
Unfortunately the dynamic core still crashes on 64bit Linux only on very specific occasions.
The 100% sure way to reproduce it is to try to run imgmount from within Windows 3.11's command prompt.
It would result in an immediate crash: "Exit to error: DynrecCore: illegal option in dyn_mov_seg_ev".

This does not happen with 0.74 32bit.

I can reproduce it, although slightly different (I just have to start the command prompt under my version of 3.11)

But I haven't figured out what is going wrong. I have some leads, but it is far from trivial.

Water flows down the stream
How to ask questions the smart way!

Reply 25 of 54, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author
digger wrote:

Ooooh, a new DOSBox version. Congrats on the release! 😀

I'm curious though. When are you finally going to migrate from SVN to Git? Being a software developer myself, I cannot imagine any collaborative code base, especially one as complex and popular as DOSBox, not being managed through Git these days. I hope I won't offend anyone by being so opinionated about this, but I'm sure I'm not the only one. Come on, it's 2018! 😉

Nevertheless, thanks for the hard work and keep it up! I'm looking forward to version 0.75.

I don't see how moving to git would make managing dosbox easier or harder.

Water flows down the stream
How to ask questions the smart way!

Reply 26 of 54, by jnm2

User metadata
Rank Newbie
Rank
Newbie
Gene Wirchenko wrote:

Because I need printer support, I do not use vanilla DOSBox. Is there a version of 0.74-2 with printer support available? I am not concerned with whether it is an official version.

Sincerely,

Gene Wirchenko

I have the same question. Jon Campbell's comment (https://github.com/joncampbell123/dosbox-x/is … mment-417774338) made me aware that DOSBox-X's last release has printer support (https://github.com/joncampbell123/dosbox-x/re … windows-v0.82.9). I don't know if that release is based on 0.74-2 though.

Reply 28 of 54, by jnm2

User metadata
Rank Newbie
Rank
Newbie
keenmaster486 wrote:

Guys, this isn't a new feature release. It's a maintenance release.

Right, but if one of the forks which already has printer support is based on this maintenance release, it might fix some ongoing issues we're having while using the SVN-Daum build.

Reply 29 of 54, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Sure but mentioning non-supported features in an official release thread is kind of rude.....

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 30 of 54, by jnm2

User metadata
Rank Newbie
Rank
Newbie
DosFreak wrote:

Sure but mentioning non-supported features in an official release thread is kind of rude.....

Well, I certainly apologize. As a long-time user, DOSBox is awesome! Is it okay if I move our comments to a new thread?

Reply 31 of 54, by digger

User metadata
Rank Member
Rank
Member
Qbix wrote:
digger wrote:

Ooooh, a new DOSBox version. Congrats on the release! 😀

I'm curious though. When are you finally going to migrate from SVN to Git? Being a software developer myself, I cannot imagine any collaborative code base, especially one as complex and popular as DOSBox, not being managed through Git these days. I hope I won't offend anyone by being so opinionated about this, but I'm sure I'm not the only one. Come on, it's 2018! 😉

Nevertheless, thanks for the hard work and keep it up! I'm looking forward to version 0.75.

I don't see how moving to git would make managing dosbox easier or harder.

Branching, merging, pull/merge requests, bisecting bugs that were introduced at some point, off-line commits, among other things. Particularly, it would be a lot easier for other people to contribute and for you to review and accept those contributions.

Seriously, once you've switched, you won't ever want to go back. At the very least, it won't hurt you to switch, but it will help things immensely for many other (would-be) contributors. Have you worked with it much? Give it a chance. It's not too much of an effort to migrate an SVN repository to Git. 😀

Reply 32 of 54, by digger

User metadata
Rank Member
Rank
Member
DosFreak wrote:

Sure but mentioning non-supported features in an official release thread is kind of rude.....

Why would it be, as long as it's well-intended? There's nothing wrong with constructive feedback. It doesn't make us any less appreciative of the hard work that has already gone into DOSBox. At least that's how I see it. 😀

Reply 33 of 54, by krcroft

User metadata
Rank Member
Rank
Member
digger wrote:
Qbix wrote:
digger wrote:

Ooooh, a new DOSBox version. Congrats on the release! 😀

I'm curious though. When are you finally going to migrate from SVN to Git? Being a software developer myself, I cannot imagine any collaborative code base, especially one as complex and popular as DOSBox, not being managed through Git these days. I hope I won't offend anyone by being so opinionated about this, but I'm sure I'm not the only one. Come on, it's 2018! 😉

Nevertheless, thanks for the hard work and keep it up! I'm looking forward to version 0.75.

I don't see how moving to git would make managing dosbox easier or harder.

Branching, merging, pull/merge requests, bisecting bugs that were introduced at some point, off-line commits, among other things. Particularly, it would be a lot easier for other people to contribute and for you to review and accept those contributions.

Seriously, once you've switched, you won't ever want to go back. At the very least, it won't hurt you to switch, but it will help things immensely for many other (would-be) contributors. Have you worked with it much? Give it a chance. It's not too much of an effort to migrate an SVN repository to Git. 😀

Just adding words of support for every benefit mentioned by digger.

I transitioned the organization I work for from subversion to git a couple years ago, and git's distributed nature unlocks and trivializes the collaborative challenges that have historically plagued source control management.

The webgui's like gitlab and github take this to the next level by making code review and commenting so easy and enjoyable. l can't wait for the day when I can submit and online-discuss my first merge request in dosbox 😀

Perhaps the best example is the linux kernel, where git allows them to manage an average of 8.5 code changes per hour. Yes, it's 100-fold dosbox's source, but there are a lot of incredibly talented folks in these forums with skills ranging from assembly, to scripting, to documentation.

I beleive the dosbox devs could hone that talent (through feedback in merge/pull requests) and see dosbox's already-impressive change velocity further improve.

Reply 34 of 54, by scrutinizer

User metadata
Rank Newbie
Rank
Newbie
krcroft wrote:

I beleive the dosbox devs could hone that talent (through feedback in merge/pull requests) and see dosbox's already-impressive change velocity further improve.

Exactly!
People are very much used to git nowadays. Since there's no real downside, NOT using it only hinders development for no good reason.
😕

Reply 35 of 54, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
scrutinizer wrote:
Exactly! People are very much used to git nowadays. Since there's no real downside, NOT using it only hinders development for no […]
Show full quote
krcroft wrote:

I beleive the dosbox devs could hone that talent (through feedback in merge/pull requests) and see dosbox's already-impressive change velocity further improve.

Exactly!
People are very much used to git nowadays. Since there's no real downside, NOT using it only hinders development for no good reason.
😕

The argument comes up often and thus far in two other projects that I'm active in and people begged for git because it would make development so much easier and more often added to, haven't seen any substantial gain from git.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 37 of 54, by Nilex

User metadata
Rank Newbie
Rank
Newbie

Following a hunch because of these two:

  • Replace NV_PixelDataRange with the more common ARB_PixelBufferObject extension. Should help with output=opengl.
  • Reuse graphics window if possible instead of always creating a new one!

I loaded Epic Pinball to see if the board panning still suffers from visual stutter under opengl and yep still does. It's not related to auto/max cycles though, but under same conditions board moves smooth with ddraw. OS is Win7.

One other thing, I read a while ago somewhere on this board that ripsaw mentioned DOSBox had turned on file modify date updating when eg. installing a game. How he said it left an impression on me it was a trivial on/off switch. I believe reason for it was to make user aware of files being manipulated (can't remember). But my preferred method is to have files retain their original dates so I always when back to the source to replace the files I could and for the rest it was Bulk File Changer. There's just something about seeing the years long since passed attached to files of old legendary games. Kind of like having an authentic historic record. So could you pretty please with a sugar on top put an optional on/off switch in the .conf? If it's not too much trouble.

Reply 38 of 54, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Your impression or interpretation of what I wrote is incorrect. Updating file stamps with the current date and time is a natural behavior of the host OS when a file is created or written to. DOSBox would have to implement functionality to modify stamps to something other than what the host OS sets them to, and there is currently no cross-platform solution for that.

Regarding your issue with opengl: ensure that vsync is not forced ON in your video driver, as that is known to cause less than smooth results for DOSBox, at least in some cases.

BTW, there are other places on the forum for posting issues and feature requests; please use those rather than this thread.

Reply 39 of 54, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

http://stuffjasondoes.com/2018/09/13/virtuali … gaming-in-2018/

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline