Reply 260 of 294, by James-F
- Rank
- Oldbie
As of SVN r4012 Gobliins 2 sound is still a mess.
As of SVN r4012 Gobliins 2 sound is still a mess.
This is not the right thread for bug reports. Start a new one and make sure to try a vanilla svn build
Thanks Dominus.
I am registered on SourceForge so the bug reports go there, but is it wise to start a new thread for a small bug report or comment?
As part of some other projects *I* like single bug reports better. I have had the experience that bug reports in other threads tend to get lost in the noise and derails threads. This thread is a prime example as it was intended to list the varios SVN builts that are available. It has long been derailed, though 😉
So my thoughts are its best to log a proper bug report on SF and start a new thread unless it kind of fits in another thread. Here I think the ECE thread would have been more appropriate sine the problem started with the changes discussed there. But then again that thread has been derailed as well 😉
Edit: but then I'm only speaking from my experience, I'm only a moderator here, not a DOSBox developer 😉
Is it still a good idea to use Daum's DosBox build? I really like it's ease of use, it's features and it's UI, but it's super behind actual DosBox builds. Has anything surpassed it for usability?
It is also broken.
wrote:It is also broken.
Ooof. Is it really? That might explain a few things.
So what should I switch to nowadays?
ECE if you like the bells and whistles.
All hail the Great Capacitor Brand Finder
ECE seems pretty great, but I'm gonna miss the UI of Daum's. 🙁
Probably worth the trade to get working software and a developer who's still active.
There's also quite a few frontends in active development to make setup more pleasant. If you have specific features you want included, try to find one with a developer team which allows you to actively contribute via your ideas, testing, coding, and encouragement.
All hail the Great Capacitor Brand Finder
The thing about the (G)UI that makes it a feature not just a convenience is changing the defaults of the conf file(s) as the game is running, not just at the start, if for some reason you can't or don't want to change your defaults for that game (i know about dosbox support for 'onion' confs).
Though, it's not surprising that that fork/patch is dead honestly. GUIs are always messy platform specific things, and when you have multiple unrelated dosbox patches with new options on top...
I sure won't put such a patch in my ppa even if it existed.
Well, if you had real hardware, you wouldn't be changing much in the way of configuration details without a reboot.
All hail the Great Capacitor Brand Finder
Eh. What does it mean to change the scaler on 'real hardware'? Some settings don't have a equivalent. For sure, if it's dangerous to change it outside of the shell, by all means disable it, but some are perfectly safe.
wrote:What does it mean to change the scaler on 'real hardware'?
Changing monitors, of course!
All hail the Great Capacitor Brand Finder
Speaking of scalers, is it still normal for scalers to not work with machine=vgaonly in the latest CVS version? (r4025)
Tried using it with scaler=normal3x and aspectratio=true, but it doesn't work, instead I get a weird normal2x scale with ugly stretching.
Also been getting a lot of buffer underrun errors with ALSA (Debian Sid), so I wonder if anyone has such problems as well.
Is there any more up-to-date build than Daum that has pixel shaders? Daum works most of the time but some games don't work (which do work in the main build).
I found that r4044 runs extremely slow when starting RICH3. (rths.cf/tmp/rich3.zip)
My latest builds of DOSBox SVN r4059 crash whenever I close them via the "X" in the title bar. Closing it by entering "exit" in the DOSBox windows works, however. I tried it on several PCs, it happended all the time. Can anyone confirm this error?
My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)
wrote:My latest builds of DOSBox SVN r4059 crash whenever I close them via the "X" in the title bar. Closing it by entering "exit" in the DOSBox windows works, however. I tried it on several PCs, it happended all the time. Can anyone confirm this error?
Yes, confirmed from my side. It wasn't there in old versions, atleast in r4019.
One more thing observed, more like a minor regression, is that the load time between the title screen and game screen has increased considerably in Lure of the temptress since r4047 commit(MPU related!!!). In older dosbox builds, the blue note symbol on bottom left used to flash only once between the title screen & prelude(text) as well as between the end of prelude & initial game screen. But since r4047, the blue note symbol flashes 10-11 times in both instances in my system