VOGONS


First post, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

Actually 2 topics, the second more of a feature request/question....

First, what versions of SDL and SDL_Net is DOSBox looking for at compile time. The properties of SDL.DLL details says 1.2.13, but the size is totally different from both the release version and what I end up compiling of that version. I wouldn't ask, except that for some reason, my compile completely loses DDraw access with "Failed to create DDRAW surface" error. I put the DLL files (actually only the SDL.DLL file,) that come with the release package in and DDRAW comes right back. I've gotten libpng and zlib working just fine, but cannot get SDL working. I tried installing the DirectX SDK (I really thought that was the issue,) and incorporating it with VS, but that didn't help. It seems to me that it all falls down to my compile of the SDL libraries, but I cannot figure out what I'm doing wrong there. Any help at all would be greatly appreciated. Is it possible that there is a configuration or setting I'm missing on my compile of those libraries?

Next, or last, or whatever. DOSBox is great at emulating all the different resolutions of old graphics cards. There is only one problem, the old cards would have a internal and an external (my definitions, not official,) aspect ratio. No matter the actual pixel resolution, it would display at the 4:3 aspect of the monitor. So, the 8:5 of the 320x200 CGA screen would actually come out 4:3 on the monitor. From what I understand, this was done by reshaping the pixels (oval instead of square.) I could have that wrong, though. I've tried setting up specific resolutions (640x480, 1024x768, etc...) that are 4:3 and setting aspect=false, but that doesn't help. I've tried surface, overlay, ddraw (thus my discovery of the failure and desperate attempt to fix it,) opengl, & openglnb without any luck. Finally, I've tried every one of the scaler's (_forced as well,) with some rather startling results at times, but again no luck. Is this something DOSBox is even capable of? If not, is it something that may be possible in the future? Am I missing something in a setting somewhere? I'd sort of like to get my games displaying at the aspect ratio they originally displayed at (320x200 actually appearing to be 320x240, just the pixels stretched vertically a bit - 20%.) ** Note, this holds true with official .74, the SVN, and my own compile. **

Feeding Dragon

Reply 1 of 17, by ripa

User metadata
Rank Oldbie
Rank
Oldbie

Issue #1: Dosbox uses a custom SDL-1.2.12 DLL to fix some issues with DirectDraw. You can find the modifications in src/platform/sdl-win32.diff. I think you could apply that patch to the latest SDL 1.2.x too.

Issue #2. To always get 4:3 aspect ratio, simply use aspect=true. If you're still getting stretched/widescreen aspect ratio, adjust your monitor or graphics card settings to not mess up the aspect ratio.

Reply 2 of 17, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie
FeedingDragon wrote:

So, the 8:5 of the 320x200 CGA screen would actually come out 4:3 on the monitor

The original CGA screen never had a screen aspect ratio of 8:5, because the CGA does not output square pixels. In 320x200 mode, the CGA outputs at a pixel clock of 7+7/44 MHz, which given NTSC frequencies (under which square pixels would need to occur at a frequency of 6+3/22 MHz) translates to a 6:7 pixel aspect ratio on a NTSC reference monitor. Therefore, the original CGA screen has a (8/5)*(6/7) = 48/35 ~ 1.37 screen aspect ratio, which is almost 4:3, the difference being too miniscule to emulate.

ripa wrote:

Issue #2. To always get 4:3 aspect ratio, simply use aspect=true. If you're still getting stretched/widescreen aspect ratio, adjust your monitor or graphics card settings to not mess up the aspect ratio.

Not in text modes. Standard DosBox seems to enforce a 1:1 pixel aspect ratio in these for reasons unknown to me, whereas SVN Daum does not.

Last edited by NewRisingSun on 2014-04-20, 17:17. Edited 1 time in total.

Reply 3 of 17, by ripa

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

Not in text modes. Standard DosBox seems to enforce a 1:1 pixel aspect ratio in these for reasons unknown to me, whereas SVN Daum does not.

Yes, of course not. I always forget that the aspect ratio correction does not apply to text mode.

Reply 4 of 17, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
ripa wrote:

Issue #1: Dosbox uses a custom SDL-1.2.12 DLL to fix some issues with DirectDraw. You can find the modifications in src/platform/sdl-win32.diff. I think you could apply that patch to the latest SDL 1.2.x too.

Ooh, I didn't see that... Is this listed somewhere, some instructions I missed? If so, apologies to all concerned.

ripa wrote:

Issue #2. To always get 4:3 aspect ratio, simply use aspect=true. If you're still getting stretched/widescreen aspect ratio, adjust your monitor or graphics card settings to not mess up the aspect ratio.

That's just it. I've tried it with both aspect set to true and false. It always comes out in it's native ratio, the actual resolution will change, but the ratio remains the same. For example, if I set a 640x400 screen to display at 1024x768, it will actually display around 1024x640 (8:5 instead of 4:3.) If I set it to my monitor's resolution of 1366x768, I get around 1229x768. Have to bring up a box and use graphics programs to measure the pixels.

Some more details:
Surface - No resizing whatsoever regardless of what the aspect or scaler values are set too. I have to specify original for full screen and let my monitor do the adjustment (it does a good job, but maintains aspect ratio - so 8:5 or whatever.)

opengl(nb), overlay, and ddraw all will resize the display, so that's what I'm working with:
aspect=true - aspect ratio remains true to the original pixel resolution regardless of the aspect ratio of the target resolution. Tried this with scaler set to every single one listed in the config file, with and without _forced appended on the end.
aspect=false - exact same results. I could not find a difference anywhere.

I tried with GPU scaling turned off and turned on (Catalyst Control Center.) I couldn't change any other settings (maintain aspect, stretch, etc..) in CCC because they were all greyed out, just enable/disable GPU scaling.

All this with the official .74 release, the SVN build, and with my personal build (which will be undergoing some more building now that I know about that diff file.)

Feeding Dragon

Reply 5 of 17, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
ripa wrote:
NewRisingSun wrote:

Not in text modes. Standard DosBox seems to enforce a 1:1 pixel aspect ratio in these for reasons unknown to me, whereas SVN Daum does not.

Yes, of course not. I always forget that the aspect ratio correction does not apply to text mode.

Ok, time for more testing... All my tests were done in text mode 🙁 Didn't know about that.

Feeding Dragon

Reply 6 of 17, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

Please totally disregard my second issue. Text mode was wonky, and resizing was broken for a while there (didn't know ddraw was broken,) led to some incorrect conclusions. Once I've gotten sdl lib set up again, this whole issue will be over. Thanks all, sorry to have been a bother.

Feeding Dragon

Reply 7 of 17, by ripa

User metadata
Rank Oldbie
Rank
Oldbie
FeedingDragon wrote:

Ooh, I didn't see that... Is this listed somewhere, some instructions I missed? If so, apologies to all concerned.

It's mentioned in INSTALL.

Reply 8 of 17, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
ripa wrote:
FeedingDragon wrote:

Ooh, I didn't see that... Is this listed somewhere, some instructions I missed? If so, apologies to all concerned.

It's mentioned in INSTALL.

Ah, there it is. Just out of curiosity, why the instruction files without file types? I see a .txt (or .doc, .me, .1st, .diz, etc....) file, I know to read it in case it's important. Does it have something to do with cross platforming??

BTW - compiles great now, everything seems to work too 😀 I'm not sure about zlib, don't know how to test that. libpng works just fine (making screen shots and such.) Don't do much (ok, not any,) networking with DOSBox, so have been considering yanking the sdl_net library (though I probably won't, just in case.) Have been considering the sdl_sound library next (though that's rather easy to test, build a mp3/ogg based cue/bin image - plenty of instructions on a simple search here on that.)

Right now, though, my main goal is to incorporate some of the fix patches (like the pcjr graphics patch.) Though all that comes after I get my system completely re-installed. New MB had to re-install Windows, and I forgot to back up some of my shortcuts, links, and config files (ok, more that just "some", try almost all.) That's going to take a while 🙁 It was rebuilding the config library that let me discover the ratio problem, then the ddraw problem (got those solved though, thanks again.)

Feeding Dragon

Reply 9 of 17, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

There seem to be standard naming schemes in source repositories, INSTALL, CHANGELOG, README, etc... Everyone accustomed to sources knows where to look 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 10 of 17, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

There seem to be standard naming schemes in source repositories, INSTALL, CHANGELOG, README, etc... Everyone accustomed to sources knows where to look 😉

Yeah, but I'm a complete amateur... I took one half of a single course in programming in college, the decided I didn't have the patience for it. Now that I can't work any more, and have plenty of free time and not enough to keep my mind off of other things, I'm picking it up again. I've never before had to work with others when writing something. It's always been a case of, need a utility to do this very simple task (over and over and over etc...) I sit down, hammer it out, then move on. That's the extent of my past programming experience 🙁

Feeding Dragon

Reply 11 of 17, by ripa

User metadata
Rank Oldbie
Rank
Oldbie
FeedingDragon wrote:

BTW - compiles great now, everything seems to work too 😀 I'm not sure about zlib, don't know how to test that.

Zlib is used by the video capture functionality, so you can test it by capturing some video.

Reply 12 of 17, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
ripa wrote:
FeedingDragon wrote:

BTW - compiles great now, everything seems to work too 😀 I'm not sure about zlib, don't know how to test that.

Zlib is used by the video capture functionality, so you can test it by capturing some video.

Ok, had Zlib wrong. Sorry it took me so long to respond, when it failed, I started over from scratch. Got it up and running now, screen captures work, video capture works (though it won't show video in VLC, it will in WMP, something I'm going to have to look into eventually - not a DOSBox issue, a VLC one.) I kept having a problem with zlib because the "source" insisted on only building a wapi (windows API,) version and I think that's what made it break my build. I finally forced a cdecl version build (by using the makefile instead of the visual studio's solution file.) I still think I could probably fix the solution file, but why bother? I also stopped depending on the zlib built by libpng when it builds. But to get that working I had to point it specifically at my zlib.lib build & headers and completely remove it from the solution. I fought for 2 hours with the SDL_sound source before saying, the heck with it, I'll come back to it later. I was rather shocked to see that SDL_Sound had desktop workspace files designed by Visual Studio 6?? I have VS6, but really??

So, DDraw working again.... check.
Screen caps working..... check.
Video captures working..... check.
All the little fixes working.. check. (Ok, more like personal tweaks than fixes 😀, though the PCjr & Tandy graphics fixes are actual fixes.)

Hmm, what's left??? I'll get on to that SDl_Sound issue next I guess. I may have to re-create the stupid workspace (solution that is,) from scratch.

Feeding Dragon

Reply 13 of 17, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Sdl-sound is annoying on Windows. You need all kinds of dependencies and it's hard to turn off this depending in Windows. Much easier on *nix 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 14 of 17, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

I mercifully got SDL_Sound compiling right away in mingw/MSYS after I edited its config.h to only compile the decoders I wanted --- wav, flac and ogg. (Other decoders throw funny error messages from math.h being included several times with the reinclusion check failing for some reason.) The biggest challenge for me was to get DosBox' configure script to recognize that libpng and SDL_Sound were present. I never succeeded at that, instead I had to edit "configure" itself by hand to force their use. I don't know where it expects the header files to be.

Note that SDL_Sound has a bug in that it does not report file durations accurately for WAV and FLAC formats with DosBox' seek method. Tracks other than the first audio tracks then don't play. That's why you should use the updated SDL_Sound source from Mercurial, as that one adds the Sound_GetDuration function, which can then be used in dos/cdrom_image.cpp' CDROM_Interface_Image::AudioFile::getLength() in lieu of the seek method to get proper durations.

Reply 15 of 17, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

When I'm ready to start hammering at code again, I'll look into Mercurial, never actually worked with the system before. Thanks for the tip. I'm afraid that I'd really only want to work with SDL_Sound with MP3 support, as I do all my work with MIDI and MP3 files (wonder if there's a MIDI patch hehehe.) That's another reason to hate my forced upgrade to Win7, they've totally destroyed my ability to work with MIDI like I'm used to. Having to really scramble to get my stuff up and running again 🙁 I still haven't fixed the volume issue (if I don't remember to physically turn things down, my ears start bleeding when a MIDI plays.)

Feeding Dragon

Reply 16 of 17, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

The biggest challenge for me was to get DosBox' configure script to recognize that libpng and SDL_Sound were present. I never succeeded at that, instead I had to edit "configure" itself by hand to force their use. I don't know where it expects the header files to be.

I just want to say the DOSBox configure scripts work without a hitch right out of SVN or any official source release on my MinGW/MSYS setup. I have also compiled SDL, SDL_net, SDL_sound and libpng from source and "make install" in the same MinGW/MSYS setup. You may want to look at your MinGW/MSYS setup again. When you build libraries for MinGW gcc from source, make sure you have "--prefix=/mingw". Otherwise, your libraries installation prefix will most likely default to /usr/local, which MinGW gcc will not be able to locate the header files and causes configure scripts to fail. If you ever install any libraries into /opt or /usr/local prefix, then you will need to specify the extra overrides during configure scripts invocation.

Reply 17 of 17, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

I had assumed that if source packages install into /usr/local, then their configure scripts would look into /usr/local as well, and I would only have to add this path to gcc's specs file so mingw's gcc would look there. Apparently not.