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

Chocolate Doom

Recommended Posts

RazTK said:
Edit: Okay, it does. :-\

Yeah, it had the error for me too.

Share this post


Link to post

fraggle, I managed to record a demo that causes the crash, you can get it here (DOOM2 MAP08). You will have to type IDFA at the start so it won't desync.
Please watch and test.

Share this post


Link to post
RazTK said:

fraggle, I managed to record a demo that causes the crash, you can get it here (DOOM2 MAP08). You will have to type IDFA at the start so it won't desync.
Please watch and test.

I'm pretty sure I've identified the cause of the bug. It only occurred if you used the Codeblocks build system, and I've talked with Russell who has fixed it.

By the way, I thought I should announce the latest Chocolate Doom feature: aspect ratio correction: you can now run at 640x480 and have it take up the whole screen, so no more letterboxing. Hopefully this will make some people happy.

Here is a screenshot for anyone who is curious :-)

Internally, everything is still 320x200, it's just scaled up to fill the whole screen. I'm actually fairly impressed with how well this has turned out. You can't perfectly scale up to 640x480 because it's not a multiple of 320x200. If you run at 320x240 it's very noticably blurry, but at 640x480 it's almost unnoticable. I'm also impressed with the speed I've managed to get - the code does blending as it scales up, but it's still playable at 640x480 even on my crappy old laptop. I'm seriously considering making this the default for people who can't run at 320x200 - instead of letterboxing the screen, which is what I currently do.

In fact, the perfect resolution to run in is 1600x1200, as 1600 is a multiple of 320 and 1200 a multiple of 200, but Chocolate Doom doesn't support that yet :-)

Share this post


Link to post
fraggle said:

I'm pretty sure I've identified the cause of the bug. It only occurred if you used the Codeblocks build system, and I've talked with Russell who has fixed it.

Thanks fraggle! And big thanks to Russell too, awesome job guys!

The latest Windows revision builds can always be found here (and notice the new sexy icon to the setup utility :-).

Share this post


Link to post

I think autodetection is broken. 30ev5534.lmp desyncs without the -gameversion final parameter, but it plays back fine with it. I'm using the latest SVN build.

Share this post


Link to post

ultdoomer said:
I think autodetection is broken. 30ev5534.lmp desyncs without the -gameversion final parameter, but it plays back fine with it. I'm using the latest SVN build.

Are you sure you aren't using -file instead of -iwad for tnt.wad?

Share this post


Link to post

I've found the reason of SDL mouse lag. Sounds as nonsense, but it depends from SDL_ShowCursor(0). Do not hide cursor!, but replace it with an empty from one transparent pixel and the problem will go away

Uint8 data[1] = {0};
cursors[0] = SDL_GetCursor();
cursors[1] = SDL_CreateCursor(data, data, 1, 1, 0, 0);
SDL_SetCursor(cursors[1]);
This code will work fine and without lags on fullscreen. Very strange.

Share this post


Link to post

Hide the mouse cursor using SDL_SetCursor to a blank cursor, not SDL_ShowCursor. This fixes mouse lag on Windows. Thanks to entryway.

I hope this patch should fix the problem on all platforms, because it happens on Windows, MAC and POSIX (I checked it)

Share this post


Link to post

Yeah. It would be interesting to have a look through the SDL source and see exactly what it's doing.

My one concern is that this probably affects mouse acceleration: if we're running with an "invisible mouse cursor", it probably means that the values we're getting are affected by the host OS's mouse acceleration settings.

Share this post


Link to post
fraggle said:

My one concern is that this probably affects mouse acceleration

OS's mouse settings always had effect. In XP at least.

Share this post


Link to post

I have sort of a request for this great port: the use of numpad keys to select weapons, like with the normal numbers on the keyboard. This would come in hand for left-handed people who play with arrows, or just people who play with arrows regardless, like me. Just a though I had, since I have to reach clear across the keyboard to change guns. Either that, or you could look into adding a next/previous weapon, but then again, that would probably go agaist what this port is all about: true Vanilla compatability.

Share this post


Link to post

Bashe said:
but then again, that would probably go agaist what this port is all about : true Vanilla compatability.

Both would, but you can use PrBoom with complevel 2 (or 3) for that, which allows you to bind the weapon keys.

Heh, you just made me find an incompatibility in Chocolate Doom. It's minor and could be viewed as inconsequential, but it's curious and who knows, could have some sort of effect in some way: hitting the 5 in the numpad will toggle the Rocket launcher in Doom. Only that one works and not any of the others. On the other hand, in Chocolate Doom that key doesn't do anything.

Share this post


Link to post

Oh well, it was just an idea I had to make things more conveniet, but this isn't about what Bashe wants, it's what Vanilla Doom wants! Yeah! >:D

Share this post


Link to post

I've had a pretty nasty problem since revision 755 (currently I'm using r823): whenever there are pain or pickup screen flash effects on screen, there is also a massive slowdown. The degree of the slowdown depends on the screenmultiply setting - the bigger screenmultiply, the worse the slowdown is. If screenmultiply is set to 1, there is no slowdown at all. Here's a short video of how the slowdown looks like.

I've also got a little question. How am I supposed to run the Obituary TC with Chocolate Doom? I tried using the following command line parameters: "-file OBTIC1.WAD -nwtmerge OBTIC2.WAD OBTIC3.WAD -deh OBTIC2.DEH", but it didn't work.

Share this post


Link to post

Janizdreg said:
I've also got a little question. How am I supposed to run the Obituary TC with Chocolate Doom? I tried using the following command line parameters: "-file OBTIC1.WAD -nwtmerge OBTIC2.WAD OBTIC3.WAD -deh OBTIC2.DEH", but it didn't work.

What is -nwtmerge? I don't see it mentioned in the Chocolate Doom wiki. Although some NWTlike merging commands are explained in the wad merging section.

This thread might also help.

Share this post


Link to post
myk said:

This thread might also help.

Thanks, it helped alright. I ran NWT with the commands Grazza suggested in the thread, and then I simply ran Chocolate Doom with "-file OBTIC1.WAD OBTIC2.WAD -deh OBTIC2.DEH" and it worked like a charm.

What is -nwtmerge?

It's a new parameter introduced just recently, and it hasn't yet been documented properly anywhere. A quote from Chocolate Doom's NEWS file: "New '-nwtmerge' command line option that emulates NWT's '-merge' option. This allows TiC's Obituary TC to be played". So, I assume it's supposed to allow Chocolate Doom to run Obituary without having to use NWT to touch up the wads first.

Share this post


Link to post

Perhaps you still need to use nwt to join obtic2.wad and obtic3.wad together, and can then use -nwtmerge. Thus:

nwt -join obtic2.wad obtic3.wad
chocolate-doom -file obtic1.wad -nwtmerge obtic2.wad -deh obtic2.deh
Just guessing (haven't tested), but that would seem to make sense.

BTW, the choc wiki page is somewhat misleading - with neither deusf nor nwt is it necessary to modify the iwad to play these wads with vanilla. With both it is possible to add the necessary stuff to the pwad and then load the resulting (enlarged) pwad with -file (also works with Chocolate as an alternative to -merge/-nwtmerge - this is what the instructions I gave in the other thread basically do).

Edit: judging from what fraggle put below, I suppose the command lines to play with the modified weapons (via -nwtmerge) ought to be:
nwt -join obtic2.wad obtic3.wad
chocolate-doom -deh obtic2.deh -nwtmerge obtic2.wad -file obtic1.wad obtic2.wad

Share this post


Link to post
Janizdreg said:

I've had a pretty nasty problem since revision 755 (currently I'm using r823): whenever there are pain or pickup screen flash effects on screen, there is also a massive slowdown. The degree of the slowdown depends on the screenmultiply setting - the bigger screenmultiply, the worse the slowdown is. If screenmultiply is set to 1, there is no slowdown at all. Here's a short video of how the slowdown looks like.


Chocolate Doom uses SDL's DirectX output by default, but using the -gdi command line parameter will use the plain GDI version instead. According to my IRC backlog, you've already done this and it fixes your problem :-) If you want to make it permanent, you can set a variable named SDL_VIDEODRIVER in your environment settings (in System properties) with the value "gdi".

I'm a bit confused because DirectX really shouldn't be slower than plain GDI output. I can add a configuration option to specify which video driver to use but I'm interested to know why this is happening in the first place.

I've also got a little question. How am I supposed to run the Obituary TC with Chocolate Doom? I tried using the following command line parameters: "-file OBTIC1.WAD -nwtmerge OBTIC2.WAD OBTIC3.WAD -deh OBTIC2.DEH", but it didn't work.


Ok, I guess I forgot to put up instructions. Sorry :-)

NWT's -merge option is strange in that it doesn't actually merge anything. All it does is modify the IWAD to blank out the entries that are being replaced. You then need to add the WAD back again when you run Doom, using -file. Because I've tried to reproduce its behavior as closely as possible, the -nwtmerge option is a bit verbose in its use.

To run Obituary in "normal" mode (no extra weapons; this is equivalent to running OBNORM.BAT):

chocolate-doom -deh OBTIC1.DEH -nwtmerge OBTIC2.WAD -file OBTIC1.WAD OBTIC2.WAD
I'm pretty certain I got the extra-weapons version to work as well (OBWEAP.BAT) but it's trickier because of an extra PWAD join in the batch file.

EDIT: You can run with extra weapons like this:
chocolate-doom -deh OBTIC2.DEH -file OBTIC1.WAD -aa OBTIC2.WAD OBTIC3.WAD
(Does this mean that you can just use -aa and ignore -nwtmerge? Probably.)

Share this post


Link to post

Are you using SDL_HWSURFACE to get double buffering? Because SDL hardware surfaces are *crap* -- they are slower than software surfaces for virtually all purposes. When using them in Halif Engine, I experienced a loss of almost 2000 FPS, especially for anything that must read from the video surface (DOOM doesn't do this much fortunately).

When SoM added your -gdi / putenv() code to EE, I lost 15 FPS in 960x600 mode. I also started to experience an input problem. That is, at random, the game would suddenly pause and the Win32 system menu that comes from the top left corner of the window would suddenly appear without explanation. I've had to disable the code for now.

Share this post


Link to post

Ok, it seems you really can't avoid messing with the NWT first if you want to get Obituary & its new weapons working with Chocolate Doom like they are supposed to. Loading obtic2.wad & obtic3.wad using the -aa parameter isn't a very good option since it doesn't load the new sounds at all. Therefore, the best way to proceed is, as Grazza suggested:

nwt -join obtic2.wad obtic3.wad
chocolate-doom -deh obtic2.deh -nwtmerge obtic2.wad -file obtic1.wad obtic2.wad

fraggle said:

I can add a configuration option to specify which video driver to use

Now there's a feature I'm looking forward to! Unless, of course, I can get rid of the slowdowns some other way than by switching to GDI. Though even then the option could be a useful one, as other people might have similiar problems at some point. Maybe the video driver setting could even be made as a chocolate-setup option?

Quasar said:

Are you using SDL_HWSURFACE to get double buffering?

No, I haven't tweaked any SDL specific settings, only ones that are found in the Chocolate Doom config files.

Share this post


Link to post

Actually that question was for fraggle. SDL_HWSURFACE isn't a setting the user can specify; it is a flag that is passed into SDL_InitVideoMode in the program.

Share this post


Link to post

I have a question for anyone who has an unusual keyboard layout (ie. non-QWERTY). For example, German keyboards have a QWERTZ layout.

Vanilla Doom doesn't seem to do keyboard layout conversion, so if you have a German keyboard, pressing 'z' will actually type a 'y'. This means that on the menu prompts (press y to continue, press y to quit, etc.), you actually have to press a different key to the one you're being prompted for. I decided to fix this in Chocolate Doom, so that when you're prompted to "press y", you really do have to press 'y' - whatever that key may be on your keyboard.

After this, it occurred to me that if Vanilla has the same bug, German Doomers (and others) have probably been living with this bug for years and have it ingrained into their skulls which key to press. So my question is: what should be the expected behaviour? The sensible thing to do would be to expect a real 'y' when we prompt for 'y', but have users of non-QWERTY layouts grown to expect the non-standard layout?

The same also applies to cheat codes: someone with a German keyboard would have to type IDMZPOS instead of IDMYPOS, for example.

Share this post


Link to post
fraggle said:

I have a question for anyone who has an unusual keyboard layout (ie. non-QWERTY). For example, German keyboards have a QWERTZ layout.

Vanilla Doom doesn't seem to do keyboard layout conversion, so if you have a German keyboard, pressing 'z' will actually type a 'y'. This means that on the menu prompts (press y to continue, press y to quit, etc.), you actually have to press a different key to the one you're being prompted for. I decided to fix this in Chocolate Doom, so that when you're prompted to "press y", you really do have to press 'y' - whatever that key may be on your keyboard.

After this, it occurred to me that if Vanilla has the same bug, German Doomers (and others) have probably been living with this bug for years and have it ingrained into their skulls which key to press. So my question is: what should be the expected behaviour? The sensible thing to do would be to expect a real 'y' when we prompt for 'y', but have users of non-QWERTY layouts grown to expect the non-standard layout?

The same also applies to cheat codes: someone with a German keyboard would have to type IDMZPOS instead of IDMYPOS, for example.


Why not just make it configurable?

If you don't want to do that, I'd suggest keeping the vanilla behaviour, myself - prboom and prboom-plus also retain this, and people who'll use chocolate-doom will probably be more used to those ports than to ones that have moved further away from the original game (like zdoom, which fixes this behaviour).

Share this post


Link to post
fraggle said:

I have a question for anyone who has an unusual keyboard layout (ie. non-QWERTY). For example, German keyboards have a QWERTZ layout.

Vanilla Doom doesn't seem to do keyboard layout conversion, so if you have a German keyboard, pressing 'z' will actually type a 'y'. This means that on the menu prompts (press y to continue, press y to quit, etc.), you actually have to press a different key to the one you're being prompted for. I decided to fix this in Chocolate Doom, so that when you're prompted to "press y", you really do have to press 'y' - whatever that key may be on your keyboard.

After this, it occurred to me that if Vanilla has the same bug, German Doomers (and others) have probably been living with this bug for years and have it ingrained into their skulls which key to press. So my question is: what should be the expected behaviour? The sensible thing to do would be to expect a real 'y' when we prompt for 'y', but have users of non-QWERTY layouts grown to expect the non-standard layout?

The same also applies to cheat codes: someone with a German keyboard would have to type IDMZPOS instead of IDMYPOS, for example.



For in-game key handling this doesn't really matter and with the methods at hand it will be hard to fix anyway. DirectInput under Windows doesn't offer any means of keyboard localization and neither does SDL if it is used with DirectInput.
Keyboard mappping only is important when entering text into a console or another editing field (e.g. savegame names)

As for expecting an 'y', my first reflex is to hit 'y' and if it doesn't work, hit 'z' afterward. It's totally inconsistent between games, even modern ones. Some developers think about this and others never seem to care at all and force US layout onto everybody.

Share this post


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