aside from there being a sticky topic about unofficial builds ?
Things are going to change anyway with what the latest release is.

I'd say there are regression bugs to fix before a next release, as is, 0.74 is less buggy and faster than current svn.

For example, this happens in svn and not 0.74, with tie fighter cd, among others, with opengl in full screen, screen is squashed, shifted left, screen cut off, with ascpect correction, cut off still but black border on top and right of screen, with surface, fullscreen is not fullscreen but banded vertical black bars, with aspect correction a black border all around instead of fullscreen at fullscreen.

speedhaste, crashes from illegal access if try to skip past second credits screen with svn.

really ? That is unfortunate. Thought that the rendering stuff was quite stable in svn. 🙁

(Not speaking about compatibility regressions, purely about the rendering stuff)

To see it yourself, tie fighter cd is referring to the "cd collection" version: https://www.mobygames.com/game/star-wars-tie- … llectors-cd-rom but I think it's a general bug so try it with anything.

I was going try to fix these issues and pop the surprise to be the hero with some patches(regression fixes are easier since you just checkout the tree back in time until the bug goes away and then continue narrowing to the culprit from there in the diff) but if there's talk of releasing my hand is forced to avoid an egg on face release.

I have pmed you something

Not to butt in when the lead dev is already on it, but out of interest is it an issue with a straight svn build or with an enhanced one?

Problems with initial screens of SpeedHaste are not new to SVN, although might be different or "worse" now:
"Speed Haste" Terminates after second logo

Be sure to try the -novbl parameter with the game as mentioned in the linked thread; it seemed quite helpful with the crashiness.

I was wondering if it would be possible for someone to make a sticky topic in the DOSBox forum, explaining that DOSBox 0.74 is the last official buld

That is the latest official build, not the last.

and listing what unofficial later builds there are their enhancements and (if any) regressions their enhancements and (if any) regressions, and what build is recommended for any specific game or whatever.

Why should the dosbox devs bother with unofficial builds when they are busy working on DOSBox.? That is a job for the community.

As it is, fairly often someone posts asking about v0.75, and they are told to use an unofficial build, and pointed towards the builds (as in Next Dosbox update?), but I think that newcomers (and even oldies like me, who don't use DOSBox too often) would often be confused by the different unofficial builds.

As with any project you should always use the builds provided by the project itself and not unofficial builds. DOSBox is not that hard to compile, if you can't compile then pester the DOSBox team to provide an accessible SVN build. IIRC, Qbix has one already but it's not promoted heavily. Prepare to be disappointed if you want whatever is fashionable, it will be pretty much the same as DOSBox 0.74 but with all the fixes since then.

A sticky that listed the stable versions of the unofficial builds, along with a quick guide to how each build compares to the others (i.e. someone might want to have a snapshot function, but doesn't care about long file name support), would help us less DOSBox-savvy people to decide what version(s) to use, and the sticky could be updated every few months or so, or after important releases, to reflect the new builds.

Use the official build, use a clean SVN ver. That's the official stance. Unofficial builds are not stable as far as we are concerned.
If tracking patches applied to unofficial builds is something you care deeply about then requesting access to the DOSBox wiki and posting the information yourself would be a good plan.

It may be worthwhile to gather all the patches out there and list a justification for why each patch should be included in DOSBox as well as how difficult it is to maintain the patch, what OS it's compatible with, if it is for non game purposes, what license it's under, etc etc.

Dominus wrote:

Not to butt in when the lead dev is already on it, but out of interest is it an issue with a straight svn build or with an enhanced one?

Straight, not the size opt and 64 decoder one I've been doing.

To get everyone else up to speed, the fullscreen issue happens with scaler set to a 3x scalar(normal3x,hq3x,) with the added wrinkle this happens with 0.74 too, I had missed that 0.74 was still set to normal2x. Still want to fix this though, simple solution being to set to 2x when going full screen then setting back to whatever scalar when returning to windowed. Whether getting 3x to work full screen or switching, better than unaware users coming in complaining about dosbox being buggy at full screen.

Speaking of bug fixes, even though the s3 emulation is only supposed to go to 4mb, compiling with 8mb gets rid of the flickering in Burnout: Championship Drag Racing where 4mb doesn't. Note, setting to more than the default 2mb kills framerate in quake.

Changing the amount of video memory on the emulated S3 seems to be a "fix this but break that" kind of proposition.

For flickering in games that use VESA modes, the machine=vesa_nolfb setting helps in some cases.

Hey, vesa_nolfb fixes flicker in burnout /w vidmem at 2mb, and flight sim 5.1, duke3d, and nam/ww2 gi, but seal team credits still flicker.

With LFB, some games don't wait at all when page flipping (same as "vid_wait 0" in Quake), some wait for the video enable bit (same as "vid_wait 2" in Quake), some wait for vertical retrace (same as "vid_wait 1" in Quake). Waiting for video enable has low impact on framerate, but is not effective in eliminating flicker on all video cards. Waiting for retrace has considerable impact on framerate, but is almost always effective in eliminating flicker.

Disabling LFB eliminates flicker because there is only one page with bank switching, thus no page flipping.

Also, flicker can be affected by cycles, and using a specific amount of fixed cycles or a cycle limit can help in some cases.

Woof, it took dropping cycles down to 1k, about equivalent to a 286@8mhz to get rid of the credit flicker. Like falcon 3.0 that takes setting to around equivalent to a 386-16 to almost get the intro animation and sound to sync up, neither cpu settings are optimal speed settings for either games' game play.

FYI, applying the v1.23 patch for Burnout appears to get rid of flickering, even with LFB. Search for "burnpt5s.zip" to find places to download the patch.

some other games with bugs that aren't bugs:
star wars: x-wing: fm fails > ~pii 233/140k cycles, starts out clipping then no sound as set higher
comanche maximum overkill: fm fails to init > ~586 66/35k cycles, set to "486 40"/14k cycles for optimum gameplay speed
wolf3d: sound will sometimes fail to be identified at higher speeds
aces of the pacific: intro fails > ~586 75/40k cycles, set to 486 50/66/17.5k/23k cycles to get working again without restarting dosbox.
aces over europe: sometimes no keyboard on startup, can be instigated by trying to skip intro, speed issue?
1942 paw: some keys stop working from selecting alt-f1 view, seems laggy, a cyclical pause, but maybe how the game is, hard to tell

Qbix wrote:

Things are going to change anyway with what the latest release is.

Wow, that is the first time in years that I have heard a dev volunteer the idea of a new release 😀

well, it will be a maintenance release, but it is in preparation for a full release, so the former current release can be used if we break your favorite game in the new full release.