VOGONS


First post, by Silanda

User metadata
Rank Member
Rank
Member

Hi. I don't normally make desperate pleas to application developers but, unless there's some critical problem with it, could a DOSBox dev please implement the fix described in this bug report: https://sourceforge.net/p/dosbox/bugs/385/

There are quite a number of games that use 15 and 16-bit modes that are affected by this, and I'm assuming that OpenGL is the preferred output mode of most users. The author of the suggested fix seems to have tested it in Linux, and I've been running my own Windows builds for years with the fix with no apparent ill effects.

Thanks for reading.

Reply 1 of 10, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Why desperate? As you suggested previously, you could compile your own build with the patch applied.

BTW, not only VESA modes; machine=vgaonly is also affected because it uses higher color depth to emulate palette tricks.

I believe that Harekiet is considering the proposed solution, as I mentioned it before after noticing vgaonly fall back from opengl to surface output.

Reply 2 of 10, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

I tried removing these two checks as suggested and at least I could now run Screamer 2 and Screamer Rally using the start65h.exe, which runs the game in 640x480 with 65K colors. I crosschecked it by using my regular ECE build and DOSBox crashed instantly when running the games with the same settings, as it already did before.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 3 of 10, by Serious Callers Only

User metadata
Rank Member
Rank
Member

My ppa applies this patch for a long long time. I honestly figure out the only reason it's not upstream is that dosbox devs have been neglecting some areas of the code for a long while.

Reply 4 of 10, by DosFreak

User metadata
Rank l33t++
Rank
l33t++
Serious Callers Only wrote:

My ppa applies this patch for a long long time. I honestly figure out the only reason it's not upstream is that dosbox devs have been neglecting some areas of the code for a long while.

That's just like your opinion man.

Keep them out of threads where they don't belong.

If you have something to contribute then bring it up with a dev.

How To Ask Questions The Smart Way
Make your games work offline

Reply 5 of 10, by Serious Callers Only

User metadata
Rank Member
Rank
Member

In a thread about the bug, my opinion that the bug wasn't fixed in spite of having a logical and explained patch for 5 years is because dosbox devs aren't touching that code 'doesn't belong'.

Sure man.

Meanwhile i try to defend dosbox far greater usability in other forums when people say dosbox is total trash and to use MAME or PCem cause they can't figure out munt or install a dosbox with the mt32 patch. Guess i should stop since unfixed 5 year old bugs with patches means they're right to rag.

Reply 6 of 10, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

I don't understand why all the drama?

Also, SCO (unfortunate name if you're shipping Ubuntu packages...), common man, it was a few months ago. Can't we just take it easy?
Star Trek Final Unity - Window Size

All hail the Great Capacitor Brand Finder

Reply 7 of 10, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Well i was irritated at the time because i had just 'accepted' that some games caused screwy resolution behavior (my usecase was one of the intro videos of Tomb Raider going slide-show-esque because of this iirc). Finding out that the patch was sitting on sourceforge for 5 years didn't endear me to this.

I understand people move on and software needs to get people that know the code and the engineering to maintain it, and it's not easy to get those qualities, but i'd at least expect maintenance. If not, please announce you're looking for qualified help for graphics because it sure looks like it when even minimal bugfix patches don't get in or get a review stating why not.