Chocolate Doom

[myk]

ultdoomer said:
Does the water look wrong to anyone else with this latest version?

I can't see anything wrong with the water.

I did notice something strange, though; Chocolate Doom always flips my Player to the right about 90° when it loads me into the level, but only if the engine just started. If I reach another level, warp using idclev or load a saved game, it's normal. All I hit before entering the game is the up arrow (to reload what was on the command line with doskey) and enter, and neither are used by by the game in my setup, so I'm not doing anything and it is flipping the Player all by itself.

[ultdoomer]

That sounds like the bug PrBoom(-plus) has (apparently it was fixed, but it still happens to me). I read it's caused by the pointer getting snapped to the center of the screen and that "movement" getting executed.

And I think the water issue has something to do with the DLLs. I can't test it though, since the latest version of Chocolate Doom won't start without the included DLLs. I didn't have this problem in 0.1.4. Also, I only see this in fullscreen mode.

[fraggle]

myk said:

I can't see anything wrong with the water.

I did notice something strange, though; Chocolate Doom always flips my Player to the right about 90° when it loads me into the level, but only if the engine just started. If I reach another level, warp using idclev or load a saved game, it's normal. All I hit before entering the game is the up arrow (to reload what was on the command line with doskey) and enter, and neither are used by by the game in my setup, so I'm not doing anything and it is flipping the Player all by itself.

Does this happen when you start a new game from the menu, or when you start a game from the command line with -warp ?

Does the water look wrong to anyone else with this latest version? I can't provide a screenshot (because the print key and every image-capturing program just give me a black box with Chocolate Doom), but it is easily noticeable if it is different.

This is rather worrying. Run with -devparm and press F1 to take a screenshot (this is how Vanilla does it).

Also, the startup_delay doesn't seem to work.

Are you sure? What value are you using for startup_delay? Bear in mind it is in milliseconds, so for 1 second you should use startup_delay 1000.

[myk]

ultdoomer said:
That sounds like the bug PrBoom(-plus) has (apparently it was fixed, but it still happens to me). I read it's caused by the pointer getting snapped to the center of the screen and that "movement" getting executed.

Maybe, but then why is the movement always exactly the same no matter where the mouse cursor was on the Windows screen?

fraggle said:
Does this happen when you start a new game from the menu, or when you start a game from the command line with -warp ?

With the command line's warp (or loadgame). If I use the menu or the warp cheat (or if I enter a new level by exiting a previous one), it is fine.

[andrewj]

myk said:

Maybe, but then why is the movement always exactly the same no matter where the mouse cursor was on the Windows screen?

Maybe the mouse cursor is moved to (0,0) first, either by SDL or by the Windows own video mode-setting code.

[entryway]

Ajapted said:

Maybe the mouse cursor is moved to (0,0) first, either by SDL or by the Windows own video mode-setting code.

yes, it's true

SDL_WarpMouse(SCREENWIDTH/2, SCREENHEIGHT/2);

[exp(x)]

I guess I've never tried started chocolate doom with the warp command, but I just did now and the same thing happened to me.

[Quasar]

This water crap sounds like the palette issue in SDL 1.2.11, which is caused by yet another retarded design decision in Camp SDL. This decision was to change the default video driver for Windows to GDI even if DirectX is installed. The only way to change this, believe it or not, is to set an ENVIRONMENT VARIABLE. What is this, the stone age? Apparently the GDI driver is buggy and is screwing up the palette. Somebody needs to let the SDL guys know how much their stupid change is screwing up everybody's programs. Not that they'll probably care though. They seem to do pretty much whatever suits them. Personally, I refuse to manipulate the system by adding environment variables. Give me an API function or forget it.

[myk]

Quasar said:
This decision was to change the default video driver for Windows to GDI even if DirectX is installed.

That might explain it, as my command prompt is initiated with the directx environment variable (I need it for PrBoom's resolution to work right).

[entryway]

Is it really problem to put one line in the source?

#ifdef _WIN32
  putenv("SDL_VIDEODRIVER=directx");
#endif

P.S. putenv() is a SDL function

[myk]

entryway said:
Is it really problem to put one line in the source?

I'd guess that depends on under what circumstances the environment is used. If always, then, yeah, in the code it's better, under accountable circumstances it's also good, but if the bug depends on different video cards and there's no clear way for the engine to tell them apart, then it might be better to just note the known issue and the solution in the engine documentation, or to add a CFG setting and (possibly) an ingame menu option.

[fraggle]

Quasar said:

Give me an API function or forget it.

void SDL_SetVideoDriver(char *name)
{
    setenv("SDL_VIDEODRIVER", name);
}

There you go! :-P

Seriously though, I'll see about setting this in the source code so that DirectX is used.

EDIT:
this should fix the turning problem.

this should fix the directx problem.

I cant test these at the moment because I don't have a functioning Windows install.

[exp(x)]

The turning problem is fixed. I was getting it on linux, btw.

[Quasar]

I don't care if it's "simple", it's still stupid, especially considering that it may NOT work for everyone, and it's also system-specific. Fortunately I think most of that crap is going to disappear with SDL 1.3 -- of course SDL 1.3 will probably be unusable for a while til they get the inevitable bugs and other issues worked out.

[entryway]

Quasar said:

I don't care if it's "simple", it's still stupid

IMO the current environment variables system is the only correct workaround system in this case, because users can change behavior without you and they do it :)

and it's also system-specific

We already have many of #ifdef _WIN32, etc. PrBoom at least. One more, one less... who cares? But of course, this difference in behavior must be solved in SDL. If it is possible.

SDL 1.3

SDL 1.3 will have refresh rate API for Windows. I am afraid that 50% of glboom users play in doom on 60 Hz under XP :(

[andrewj]

fraggle said:

this should fix the directx problem.

Perhaps add a "-gdi" option to get the non-directx behaviour, for example:

#ifdef WIN32
    if (SDL_getenv("SDL_VIDEODRIVER") == NULL && ! M_CheckParm("-gdi"))
    {
        SDL_putenv("SDL_VIDEODRIVER=directx");
    }
#endif

[entryway]

prboom-plus has the following universal code

    {"sdl_videodriver", {NULL,&sdl_videodriver}, {0,"default"},UL,UL, def_str,ss_none},

  // e6y: Forcing "directx" video driver for Win9x.
  // The "windib" video driver is the default for SDL > 1.2.9, 
  // to prevent problems with certain laptops, 64-bit Windows, and Windows Vista.  
  // The DirectX driver is still available, and can be selected by setting 
  // the environment variable SDL_VIDEODRIVER to "directx".
  {
    int p;
    char *video_driver;
    if ((p = M_CheckParm("-videodriver")) && (p < myargc - 1))
      video_driver = strdup(myargv[p + 1]);
    else
      video_driver = strdup(sdl_videodriver);

    if (strcasecmp(video_driver, "default"))
    {
      // videodriver != default
      char buf[80];
      strcpy(buf, "SDL_VIDEODRIVER=");
      strncat(buf, video_driver, sizeof(buf) - sizeof(buf[0]) - strlen(buf));
      putenv(buf);
    }
    else
    {
      // videodriver == default
#ifdef _WIN32
      if ((int)GetVersion() < 0 && V_GetMode() != VID_MODEGL ) // win9x
        putenv("SDL_VIDEODRIVER=directx");
#endif
    }
    free(video_driver);
  }

[andrewj]

entryway said:

prboom-plus has the following universal code

Yeah, the -videodriver option is a good idea, but I think you should use SDL_putenv() instead of plain putenv().

[Quasar]

Well since you guys wrote the code for me I'll consider it ;)

[ultdoomer]

fraggle said:

This is rather worrying. Run with -devparm and press F1 to take a screenshot (this is how Vanilla does it).

The screenshots work with that method, but unfortunately it doesn't capture the problem. I'm still having the water problem when playing, though.

fraggle said:

Are you sure? What value are you using for startup_delay? Bear in mind it is in milliseconds, so for 1 second you should use startup_delay 1000.

My mistake, I did assume it was seconds.

And is there any temporary solution to the water problem until it gets fixed in the code?

Lastly, how does "autoadjust_video_settings" affect your settings?

[fraggle]

ultdoomer said:

The screenshots work with that method, but unfortunately it doesn't capture the problem. I'm still having the water problem when playing, though.

And is there any temporary solution to the water problem until it gets fixed in the code?

Can you run Chocolate Doom from a command prompt? Type the following command before running it:

SET SDL_VIDEODRIVER=directx

Let me know if that helps or fixes it.

Lastly, how does "autoadjust_video_settings" affect your settings?

Chocolate Doom checks what available video modes your graphics card supports. If you specify a video mode that isn't supported, it tries to change your video settings to get a mode that your graphics card does support. For example, some cards don't support 320x200 any more. In that case, Chocolate Doom might set screenmultiply to 2 and fullscreen to 2, to give 640x480.

Sometimes it's desirable to be able to force a video mode that isn't in the list of modes that the card supports. If you set autoadjust_video_settings to 0, the autoadjust code is disabled and it will always use exactly whatever settings you've selected without question.

[ultdoomer]

fraggle said:

Can you run Chocolate Doom from a command prompt? Type the following command before running it:

SET SDL_VIDEODRIVER=directx

Let me know if that helps or fixes it.

It's still the same, unless I didn't enter it correctly.

I typed chocolate-doom SET SDL_VIDEODRIVER=directx in the Run command-line.

[andrewj]

ultdoomer said:

I typed chocolate-doom SET SDL_VIDEODRIVER=directx in the Run command-line.

That's not how to do it.

The command prompt is a window with a black background and white text which you can enter DOS commands on. You get it in XP by entering "cmd.exe" into the Run dialog.

Once you have that, you need to "cd" to the folder containing chocolate-doom. So it needs three commands:

CD C:\xxx\CHOCOLATE-DOOM
SET SDL_VIDEODRIVER=directx
chocolate-doom

Where "xxx" is the correct folder.

[ultdoomer]

That worked. Thanks.

[ultdoomer]

I have a desync to report: Level 26 in 30nm2956.lmp, the C-N NM record. PrBoom-plus plays it back correctly, and it's a C-N demo, so I assume there's something wrong with Chocolate Doom.

[Grazza]

Confirmed (using r736, dated 24-Oct-06). No idea what the cause may be - there are no relevant compatibility issues on that map that I am aware of. (It has been several maps since the last dodgy stairbuilding, and the "solid hanging body in tall sector" in this map presumably shouldn't be handled in an incompatible way - should it?)

The start of map26 is also the place where d2dq2116.lmp desyncs (with Ultimate compat), but I have no reason to think that is anything more than a coincidence - and that one desyncs in both prboom-plus and chocolate-doom (not surprising since it was recorded with a customized exe).

Edit: the demo played back OK with Chocolate-Doom version 0.1.4, so whatever the problem is, it was introduced between that and r736.

[entryway]

Grazza said:

Edit: the demo played back OK with Chocolate-Doom version 0.1.4

heh, I have only 1.2 adapted to VisualC for my compatibility tests. fraggle, please, make it compatible with most popular programming environment. it have many errors and some hundreds of warnings last time when I checked

[fraggle]

entryway said:

heh, I have only 1.2 adapted to VisualC for my compatibility tests. fraggle, please, make it compatible with most popular programming environment. it have many errors and some hundreds of warnings last time when I checked

I don't have a functioning Windows install; all my development and testing is done under Linux. Under Windows I only use MingW and have no interest in supporting MSVC. If others want to fix up any problems so that it will compile under MSVC, patches are welcome!

[Scet]

What version of VC do you have entryway? VC2003 and 2005 should in theory be compatible with anything for GCC, well a lot more compatible then the nightmare known as VC6. If you're still using VC6, please upgrade to a compiler from this millennium.

[entryway]

i have both vc6 and vc2005, but it has no practical importance. long long does not transform into __int64 because of it. etc. 507 warnings like signed/unsigned mismatch, conversion from 'const double ' to 'int ', possible loss of data and differs in parameter lists will not disappear too - these are mistakes of choco-doom only.