Chocolate Doom - Doomworld Forums

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Source Ports > Chocolate Doom

Pages (31): « First ... « 7 8 9 [10] 11 12 13 » ... Last »

Author

All times are GMT. The time now is 10:56.

myk

Posts: 14811
Registered: 04-02

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

Yeah, it had the error for me too.

12-08-06 18:46 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

RazTK
Junior Member

Posts: 149
Registered: 10-05

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.

Last edited by RazTK on 12-08-06 at 19:18

12-08-06 19:10 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6573
Registered: 07-00

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

Last edited by fraggle on 12-16-06 at 16:00

12-16-06 15:49 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Linguica

Posts: 3700
Registered: 05-00

fraggle said:
Hopefully this will make some people happy.

Aaaaaaaannaaaaaaaaaal.

12-16-06 19:19 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

RazTK
Junior Member

Posts: 149
Registered: 10-05

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

12-16-06 21:41 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

funduke
Member

Posts: 328
Registered: 02-04

RazTK said:
The latest Windows revision builds can always be found here.

Thank you for that!
I took the freedom, to place that link on the official Chocolate Doom Homepage.

Greetings
Funduke

12-17-06 15:49 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

ultdoomer
Junior Member

Posts: 234
Registered: 06-04

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.

12-29-06 20:53 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14811
Registered: 04-02

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?

12-29-06 21:25 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

entryway
Forum Staple

Posts: 2666
Registered: 01-04

fraggle, if you do not use SDL_MOUSEMOTION event you should not use SDL_WM_GrabInput(SDL_GRAB_ON) to avoid SDL mouse lag

http://prboom-plus.sourceforge.net/mouse_lags.zip

On fullscreen SDL code will work badly in any case

Last edited by entryway on 01-04-07 at 09:28

01-03-07 21:48 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

entryway
Forum Staple

Posts: 2666
Registered: 01-04

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

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

01-04-07 12:07 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6573
Registered: 07-00

entryway said:
fraggle, if you do not use SDL_MOUSEMOTION event you should not use SDL_WM_GrabInput(SDL_GRAB_ON) to avoid SDL mouse lag

http://prboom-plus.sourceforge.net/mouse_lags.zip

On fullscreen SDL code will work badly in any case

So with your invisible mouse cursor trick, is this no longer needed?

01-06-07 01:03 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

entryway
Forum Staple

Posts: 2666
Registered: 01-04

fraggle said:
So with your invisible mouse cursor trick, is this no longer needed?

yep

01-06-07 01:17 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

entryway
Forum Staple

Posts: 2666
Registered: 01-04

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)

01-06-07 11:32 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6573
Registered: 07-00

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.

Last edited by fraggle on 01-06-07 at 14:37

01-06-07 14:30 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

entryway
Forum Staple

Posts: 2666
Registered: 01-04

fraggle said:
My one concern is that this probably affects mouse acceleration

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

01-06-07 17:07 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Bashe
Forum Staple

Posts: 2097
Registered: 11-03

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.

01-07-07 21:49 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14811
Registered: 04-02

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.

01-07-07 22:08 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Bashe
Forum Staple

Posts: 2097
Registered: 11-03

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

01-07-07 23:26 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Janizdreg
Member

Posts: 333
Registered: 07-02

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.

01-14-07 10:47 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14811
Registered: 04-02

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.

01-14-07 11:03 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Janizdreg
Member

Posts: 333
Registered: 07-02

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.

01-14-07 13:14 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Grazza
Inventor of "Y Y" to quit

Posts: 11784
Registered: 07-02

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

code: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:

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

01-14-07 15:28 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6573
Registered: 07-00

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

code:
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:

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

Last edited by fraggle on 01-14-07 at 15:49

01-14-07 15:30 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5158
Registered: 08-00

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.

01-14-07 16:30 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Janizdreg
Member

Posts: 333
Registered: 07-02

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:

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

01-14-07 20:09 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5158
Registered: 08-00

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.

01-15-07 17:47 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Janizdreg
Member

Posts: 333
Registered: 07-02

Does this mean that PC speaker support could be implemented in Chocolate Doom?

03-04-07 20:36 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6573
Registered: 07-00

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.

03-09-07 13:26 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Schneelocke
Forum Regular

Posts: 741
Registered: 06-03

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

03-09-07 13:42 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

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.

03-09-07 14:03 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

VinceDSS
Senior Member

Posts: 1295
Registered: 11-02

I got a french AZERTY.

When using vanilla EXEs, my keyboard works like a QWERTY.

The following keys are swapped :
- A and Q
- Z and W
- M and :/;
- all the caracters have different location

So it gets tedious when typing messages in coop/dm, and even cheat codes.

03-09-07 16:30 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6573
Registered: 07-00

Graf Zahl said:

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)

SDL keyboard events have a "sym" field that denotes the key pressed (this never changes regardless of the keyboard mapping), and a "unicode" field that denotes the character typed.

Anyway, I think I'm going to go with a mixed approach: Chocolate Doom will behave like Vanilla does - my reasoning being that Vanilla users will be used to pressing the wrong keys. However, for actually typing things in (savegame names and multiplayer messages), the proper typed character will be used. People can be used to pressing the wrong keys to drive the menus and enter cheat codes, but it can only ever be annoying when entering text.

03-09-07 22:14 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

fraggle said:
SDL keyboard events have a "sym" field that denotes the key pressed (this never changes regardless of the keyboard mapping), and a "unicode" field that denotes the character typed.

As long as Windows keyboard events are used this will work correctly. But last time I checked when using DirectInput for the keyboard SDL used a hard coded US mapping because DI bypasses the keyboard mapper. I can't say if there is any chance to control this though. It was some time ago...

03-09-07 22:36 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14811
Registered: 04-02

fraggle said:
Anyway, I think I'm going to go with a mixed approach: Chocolate Doom will behave like Vanilla does - my reasoning being that Vanilla users will be used to pressing the wrong keys. However, for actually typing things in (savegame names and multiplayer messages), the proper typed character will be used. People can be used to pressing the wrong keys to drive the menus and enter cheat codes, but it can only ever be annoying when entering text.

I note the difference only when typing text, since I have a Mexican keyboard and usually expect the keys to be taken as under an English layout (the letters and numbers are in the same places, but many of the special characters are not), so I initially type with the "wrong" keys, but I waste time correcting my typing messages during games, as in Chocolate they are not mixed up.

Wouldn't a compatibility in the custom CFG be more helpful? People who want that to work like in Doom could toggle it on (perhaps the default), and those that want it to read their nonEnglish or nonQWERTY keyboard properly could leave it at 0.

This would allow Chocolate to work as Doom without necessarily annoying those who can't stand the messed up layout (especially users who never used Doom with a nonEnglish key layout).

I think a compatibility method makes more sense than a hybrid, in any case.

03-09-07 22:44 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Janizdreg
Member

Posts: 333
Registered: 07-02

Janizdreg said:
Does this mean that PC speaker support could be implemented in Chocolate Doom?

To answer my own question, PC speaker support has been added to Chocolate Doom in the latest unofficial builds. If you want to try it out, you can set the snd_sfxdevice setting in the Doom config file to 1. Though now I'm hoping that fraggle will add an option for choosing the SFX device in Chocolate-setup for easier access to this setting.

I must also comment that I just spent the last hour playing Chocolate Doom with the PC speaker sounds on, which was very nostalgic for me since I first played Doom on a 386 with only PC speaker sounds available. I really appreciate the chance to get to relive those childhood memories, so big thanks to Chocolate Doom and fraggle for that.

03-10-07 02:17 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6573
Registered: 07-00

myk said:
I note the difference only when typing text, since I have a Mexican keyboard and usually expect the keys to be taken as under an English layout (the letters and numbers are in the same places, but many of the special characters are not), so I initially type with the "wrong" keys, but I waste time correcting my typing messages during games, as in Chocolate they are not mixed up.

Wouldn't a compatibility in the custom CFG be more helpful? People who want that to work like in Doom could toggle it on (perhaps the default), and those that want it to read their nonEnglish or nonQWERTY keyboard properly could leave it at 0.

This would allow Chocolate to work as Doom without necessarily annoying those who can't stand the messed up layout (especially users who never used Doom with a nonEnglish key layout).

I think a compatibility method makes more sense than a hybrid, in any case.

Yeah, I'm starting to think you may be right. In general I kind of dislike adding in more configuration options, so I try to avoid it if I can.

Janizdreg said:
To answer my own question, PC speaker support has been added to Chocolate Doom in the latest unofficial builds. If you want to try it out, you can set the snd_sfxdevice setting in the Doom config file to 1. Though now I'm hoping that fraggle will add an option for choosing the SFX device in Chocolate-setup for easier access to this setting.

I must also comment that I just spent the last hour playing Chocolate Doom with the PC speaker sounds on, which was very nostalgic for me since I first played Doom on a 386 with only PC speaker sounds available. I really appreciate the chance to get to relive those childhood memories, so big thanks to Chocolate Doom and fraggle for that.

I'm glad you like it :-) I posted this in the other thread already, but I put a video of this on youtube, here for anyone that hasn't seen.

Graf Zahl said:

As long as Windows keyboard events are used this will work correctly. But last time I checked when using DirectInput for the keyboard SDL used a hard coded US mapping because DI bypasses the keyboard mapper. I can't say if there is any chance to control this though. It was some time ago...

I just tried running Chocolate Doom in Windows with a german keyboard mapping and it seems to work fine (mapping is done correctly). Perhaps it's been fixed in SDL?

Last edited by fraggle on 03-10-07 at 03:47

03-10-07 03:32 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

fraggle said:
I just tried running Chocolate Doom in Windows with a german keyboard mapping and it seems to work fine (mapping is done correctly). Perhaps it's been fixed in SDL?

It may be. Did you run fullscreen or in a window? If I remember correctly that makes a difference for SDL.

03-10-07 09:13 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6573
Registered: 07-00

Graf Zahl said:

It may be. Did you run fullscreen or in a window? If I remember correctly that makes a difference for SDL.

I'm pretty sure it was running in a Window, as keyboard mapping is (for some reason) done on an application-by-application basis in Windows, and I needed to switch to the DE mapping after the program started.

03-10-07 16:46 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

entryway
Forum Staple

Posts: 2666
Registered: 01-04

I have found an incompatibility between doom2.exe and chocolate\prboom. Check this test level as example. The sector will rise differently in doom2.exe and chocolate-doom.exe. It happens, because all original EXE's don't check for overflow of heightlist[MAX_ADJOINING_SECTORS] array in P_FindNextHighestFloor() as distinct from linuxdoom and all derived ports (dosdoom, tasdoom, chocolate)

You should rewrite this function as follows:

code:// 20 adjoining sectors max!
//#define MAX_ADJOINING_SECTORS    	20

fixed_t
P_FindNextHighestFloor
( sector_t*	sec,
  int		currentheight )
{
    int			i;
    int			h;
    int			min;
    line_t*		check;
    sector_t*		other;
    fixed_t		height = currentheight;
    fixed_t		*heightlist;

    static int MAX_ADJOINING_SECTORS = 0;

    if (MAX_ADJOINING_SECTORS == 0)
        MAX_ADJOINING_SECTORS = M_CheckParm("-doom95") ? 500 : 20;

    heightlist = malloc(sec->linecount * sizeof(heightlist[0]));

    for (i=0, h=0 ;i < sec->linecount ; i++)
    {
	check = sec->lines[i];
	other = getNextSector(check,sec);

	if (!other)
	    continue;
	
	if (other->floorheight > height)
	{
	    // Emulation of memory (stack) overflow
	    if (h == MAX_ADJOINING_SECTORS + 0)
	        ; //do nothing
	    if (h == MAX_ADJOINING_SECTORS + 1)
	        height = other->floorheight;

	    // Check for fatal overflow. Exit.
	    if ( h == MAX_ADJOINING_SECTORS + 2 )
	        I_Error("Sector with more than 20+2 adjoining sectors. "
                        "Vanilla will crash here");

	    heightlist[h++] = other->floorheight;
	}
    }
    
    // Find lowest height in list
    if (!h)
    {
	free(heightlist);
	return currentheight;
    }
		
    min = heightlist[0];
    
    // Range checking? 
    for (i = 1;i < h;i++)
	if (heightlist[i] < min)
	    min = heightlist[i];
			
    free(heightlist);
    return min;
}

Or simply delete the check for overflow.

Last edited by entryway on 06-04-07 at 20:01

06-04-07 15:47 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6573
Registered: 07-00

Just saw this. Thanks! I'll get onto it.

06-12-07 19:26 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

entryway
Forum Staple

Posts: 2666
Registered: 01-04

prboom-plus\p_spec.c with fixed P_FindNextHighestFloor()

P.S. I saw you fixed it already in repository :)

Last edited by entryway on 06-12-07 at 20:39

06-12-07 19:51 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

LogicDeLuxe
Member

Posts: 628
Registered: 08-03

Are there plans for 1.2 compatibility?
There are several changes keeping maps designed for 1.2 from working as intended.

All collectible stuff has the standard pickup sound.

Sectors can be 32768 units high without crashing the game (though you encounter visual glitches when they are taller than 512 units).
For testing this issue, check out FORGEX.WAD which has a lift going down really deep. The game often crashes when walking near the shaft. V1.2 never crashes there.

Lost Souls count for kills.

Stairbuilders have no clunk sounds (only the crusher sound is there)

Max. health is 199 and armor is unlimited.

Lower floor to lowest neighbor and copy type and texture got the target type and texture from the least numbered neighbor, regardless of its height. (since 1.666, it's the least numbered neighbor which matches the target height)
Some mapping errors (including the original E3M9 prior 1.9) producing an invalid sector type, because the tagged sector is lower than its neighbors.

06-15-07 20:37 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14811
Registered: 04-02

Older version compatibility seems more a thing PrBoom could go for, but there are other more obscure issues to deal with, such as a weird movement glitch when recording demos, and the buggy line type used in the second level of Return to Phobos, that is hard to emulate.

LogicDeLuxe said:
For testing this issue, check out FORGEX.WAD which has a lift going down really deep. The game often crashes when walking near the shaft. V1.2 never crashes there.

Where? In the red room with the two end level shafts? I couldn't get it to crash there. I know of a crash when you fall great distances, though, and you are right that it doesn't affect v1.2 (where you get HOMs, or something, instead).

A good wad for seeing that falling limit is Daniel Hornbaker's The Apocalypse Project; in E1M9 you jump down an abyss where the error can occur (to avoid it in v1.9, let the player fall straight instead of running forward). Here is a demo (recorded with PrBoom+) that triggers the error. Curiously, Doom says it's an R_MapPlane error, while Chocolate Doom calls it an R_DrawColumn error.

06-15-07 23:24 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

LogicDeLuxe
Member

Posts: 628
Registered: 08-03

I recorded a demo of forgex.wad
http://rapidshare.com/files/37512013/forgecra.lmp.html
It crashes with Error: R_MapPlane: 316, 316 at 244 in Chocolate Doom.

Also seen is an imp trapped in the floor due to a blockmap bug from the really old bps builder. You can fall in there as well when walking slow on that spot.

06-16-07 12:11 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14811
Registered: 04-02

Ah, I see, the deep lift. It's curious how it is caused when there is both vertical and horizontal movement, but not when there's little or no horizontal movement. I guess scrolling the texture very fast isn't a problem, but suddenly having to load extra textures to scroll is.

PS: You got me going with "crash" as well but it's not a really crash, but a only terminal error.

06-16-07 13:54 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

aleksej
Junior Member

Posts: 119
Registered: 10-06

fraggle, can you add one optional fix for control?
I'm always use WASD keyset but i'm not use W for move forward. Instead it i use left mouse button. And in that case doom have one issue. By default mouse button used for move forward behaves as open/use in double-click and this can't be disabled. This is a big inconvenient. entryway fix it in prboom-plus at my request by adding that option in game settings. Please do same with your chocolate!

06-17-07 09:55 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14811
Registered: 04-02

c.imp said:
Please do same with your chocolate!

That sounds like something completely against the spirit of the engine; which is to work like the original as much as possible, and to be an interchangeable port with it (using either should be the same as far as possible). When inconvenients are "bugs" the DOS engine shares, they are things Chocolate Doom isn't really meant to fix, but to either emulate or support.

I had that issue too for some time, as moving forward would sometimes make me close doors I was attempting to open. What I did is change my setup. I use a key for key_up, and I replaced key_strafe with mouseb_strafe, in case I need sr50 movement.

06-17-07 12:47 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

aleksej
Junior Member

Posts: 119
Registered: 10-06

This one not related to comatibility broke. Previously recorded demos (if some exist) with this behavior don't goes out of sync. And this fix can be optional like in prboom+

06-17-07 13:04 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14811
Registered: 04-02

c.imp said:
And this fix can be optional like in prboom+

Chocolate Doom is not just about demo compatibility. You could also fix every other bug in the engine that way (like, screen resolution would definitely not alter demo compatibility either), but what's the point? In any case, if this is fixed, how does it fix the problem in Doom, which is supposed to be the same as Chocolate Doom as far as functionality? You're making the engines different, which means that a Chocolate Doom user (that uses this option you request) will have a problem using Doom.

Another option is to use an advanced mouse driver, like Microsoft's Intellipoint (which can be downloaded for free from Microsoft or other places) to swap mouse functions when you play Doom or Chocolate Doom. With this you'd be able to keep your unusual setup by temporarily changing the function of your mouse button (to the effect of a keyboard key).

06-17-07 13:46 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6573
Registered: 07-00

myk said:
Chocolate Doom is not just about demo compatibility. You could also fix every other bug in the engine that way (like, screen resolution would definitely not alter demo compatibility either), but what's the point? In any case, if this is fixed, how does it fix the problem in Doom, which is supposed to be the same as Chocolate Doom as far as functionality? You're making the engines different, which means that a Chocolate Doom user (that uses this option you request) will have a problem using Doom.

Another option is to use an advanced mouse driver, like Microsoft's Intellipoint (which can be downloaded for free from Microsoft or other places) to swap mouse functions when you play Doom or Chocolate Doom. With this you'd be able to keep your unusual setup by temporarily changing the function of your mouse button (to the effect of a keyboard key).

To be honest, considering that it is possible to work around these things with driver settings, I'm tempted to just support it directly.

When it comes to input, you're dependent on the OS to provide you with input. Considering that you could theoretically simulate any kind of input you wanted, the notion of staying pure to Vanilla Doom becomes irrelevant.

As another example: there's no way to bind a joystick/joypad button to strafe left or right (did I mention I just added joystick support in the past week?). But programs exist that intercept the joystick input and simulate keypresses, so it's already possible to create a setup where a joystick button strafes left or right. In this situation, I might as well just add the ability to bind a joystick button to strafe left or right. Otherwise, all I'm doing is being deliberately obstructive and annoying.

06-17-07 20:52 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote