Reply 20 of 54, by NY00123
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.
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.
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.
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.
Thanks for fixing the NUMLOCK glitch. That was annoying.
Is this too much voodoo?
wrote:Great news! Unfortunately the dynamic core still crashes on 64bit Linux only on very specific occasions. The 100% sure way to re […]
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!
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!
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.
Guys, this isn't a new feature release. It's a maintenance release.
World's foremost 486 enjoyer.
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.
Sure but mentioning non-supported features in an official release thread is kind of rude.....
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?
wrote: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. 😀
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. 😀
wrote:wrote: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.
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.
😕
wrote:Exactly! People are very much used to git nowadays. Since there's no real downside, NOT using it only hinders development for no […]
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.
Wait until the SDL2-and-nothing-else begging from linux downstream comes into play...
Following a hunch because of these two:
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.
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.