Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Janizdreg

Chocolate Doom

Recommended Posts

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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...

Share this post


Link to post

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)?

Share this post


Link to post
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.

Share this post


Link to post

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).

Share this post


Link to post
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...

Share this post


Link to post
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..

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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 200
Then 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)

Share this post


Link to post

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?

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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..

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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

Share this post


Link to post

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?

Share this post


Link to post

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).

Share this post


Link to post

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..

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
Guest
This topic is now closed to further replies.
×