Reckoner Posted February 7, 2008 Graf Zahl said:I doubt you will have any success with it. NVidia completely removed all support for low resolutions from their latest line of drivers. Considering the lack of support, I think it might be nice if Chocolate Doom had some sort of emulation (for example, 320x200 scaled up in 640x400 or 640x480) as the low resolution is one of the most important aspects when it comes to keeping the classic Doom feel. 0 Share this post Link to post
evildragon Posted February 7, 2008 Reckoner said:Considering the lack of support, I think it might be nice if Chocolate Doom had some sort of emulation (for example, 320x200 scaled up in 640x400 or 640x480) as the low resolution is one of the most important aspects when it comes to keeping the classic Doom feel. Chocolate-Doom does have 640x400, and PS, that's the far better choice than 640x480. 0 Share this post Link to post
Reckoner Posted February 7, 2008 evildragon said:Chocolate-Doom does have 640x400, and PS, that's the far better choice than 640x480. Yes, but I don't want 640x400. I want 320x200, and if modern drivers won't support it then Chocolate Doom should emulate it in 640x400 (that is, the actual resolution could be higher than 320x200, but there would only be 320x200 "game" pixels, each of which would take up about 4 real pixels). And, of course, 640x400 is better than 640x480 because it keeps the 8:5 aspect ratio, but not all video cards may support it. 0 Share this post Link to post
evildragon Posted February 7, 2008 Reckoner said:Yes, but I don't want 640x400. I want 320x200, and if modern drivers won't support it then Chocolate Doom should emulate it in 640x400 (that is, the actual resolution could be higher than 320x200, but there would only be 320x200 "game" pixels, each of which would take up about 4 real pixels). And, of course, 640x400 is better than 640x480 because it keeps the 8:5 aspect ratio, but not all video cards may support it. Your not understanding me. Chocolate doom will double scan 320x200 video in 640x400, so it will look EXACTLY the same. so it already handles your "emulate". Being old computers VGA (MCGA) 320x200 video was outputted as 640x400 from the DAC anyway, there's NO change. EDIT: Simply put, Chocolate Doom ALWAYS renders in 320x200... 0 Share this post Link to post
myk Posted February 7, 2008 Yeah, I hadn't noted that it doesn't really have true 640x400 (like Doom95 does) till earlier today when I tried it and it looked just like 320x200 in full screen mode. Reckoner said: I want 320x200, and if modern drivers won't support it then Chocolate Doom should emulate it in 640x400 (that is, the actual resolution could be higher than 320x200, but there would only be 320x200 "game" pixels, each of which would take up about 4 real pixels). You can do that in ZDoom by setting both vertical and horizontal low detail at 640x400. But is the problem with some drivers and 320x200 due to a minimum resolution limit, or is it related to the ratio (8/5)? 0 Share this post Link to post
evildragon Posted February 7, 2008 myk said:That should be easy. You can do it in ZDoom by setting both vertical and horizontal low detail at 640x400. But is the problem with some drivers and 320x200 due to a minimum resolution limit, or is it related to the ratio (8/5)? Probably more like never put the strings in the INF file. I hack my Nvidia drivers with custom resolutions right from the INF file. (or atleast used to some time ago). Thing is, the video card supports it, because DOS runs the DAC in the same 400 line mode as 320x200. So, it "can" do it. 0 Share this post Link to post
evildragon Posted February 7, 2008 Here's how it works. Set the video mode like that. Then, the output is this double scanned 640x400 image. NO DIFFERENT than real 320x200 visually because the CRT gets the same sync either way. EDIT: Note that most Macintoshes only go as low as 480 lines, so 320x200 and 640x400 run in plain old 640x480 with letterboxing. (no matter what the aspect setting is). 0 Share this post Link to post
Reckoner Posted February 7, 2008 evildragon said:Your not understanding me. Chocolate doom will double scan 320x200 video in 640x400, so it will look EXACTLY the same. so it already handles your "emulate". Being old computers VGA (MCGA) 320x200 video was outputted as 640x400 from the DAC anyway, there's NO change. EDIT: Simply put, Chocolate Doom ALWAYS renders in 320x200... Indeed, I was misunderstanding you, so thank you for clearing that up. I should have investigated that before speaking; I had no idea that Chocolate Doom did that. Knowing this, I love Chocolate Doom even more than I did yesterday... 0 Share this post Link to post
evildragon Posted February 7, 2008 Reckoner said:Indeed, I was misunderstanding you, so thank you for clearing that up. I should have investigated that before speaking; I had no idea that Chocolate Doom did that. Knowing this, I love Chocolate Doom even more than I did yesterday... Glad it got cleared up. Sorry if I seemed rude, having a rough day. I've been lovin chocolate doom since I got help in this very thread on the last page to get it compiled. Though without music for me.. 0 Share this post Link to post
aleksej Posted February 7, 2008 For builds 1046 and newer 320x200 mode just not available in choco setup and won't work if that mode set manually in cfg file. Fullscreen: Windowed: MikeRS, thanks for advice. Fixed. 0 Share this post Link to post
aleksej Posted February 7, 2008 evildragon said:..Though without music for me.. What do you mean? Choco won't playing midi music on your setup? If you mean that - i know that problem. 0 Share this post Link to post
chungy Posted February 7, 2008 Chocolate Setup automatically detects what your video card supports now. Your exact choices are unlikely to be seen by other people, unless they have the same video card. BTW, try to use PNG for screenshots of Chocolate Setup. It will actually be smaller than JPEG for tons of repeated pixels, and it'll look better too. 0 Share this post Link to post
entryway Posted February 7, 2008 Support for 320x200 was removed in ForceWare 169.x. Even 163.x can handle 320x200. AFAIK c.imp has VooDoo5, thus the problem is in Chocolate Doom or in c.imp's settings 0 Share this post Link to post
aleksej Posted February 7, 2008 And again.... only new choco builds lacks 320x200 (1046 and newer), that mean all old builds including 1.0 release and early alfa versions like 0.2, 0.4 and etc run in 320x200 fullscreen very well. And yes, i use voodoo card, but voodoo3 now. And changed it a big time ago. Before 1.0 release. Both cards run that mode very well. I also tested it on matrox, ati, s3, nvidia. Those cards OFCOURSE has all range of videomodes and OFCOURSE this is not videodrivers issue. This is choco internal problem. p.s. Hmmm... Seems like this is new chocolate-setup problem. It has for 1kb bigger size. Available videomodes detection metod has changed, right? I edit chocolate-doom.cfg and set autoadjust_video_settings to 0 as Fraggle said and it work. Anyway it is choco problem, not my videocard and videodrivers. 0 Share this post Link to post
myk Posted February 7, 2008 c.imp said: I edit chocolate-doom.cfg and set autoadjust_video_settings to 0 as Fraggle said and it work. Anyway it is choco problem, not my videocard and videodrivers. It's the video card's drivers. Chocolate Doom is asking them what modes are available and they say "you can use 640x480 or higher". The drivers of my card do it and I use autoadjust_video_settings 0 as well. The setting tells Chocolate Doom not to ask and just set whatever it wants. 0 Share this post Link to post
fraggle Posted February 7, 2008 c.imp said:And again.... only new choco builds lacks 320x200 (1046 and newer), that mean all old builds including 1.0 release and early alfa versions like 0.2, 0.4 and etc run in 320x200 fullscreen very well. And yes, i use voodoo card, but voodoo3 now. And changed it a big time ago. Before 1.0 release. Both cards run that mode very well. I also tested it on matrox, ati, s3, nvidia. Those cards OFCOURSE has all range of videomodes and OFCOURSE this is not videodrivers issue. This is choco internal problem. p.s. Hmmm... Seems like this is new chocolate-setup problem. It has for 1kb bigger size. Available videomodes detection metod has changed, right? I edit chocolate-doom.cfg and set autoadjust_video_settings to 0 as Fraggle said and it work. Anyway it is choco problem, not my videocard and videodrivers. Set autoadjust_video_settings back to 1 and from the command line, run: chocolate-doom -width 320 -height 200Then look in the stdout.txt file: is there anything mentioned about autoadjusting? Can you run this program and paste the output? (Needs to be put in the same directory as Chocolate Doom) 0 Share this post Link to post
aleksej Posted February 7, 2008 Damn! I forgot to say - i'm using Windows 98. Sorry! That important ofcourse. Under WinXP all ok with new build. Thanks Fraggle, but entryway already did similar thing for me with special hack of their prboom+M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - R_LoadTrigTables: Endianness...ok. R_InitData: Textures Flats Sprites R_Init: R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables R_InitPatches P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device with 1024 samples/slice I_InitSound: sound module ready S_Init: Setting up sound. S_Init: default sfx volume 7 HU_Init: Setting up heads up display. I_InitGraphics: 640x480 I_UpdateVideoMode: 640x480 (fullscreen) V_InitMode: using 8 bit video mode I_SetRes: Using resolution 640x480 SDL_SetVideoMode.flags: 0x80000000 2048 x 1536 1920 x 1440 1920 x 1200 1920 x 1080 1856 x 1392 1792 x 1344 1600 x 1200 1600 x 1024 1280 x 1024 1280 x 960 1152 x 864 1024 x 768 960 x 720 800 x 600 720 x 576 720 x 480 640 x 480 640 x 400 512 x 384 400 x 300 320 x 240 320 x 200 This list is the same when i run prboom+ from desktop or FAR's fullscreen textmode. Now yours program stdout.txt output: 1920 x 1440 1920 x 1200 1920 x 1080 1856 x 1392 1792 x 1344 1600 x 1200 1600 x 1024 1280 x 1024 1280 x 960 1152 x 864 1024 x 768 960 x 720 800 x 600 640 x 480 And under FAR's full screen textmode it just won't works and stdout.txt is empty. Then i use "SET SDL_VIDEODRIVER=directx" invironment variable. And now: 2048 x 1536 1920 x 1440 1920 x 1200 1920 x 1080 1856 x 1392 1792 x 1344 1600 x 1200 1600 x 1024 1280 x 1024 1280 x 960 1152 x 864 1024 x 768 960 x 720 800 x 600 720 x 576 720 x 480 640 x 480 640 x 400 512 x 384 400 x 300 320 x 240 320 x 200 And the same list in FAR's fullscreen mode too. entryway told me that it make that variable build in prboom+ code with simple OS kernel detection. If 9x kernel presents "SET SDL_VIDEODRIVER=directx" sets automatically. But your one weeks old builds works without this! Only new build has broken detection of available videomodes under 9x and requires "SET SDL_VIDEODRIVER=directx" variable as prboom+ did some time ago. ps. Hmmm... maybe old choco builds just forcing "SDL_VIDEODRIVER=directx" like prboom+ did now, and in new version you disable this? 0 Share this post Link to post
aleksej Posted February 7, 2008 chocolate-setup from 1057 build under win98 started from desktop and without "SET SDL_VIDEODRIVER=directx" variable. chocolate-setup from 1057 build under win98 started from fullscreen FAR and without "SET SDL_VIDEODRIVER=directx" variable. This is cyrillic win98, just generic windows error, contact with author and etc :) chocolate-setup from 1057 build under win98 started from fullscreen FAR and after "SET SDL_VIDEODRIVER=directx" variable set 0 Share this post Link to post
myk Posted February 7, 2008 Those two settings (no autodetect and the directx environment) are also required for my system, which is likewise using Windows 98. In fact the settings exist in part because of bug reports I (and others) made. That is, they're there for cases like yours and mine. Older versions didn't need that, but those checks or changes that confuse our systems were implemented to make other systems work fine. 0 Share this post Link to post
entryway Posted February 7, 2008 exp(x) said:What is "fullscreen FAR"? http://farmanager.com/?l=en 0 Share this post Link to post
evildragon Posted February 7, 2008 What happens if you turn off "Correct Aspect Ratio"? Btw, Macs don't have the same MIDI engine as PC's, so Doom on a Mac lacks MIDI. Though DoomsDay does have music.. 0 Share this post Link to post
aleksej Posted February 7, 2008 With Correct Aspect Ratio turned off nothing changes. About music in Doom i was thinkin you mean that choco lacks midi. This is another problem with Win9x and SDL. It have strange behavior of midi routine on certain hdd partitions configuration and Win9x. If hdd partitioned in some "exotic" configuation then SDL can route midi when running from one disk and can be muted when routing from another. 0 Share this post Link to post
evildragon Posted February 7, 2008 I really don't know how an HD partition can mess up MIDI, but I don't know SDL very well. My problem is completely different than yours. I don't use Windows at all. 0 Share this post Link to post
entryway Posted February 7, 2008 evildragon said:I really don't know how an HD partition can mess up MIDI, but I don't know SDL very well It looks weird, but it's true. I do not remember clearly, but behavior depends from some weird things like where is primary partition and where is application or something... Also you can remember story about SDL and its lags with mouse on all platforms, which were solved by means of showing transparent cursor instead of hiding 0 Share this post Link to post
aleksej Posted February 7, 2008 I'm very surprised too but anyway it is problem. I'm using separate OS boot with boot manager Boot-US. It very smart and useful. It can masking not using at moment partitions by marking it as non-formatted. Even XP and *nix can't see another partitions. Real my partition configuration is: 1. primary 2gb FAT16 (DOS 6.22) 2. primary 20gb FAT32 (Win98) 3. logical 40gb FAT32 (shared to Win98 and WinXP) 4. primary 20gb NTFS (WinXP) All primary partitions hidden except current OS partition. In this case Win98 lives on non physically first partition. And now, if i running any SDL game (choco or prboom+) from my primary disk C: then midi is disabled. If i copying game folder to disk D: (logical) then all ok and midi plays in both games. Even if i'm left game on disk C: but run it sitting on disk D: from command-line prompt like: D: c:\games\choco\chocolate-doom.exe -iwad c:\games\choco\doom.wad -config "..." -extraconfig "..." then midi playback! But if i return to disk C: and run game inside it folder - no music! I don't know that is problem with SDL midi routine and partitions config or not but i don't see another reasons. I probing all variants. Only "normal" partition configuration fixes this. Very strange problem, huh? 0 Share this post Link to post
myk Posted February 7, 2008 evildragon said: Btw, Macs don't have the same MIDI engine as PC's, so Doom on a Mac lacks MIDI. Though DoomsDay does have music.. Doesn't SDL's TiMidity capability work? It's what many Linux users use for MIDI music. All you normally need is a set of patches, such as this. I use it in Windows for various ports and engines because I prefer it over the native MIDI sound (besides, it uses GUS patches, that Doom supports through a GUS card). 0 Share this post Link to post
evildragon Posted February 7, 2008 Don't know, you'd have to ask the developer of Chocolate Doom. All the Doom engines I used that had music on my Mac, used QuickTime for it's MIDI use.. 0 Share this post Link to post
myk Posted February 7, 2008 evildragon said: Don't know, you'd have to ask the developer of Chocolate Doom. I'm sure fraggle can clarify this, but I don't see why it wouldn't work, as it's independent of true MIDI, and based on what's in SDL_mixer. The page says nothing about it lacking TiMidity support in Macs. 0 Share this post Link to post
chungy Posted February 7, 2008 I believe it was an SDL_mixer bug on Mac OS X... it's like how SDL_mixer would crash on *BSD too, until a few months ago when it was fixed. 0 Share this post Link to post