Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Sign in to follow this  

    Chocolate Tastes Better than Vanilla


    Bloodshedder

    fraggle writes in that he's released version 0.1.1 of his Chocolate Doom port. If you haven't heard about it, Chocolate Doom is an SDL-based Doom port that aims to emulate the original DOS executable behavior as closely as possible.

    Sign in to follow this  


    User Feedback

    Recommended Comments

    10/18/05. Coincidence? I think pretty much everyone saw this coming. Talk about trying to steal the thunder from Quake 4.

    Share this comment


    Link to comment
    AndrewB said:

    10/18/05. Coincidence? I think pretty much everyone saw this coming. Talk about trying to steal the thunder from Quake 4.


    Yeah, Raven is gonna be pissed they got one-uped.

    Share this comment


    Link to comment

    Error: Error setting video mode: No available video device

    OH GNOES!

    Edit: Uh, right. I exited my chroot and then re-entered it and it worked. Anyway, this is sex.

    Edit again: Is there any way to change to sound output to oss? SDL sounds like arse on my machine.

    Share this comment


    Link to comment
    exp(x) said:

    Error: Error setting video mode: No available video device

    OH GNOES!

    Edit: Uh, right. I exited my chroot and then re-entered it and it worked. Anyway, this is sex.

    Edit again: Is there any way to change to sound output to oss? SDL sounds like arse on my machine.

    export SDL_AUDIODRIVER=oss

    Share this comment


    Link to comment

    One problem I have with this that I do not experience in the original .exe (just now tested it to make sure I'm not crazy), is that if I'm holding down the shift key (running) and I press any other key simultaneously, I am no longer running.

    Makes it virtually unplayable for me. :(

    Other than that, I see no apparent problems. Good luck fraggle.

    EDIT: I just noticed that in the "Read This!" screen, you can see the skull cursor in the lower right quadrant of the screen. Happy bug hunting :)

    Share this comment


    Link to comment

    Something like that can and does happen in Doom; right after you start the game, and I also experienced it in Chocolate Doom. But I was just now in Chocolate pressing both run and forward simultaneously and they don't fail.

    The thing is, if you have a key pressed down as it starts, it won't do anything until you let go and press it again. So if either both or forward fail you don't move, and if speed fails you just walk.

    Since the start up for either engine isn't exactly the same, reproducing the effect on either isn't identical, but it happens on both that keys fail to read input if pressed too early.

    Were you using Doom under DOS or Windows? Start up might be different under DOS (we know it is in some senses, like you can shift your direction before the screen is loaded when playing on Windows.)

    If you're getting this problem all the time (not just during startup) you might be having some issue that depends on your system.

    In Doom I've also had combinations where certain keys will fail, when pressing 3 or more keys simultaneously; such as being unable to press use while strafe running in one direction (though use still works from the mouse then.) Not sure how much that depends on hardware though, if at all.

    EarthQuake said:
    EDIT: I just noticed that in the "Read This!" screen, you can see the skull cursor in the lower right quadrant of the screen. Happy bug hunting :)

    Nah, if you think that's a bug go tell whoever built Doom's menu code.

    Share this comment


    Link to comment

    Certain keyboards don't properly signal if a certain number of keys or more are depressed; old keys either get "lost" or the new ones never register.

    Share this comment


    Link to comment
    myk said:

    Were you using Doom under DOS or Windows? Start up might be different under DOS (we know it is in some senses, like you can shift your direction before the screen is loaded when playing on Windows.)


    If I read that correctly, you say that turning in advance should be done in Windows? That is not the case. Back when I still had that 486, I used it many times in DOS, actually it was very easy because the screen used to load for quite some time (especially when loading a large map).

    Share this comment


    Link to comment
    Bloodshedder said:

    Certain keyboards don't properly signal if a certain number of keys or more are depressed; old keys either get "lost" or the new ones never register.

    If you have a list of keyboards that don't exhibit this behavior, please share it.

    Share this comment


    Link to comment

    Bloodshedder said:
    Certain keyboards don't properly signal if a certain number of keys or more are depressed; old keys either get "lost" or the new ones never register.

    Makes sense; mine's an IBM keyboard from the late '80s.

    Donce said:
    If I read that correctly, you say that turning in advance should be done in Windows? That is not the case. Back when I still had that 486, I used it many times in DOS, actually it was very easy because the screen used to load for quite some time (especially when loading a large map).

    Yeah, my mistake... this talk brings something else up, though; that the "pre-turning" thing doesn't work in Chocolate Doom, like in PrBoom and whatnot.

    Share this comment


    Link to comment
    EarthQuake said:

    One problem I have with this that I do not experience in the original .exe (just now tested it to make sure I'm not crazy), is that if I'm holding down the shift key (running) and I press any other key simultaneously, I am no longer running.

    Makes it virtually unplayable for me. :(


    Are you absolutely sure you're using the latest version I released on the site? I ask because I had a bug like this in older versions which I fixed.



    Other than that, I see no apparent problems. Good luck fraggle.

    EDIT: I just noticed that in the "Read This!" screen, you can see the skull cursor in the lower right quadrant of the screen. Happy bug hunting :)

    I haven't changed anything here. This is the behavior of the original Doom :-)

    Thanks everyone for your comments.

    Share this comment


    Link to comment
    myk said:

    Makes sense; mine's an IBM keyboard from the late '80s.

    As far as I know, though, it isn't a function of when the keyboard was manufactured. More than likely it's either a microcontroller limitation, a bus limitation, or an operating system limitation. If it affects both certain PS/2 and USB keyboards, then the bus is thrown out as a factor.

    In some situations, the keyboard will stop accepting input beyond a certain number of keys and just cause the PC speaker to beep while the extra key is pressed. Other times, it will keep repeating the last key that is depressed, ignoring further keys that are pressed.

    I am basing these observations on keys that produce printable characters. I don't know if keys for controlling, such as control, alt, arrows, etc. behave any differently.

    Share this comment


    Link to comment
    ultdoomer said:

    So will you be allowed to record COMPET-N demos with this?

    Compet-n rules have been very clear and consistent on this over the years: the demos must be recorded with the original DOS exes. The fact that a demo plays back with the DOS exes is not enough on its own.

    I'd be very surprised if that were to change now.

    Share this comment


    Link to comment
    Grazza said:

    Compet-n rules have been very clear and consistent on this over the years: the demos must be recorded with the original DOS exes. The fact that a demo plays back with the DOS exes is not enough on its own.


    Yes, but that's probably bacause the features in the original executable-compatible sourceports (like PrBoom) allow you to have greater control of what the end result will be (slow-motion, demo joining, re-recording). But this port aims to be just like the original executables, like PrBoom, but without the extra features. In the post in the General Forum, it says it'll even go so far as to include the fatal bugs the originals had (like VPO).

    Share this comment


    Link to comment
    ultdoomer said:

    Yes, but that's probably bacause the features in the original executable-compatible sourceports (like PrBoom) allow you to have greater control of what the end result will be ...

    No, it's to provide a completely level playing-field. See this post by Adam_H too.

    Share this comment


    Link to comment

    I think added features makes it an unfair playing field (with PrBoom). Chocolate Doom doesn't add the new features, so I was hoping it would be okay.

    Share this comment


    Link to comment

    It is not a problem with my keyboard. I have played doom.exe on Windows 98 and Windows XP and despite any attempts, I cannot recreate the bug I experienced with latest build of Chocolate Doom that I downloaded the day before yesterday. I have even tried multiple keyboards.

    Sorry, but I am certain it is not a problem with my system.

    Concerning holding multiple keys: In Doom, I can hold down strafe, run, open, and two arrows keys simultaneously and not lose any response. In Chocolate Doom, I was losing my run after holding down only two keys simultaneously.

    As for the cursor in the "Read This!" screen, you're all correct. It is indeed a bug in the original game; I just never noticed it before <!>
    Sorry for the false bug report.

    Share this comment


    Link to comment

    well done Fraggle, I love chocolate. I can hardly wait for someone to make a butterscotch doom now.

    Share this comment


    Link to comment


    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

×