Actually there is just one unofficial build - ykhwong

Huh???

Any way people were asked long time ago to not publish development builds and it worked fine
that way for a good while. Things were thoroughly tested on the beta board and cvs/svn builds
were accessible for people who really did development and testing.

For whatever reason some people later didn't care about the devs request to not freely publish
developer builds and as of now things are imo useless from a development point of view
because it's not controllable like that (going for a few years like this now but i stopped to care).

NewRisingSun wrote:

I have most of this already written; it would only have to be slightly optimized and adapted for inclusion in DosBox. But I'm not going to bother if I'm told in advance that it would just end up being the hundredth unofficial build.

Well, it's good to know that a "monitor=" config setting could be up for consideration, according to Qbix. If the target is to have at least composite and RGB for a start, then we already have most of that. And if your code could be easily adapted for DOSBox with the 16-color modes intact, that's definitely something I'd like to see. 😀

On the other hand, that still leaves open the question of how to control the various parameters of composite emulation... old/new CGA included.

wd wrote:

Huh??? […]
Show full quote

Actually there is just one unofficial build - ykhwong

Huh???

Any way people were asked long time ago to not publish development builds and it worked fine
that way for a good while. Things were thoroughly tested on the beta board and cvs/svn builds
were accessible for people who really did development and testing.

For whatever reason some people later didn't care about the devs request to not freely publish
developer builds and as of now things are imo useless from a development point of view
because it's not controllable like that (going for a few years like this now but i stopped to care).

In the first year of dosbox developement (2002) new dosbox version was released monthly, was tested only by few developers and there were no patches for it so there was no need for cvs/svn builds. Ykhwong build appeared immediately when the gap between versions become longer (2003).

The thing is that it is always the cheapest/most compatible/fastest developing project that takes the most testing. So if dosbox cannot handle something and no perspectives of handling it in near future testing goes to: real old machines people buy to play their games, vmware, virtualpc, dosbox with gulikoza's voodoo passthrough with glide wrappers (right now with nglide - the fastest developing one - if not the only developing one), the mame version of dos pc, and svn builds of dosbox with patches handling different people needs.

Of course the best thing for dosbox developers would be if all the testing went to main dosbox but the truth is that the only way of increasing amount of dosbox (and any other software) testers is the speed of development. Banning people from using svn builds won't help it.

So if dosbox cannot handle something and no perspectives of handling it in near future testing goes to

That's the problem, people can't wait and the result is what i described as uncontrolled. It worked differently before (your timeframes are irrelevant as of the availability to english-speaking people) and i'm not interested in discussing this further. And posting that somebody intends to "ban people from using svn builds" is utter crap.

I am not sure the uncontrolled is really that harmful. Main dosbox is tested less - that is minus point. But there are also plus points: There is a possibility that a person who couldn't play a game with main dosbox woudn't play that game at all later cause he woudn't have time for that in the future. But he was able to play it with some svn build and found a bug. If that bug doesn't happen in main dosbox - no problem (ok, some time wasted for checking that). If the bug happens in main dosbox too - he found a bug - plus point.
It is also possible that some bug will happen in main dosbox but won't happen in some svn build - this may help finding the bug - maybe not the most convenient way but always better than nothing.

I think, if dosbox is released later the result is it is tested by different people who have free time at the date of release, not by the people who waited a few years cause it is very probable they will not have free time later. The general rule is the older you are the less time you have. And younger ones may not be interested in dosbox at all, as they never used dos. So the more time passes the less testers dosbox may have.

Also the number of people who really do development and testing is limited and their time is limited too and they cannot check everything. Actually most bugs are being found by normal users.

Perfect solution was not achievable already at the date of dosbox release.
The perfect solution would be - a finished dosbox was released 14 years ago. And for 14 years people were only confirming everything is working perfectly. This would give the largest number of testers and every single part of dosbox's code would be tested for the longest possible amount of time 😉

Long release cycles are not the reason but a result of that. As i said i no longer care.

Carrying over some relevant discussion from Re: An old game (Zak McKracken and the Alien Mindbenders) has display problem ...

Anyone care to guess what's up with Zak McKracken's composite CGA mode? It uses mode 4, but the colors don't make much sense, on any of the machines discussed so far; see attachments for comparison. By extension this also applies to Maniac Mansion (and to the enhanced versions of both games).

I guess new CGA comes closer than the others, but it's still a stretch... of course, it's entirely possible that composite color support was more of an afterthought at that point, and they never really bothered to make it look decent. Don't know why they didn't just use mode 6 -- that palette would have been a better fit, as demonstrated by Sierra.

The composite colors do make some kind of sense in Zak. They managed to get Zak's skin to look a flesh color with CGA and sky and water are blue, but not to make the leaves on his plant green or the wooded objects brown. Only the solid black, white and cyan colors make sense in the Tandy and PCjr. modes.

Early SCUMM's so-called composite mode is unusable nonsense, as it just uses the RGB color numbers.

Now that I actually look at the patterns, that makes sense - no use in testing these games, then. Good to know.

While I can't say that I really got to experience any composite mode on a composite display back then (although a built-in monochrome monitor accepting an NTSC signal was used)...

Very good job over there! I can't say that I understand everything, and I'm sure you know what's done here better than me 😀

There's one goal I can agree on: Try to make things as authenticate as possible. Not smooth, nor pretty; Just authenticate.

However, I realize that goal may require the ability to adjust some settings like hue and brightness (please correct me if I'm wrong). Thinking of the way it's done on older TVs and computer displays... Well, if DOSBox had a GUI with knobs or something, these could be used to control the settings, probably; And then, of course, the settings would saved to somewhere. (I *think* you wouldn't expect a TV to reset it's brightness, right? 😀) Maybe the current conf file can be used for this (already discussed, I know), and maybe a different file (probably a bad idea).

I guess the knobs are one of the few examples, where a touch-screen would make the controlling of these more similar to the real thing than a mouse would. (Hehe)

Well, think that I'd be done now. As usual, there's zero promise that any suggestion is to be incorporated into an official DOSBox release.
Good luck to all!

Interesting! I found a few more games that appear to target the PCjr rather than CGA (intentionally or not).

Frogger II takes both CGA and PCjr into account to display reasonable colors on both (shots of each on Mobygames now). I found that if I took RGB captures in DOSBox that with machine set to PCjr the pixels are all shifted one to the left.

Pitstop II has always bugged me on CGA; it uses green foreground color instead of white, and the results on CGA are a more or less useless blue/green tinted image. On the PCjr however, it ends up as something much more useful! (attached image)

Wilderness: A Survival Adventure I'm not sure about; the dithering patterns lead to some reasonable colors on PCjr (more so than CGA) so it looks intentional. Either way I find it to be the best looking option for the game.

can you check these too:
I, Damiano: The Wizard of Partestrada
Sherlock Holmes in "Another Bow"

The blue trees for PCjr don't seem intentional, unless they're supposed to be blue spruces 😀 The Wilderness shots on Mobygames look like RGB rather than composite, so they don't provide a good CGA versus PCjr comparison.

there are blue trees in sierra games too (and green water) so you never knows
download.php?id=10510
😉

Servo wrote:

Frogger II takes both CGA and PCjr into account to display reasonable colors on both (shots of each on Mobygames now). I found that if I took RGB captures in DOSBox that with machine set to PCjr the pixels are all shifted one to the left.

Nice find - on top of that one-pixel shift, it also seems to change the hi-res foreground color to 9 (blue), at least when I try with machine=pcjr. I'll have to check and see how well that matches your images.

Servo wrote:

Pitstop II has always bugged me on CGA; it uses green foreground color instead of white, and the results on CGA are a more or less useless blue/green tinted image. On the PCjr however, it ends up as something much more useful! (attached image)

Definitely looks heaps better than CGA, though in this case no thanks to artifacting... it just seems to be using 16 solid colors: now that I tried it in DOSBox with machine=pcjr, if you hit "1" on the monitor select screen you get mode 8, aka 160x200 in 16 colors (see attached for a straight RGB screenshot).

This looks nice enough in both RGB and composite, which makes option "2" kinda useless on the PCjr. Never knew that the game supported this - there are no PCjr screenshots on MG at any rate, so I guess I'll go ahead and submit some now. :)

Ah, missed that with Pitstop II...when I made the capture I also checked in DOSBox to see what the RGB looked like and I got the same result as CGA, but I was in a hurry and must have forgotten to change machine to pcjr or something; I just tried again now and it worked. Very neat, I didn't know this was supported either. Still makes me wonder what in the world they were thinking with the CGA composite version.

Which version of Pitstop II are you using? My version displays mode 4 graphics even with machine=pcjr.

Tested two versions from Retrograde: the booter image behaves the same with pcjr as with cga (i.e. sets mode 6 if you pick display option #1); the EXE conversion sets mode 8 when machine=pcjr, and that's the one I checked first (and evidently Servo as well).

Both will use mode 4 if you pick display option #2. It's quite possible that there was a different / updated version that supported PCjr graphics, and the exe was sourced from that. The display selection screen doesn't make too much sense with that in mind, but given the colors in the composite CGA version, making sense evidently wasn't a priority.

Indeed, PITSTOP2.EXE is different. Given the differences observed with other DOS conversions (Bruce Lee and Microsoft Decathlon, for example) it might be a good idea to compile a list of differences between booter versions and DOS conversions of each booter game.

VileRancour wrote:

It's quite possible that there was a different / updated version that supported PCjr graphics, and the exe was sourced from that.

I find that unlikely. It rather seems to me that whoever did the DOS conversion also did a quick PCjr graphics hack for the composite mode, as evidenced by the ugly-looking font. Any other game either uses mode 9 for sharper text, like Sierra AGI games, or adjust the font for mode 8 to not produce "transitory" pixels (i.e. between M and P in MPH), like California Games or the non-enhanced Maniac Mansion/Zak McKracken.