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

twipley

Members
  • Content count

    36
  • Joined

  • Last visited

Everything posted by twipley

  1. twipley

    Chocolate Doom

    Great! I have one question though: can absolute paths now be specified in the config files?
  2. (I do not let my torrent client opened. If you need a seed, leave me a note and I will do so in the following days.) It might be interesting to compare both of these. kkaden (over at github) has noted some differences between the two. The quest is to find or attain the original, intended, authentic Doom audio experience.
  3. I have always played Doom using the keyboard, as I think it is offering a greater challenge this way. However, I am now configuring a gamepad in order to play it that way. Weapon cycling is made through the shoulder buttons. For the rest (fire, use, strafe, and run), just for fun I have been seeking default controls, so as to be playing the way developers intended it in the manual. key mappings from the manual: i.imgur.com/xaVBScg.png; "If you are using a joystick, use button 1 to shoot and button 2 to open doors and activate switches. Gravis PC Gamepads have a third and fourth button. These can be used as a Strafe and a Run button, respectively." (1 to fire; 2 to use; 3 to strafe; and 4 to run.) However, it has revealed itself kind of hard to know which is button 1, button 2, and so on. I cannot just assume button 1 for Doom developers to be button 1 for Logitech developers (my gamepad being http://www.amazon.com/Logitech-963335-0403-Precision-Gamepad/dp/B00030AX3Q/). Indeed, there seems to be no industry standard in the definition of internal button orders. I have stumbled upon different links, driving hypotheses in the regard of determining intended mappings: 1) http://www.epanorama.net/documents/joystick/pc_special.html#gravispad -- 1 for left; 2 for up; 3 for down; and 4 for right; which was the popular PC gamepad back in the days of Doom development; however, I am not sure of the posted internal button order; it would have to be tested by someone who has access to that device; 2) http://pineight.com/mw/index.php?title=USB_game_controller#Gravis_GamePad_Pro_USB -- if Gravis has kept the same button order for the USB version of this gamepad which was made like five years later (which I reasonably doubt), then the original Gravis-gamepad button order would be 1 for left; 2 for down; 3 for right; and 4 for up; 3) if the manual took in mind the button order of the snes, which was in vogue back then, then the a, b, x, and y buttons would translate to 1 for right; 2 for down; 3 for up; and 4 for left; -- resulting control schemes would be: gravis: left to fire; up to use; down to strafe; and right to run; usb-gravis: left to fire; down to use; right to strafe; and up to run; nintendo-snes: right to fire; down to use; up to strafe; and left to run; In summary, additional info and research would be needed to determine the very mapping the original manual referred to. EDIT: I have performed some more research on this matter. I have stumbled on a list of games which came out with support for the Gravis gamepad (http://www.mobygames.com/attribute/sheet/attributeId,26/offset,200/p,2/so,1d/). I have then tried to download the manuals for those games. Only one result came out as pertinent: http://www.abandonia.com/files/extras/24746_game_extra_1.pdf (Mortal Kombat User Guide) -- which mapped button A to red, B to blue, C to yellow, and D to green. Add this to both of those links: http://en.wikipedia.org/wiki/File:Gravis_pc_gamepad.jpg http://www.emulation64.com/guides/7/3/ Button 1 - Lynx Button B (Gravis Gamepad - Red Button) Button 2 - Lynx Button A (Gravis Gamepad - Blue Button) Button 3 - Lynx Option 1 (Gravis Gamepad - Yellow Button) Button 4 - Lynx Option 2 (Gravis Gamepad - Green Button) and "perhaps" then, judging from the small evidence weight, the intended control scheme is "left to fire; up to use; down to strafe; and right to run." EDIT2: It would still be relevant to receive confirmation, either from someone who could test this original gamepad at home, or who has access to its manual and could scan the relevant part for us to archive. EDIT3: from the Gravis PC Gamepad SDK: _____ || ---------------------------------------------- | \____||________ X-Axis Joystick A, X-Axis | __ GRAVIS \ Y-Axis Joystick A, Y-Axis | / \ GamePad B | Button A Joystick A, Button #1A | \__/ A C| Button B Joystick A, Button #2A |______________ D | Button D Joystick B, Button #1B \_____| Button C Joystick B, Button #2Bwhich means: _____ || ---------------------------------------------- | \____||________ X-Axis Joystick A, X-Axis | __ GRAVIS \ Y-Axis Joystick A, Y-Axis | / \ GamePad 2 | Button 1 Joystick A, Button #1A | \__/ 1 4| Button 2 Joystick A, Button #2A |______________ 3 | Button 3 Joystick B, Button #1B \_____| Button 4 Joystick B, Button #2Bso, the second set of buttons in the doom manual would have been referring to the "joystick b" pair of buttons; tl;dr: the intended control scheme might be "left to fire; up to use; down to strafe; and right to run."
  4. twipley

    [SEEKING] Intended Gamepad (Joystick) Controls

    Fine. I also assume that it would be easy to override (or just disable altogether) the autoconfiguration feature so that any layout can be used with any gamepad?
  5. twipley

    [SEEKING] Intended Gamepad (Joystick) Controls

    If shoulder buttons are added in, these might, as you say, well make sense from a practical point of view. I guess I had gone full canonical and went without the shoulder buttons. From that perspective, the "tl;dr (most-canonical) layout" makes sense from a practical point of view, since -- at least it seems to me -- strafe is more important and thus should be more accessible, in battle scenarios. The equation changes depending on whether shoulder buttons are there (or made use of) or not, so the results. There is nothing wrong with me in doing it the way you are doing it. The modernization of game controllers might well call for the modernization of input layouts.
  6. twipley

    [SEEKING] Intended Gamepad (Joystick) Controls

    no it's okay, since without it i never would have seen this. i am very happy to see this, since when i contacted you earlier about the default-layout idea, you had replied that it was not canonical enough to fit in the project's scope. i always felt somewhat different about this, and i am glad that you have reconsidered your position. i also agree that the 'original' layout is nice and was well-thought. "I think Doom's defaults have been chosen with the Gravis Gamepad in mind." -- at least, that's what perspires from the manual, which can be considered a canonical bible since it was released back in 1993. EDIT: how come both your layouts feature 'down to run'? mine suggested 'right to run', instead. quote: tl;dr: the intended control scheme might be "left to fire; up to use; down to strafe; and right to run. here is, straight from the manual: where do our logics diverge? they should have met and converged.
  7. twipley

    [SEEKING] Intended Doom SC-55 Music

    Yeah, I think that's about what he said! (Or, at least what I inferred from it!) Although, I didn't understand all of the repercussions, so I asked him if he could publish those "unmolested masters" in order for us all to test on. More choices means more stuff for reviewin', right? :)
  8. twipley

    [SEEKING] Intended Doom SC-55 Music

    Chocolate Doom now has implemented such-packs support! :applaudes: EDIT: beaten by fraggle. That being said, more pack reviews would be needed! EDIT: beaten by fraggle, too. (hehe) Awesome work by fraggle in the past weeks, first off adding a hardware-based-scaling prototype, then support for such-packs. :applaudes: :) I have two questions in mind: a) as for the sound effects (http://www.perkristian.net/game_doom-sfx.shtml, for example weapon, monster, and washing-machine-switch sounds, they are not stored in MIDI form and therefore a sound-effects pack would not be needed in order to reach original experience, right? b) I have asked MI if he could publish uncompressed versions of his pack, which he said he would do. If I remember correctly, he told me in an email that it has to do with the volume level, which might be best not to fiddle with using in-port volume sliders, which would best be left at 100% (in order to prevent degradation or something?). That being said, I have noticed Chocolate Doom, probably in order to match the original game, has that slider set to 50%. Would not that go against the recommendation stated above, therefore inducing (if I did understand correctly) degradation? Or perhaps did I just misinterpret, which might well be the case. In any case, I am leaving this here in order for all to reflect on.
  9. twipley

    [SEEKING] Intended Doom SC-55 Music

    Hello world! Back in early January, I had emailed Bobby in order to ask him if he would be interested in giving us some input. I have not much to do with his reply since for me it reads like Chinese, but I am guessing others might find it enlightening plenty.
  10. twipley

    [SEEKING] Intended Doom SC-55 Music

    Gentle bump, so that people be informed of the above edit. :/
  11. twipley

    [SEEKING] Intended Doom SC-55 Music

    Both versions sound quite different. Especially, in some particular respects. I am quite a critic, although my musical tastes (and audition!) are not acquired enough for me to adequately judge. At any rate, though, it is an outstanding advantage that both works (packs) were performed in such a complete independence from one another. That is, nobody copied no one in their technique. Two independent minds have done it their own way. I am not to be a critic here. I could not; I do not even have the vocabulary. I (as others would) might be interested in reading more development in this regard. I am just happy that two such independent efforts produced the respective results they have. We are lucky to have something like this to compare. EDIT: I believe my preference (this is really a layman opinion, about which even I am not sure!) is Roth's pack for listening outside of the game, as more of the music seems to stand out; and Blume's encodings for listening inside of the game, as the music do not seem to thrust itself too much to awareness. More testing is needed before developing this opinion and grounding it into direct experience rather than speculative anticipations, though, as I myself have never, ever, played the game using such packs. I am stating this swoon opinion because I feel this thread would benefit from such inputs.
  12. twipley

    [SEEKING] Intended Doom SC-55 Music

    Hey, thanks for such an informative post! I hadn't realized the extent of the lengths you guys travelled, performing all of those subtle modifications over the original outputs. I am not sure of my opinion on this. On the one hand, you guys sure are going over for quality, and are very meticulous in their technique in doing so. On the other, though -- I hope my judgment is not clouded by the fact that I am, in terms of audio mastering, technically illiterate -- some part of myself is left wondering the pertinence of such modifications. While I realize these are applied for the common good, such techniques as multiband compression, peak limitation, cutting off mirror frequencies, and increasing the music volume (in comparison to the sound one) leave me with a touch of uneasiness. For example, if the original Doom experience is having more sound than music reaching your ears, then so be it! (Isn't it?) Although, as a purist, I might be biased. However, I think part of what the community (at least, the Chocolate-Doom one) is interested in, is in "unmolested" music. "Nothing beefed up, [so as to be] giving the pure sound of the original tracks to people who don't own one of those Roland devices." I have a hard time writing all of this without sounding like bashing both of you. Trust me, this is the farthest from my authentic intention. If I could talk to you guys face to face, you might understand that better. My delicate manners seem somewhat obscured by the coldness of all this text.
  13. twipley

    [SEEKING] Intended Doom SC-55 Music

    Here is -- I believe -- most of the relevant material from that thread: LogicDeLuxe answered: You also need loop data, though. The FLAC has to repeat itself while the fading notes and reverb at its ending is still playing. The exact point where the original MIDI ended has to be stored somewhere. LogicDeLuxe answered: I played the MIDI's provided in this thread earlier to the end, until the last note and reverb is over.Unlike the MP2 tracks, this don't clip, really. I mastered them a few dB quiter than those MP2. There are some multiband peak compression involved on very few occasion. And the peak limiter softens some peaks slightly. I sure compared every mastered track carefully to the original recording at the same RMS loudness to be sure that there is no significant difference. I am the last who would overcompress or clip a recording just to make it excessive hot. The RMS matches those of the late 80's and early 90's which used to be a good compromise between loudness and resolution usage. I usually master at -14 dBFS RMS sine, and this one is even slightly softer. In my experience, there are only few cases where even more dynamic is important, which are mainly classic, some jazz styles and audio dramas. Most mastering guys probably would have edited this much more aggressively, I guess. Compare this sound to those mainstream CD's released over the past few years, for instance. Btw. I am a TurnMeUp supporter. Other than this, I cut off the mirror frequencies above 16kHz with a FFT filter and did a phase true subsonic filter below 30 Hz to save some power. (Lowest note in those tunes has a base frequency at about 45 Hz.) No noise reduction involved, since the SC-155 has already a pretty good noise ratio. Thus no need to mess with it. Looping is one not so trivial think to do. The problem is, that I would chop of the reverb if I'd just cut the end. You could insert it to the beginning in order to prevent this, but then, it won't sound like a real beginning anymore. Thus, the best think to handle this issue would be an engine handling this, ie. restart the track from the beginning while still playing the reverb of the last note.Do you mean the OPL3 and the MU5 example? If yes, it well could be the case. Some of my cables have its colors wrong on the RCA jacks for some reason, and I just quickly made those examples without checking the channels. I did for the Sound Canvas recordings, though, I think.
  14. twipley

    [SEEKING] Intended Doom SC-55 Music

    I guess you're right. I meant he would have liked people to use SC-55s. Because, it permits hearing Doom the way it was designed to sound like.
  15. twipley

    [SEEKING] Intended Doom SC-55 Music

    This, or inquire about the method each of Roth and Blume used. Because, isn't after all the only needed equipment the Roland sound card? It is what he intended people using. I really wonder what is the cause of differences between both above encodings. EDIT: I've informed both Roth and Blume about the existence of this thread.
  16. twipley

    Chocolate Doom

    Here is Doom music as it was intended to be heard! https://github.com/chocolate-doom/chocolate-doom/issues/245 kopasite.net/up/1/doom-rc-55-soundtrack.torrent -- you are welcome sharing this with your friends. Comparison between two different encodings: -- Roth (LogicDeLuxe) from http://www.abmischung.de/index.html -- Blume (MusicallyInspired) from http://sc55.duke4.net/index.php EDIT: comparison discussion over at http://www.doomworld.com/vb/doom-general/66795-seeking-intended-doom-sc-55-music/
  17. twipley

    Chocolate Doom

    Hey, fraggle! I was just wondering if you were planning implementing both of these below to the next version? http://sourceforge.net/p/chocolate-doom/bugs/245/ http://sourceforge.net/p/chocolate-doom/bugs/246/ Just out of curiosity. For the sake of a classic game. :)
  18. twipley

    Chocolate Doom

    this is a great idea! fraggle: should a ticket be opened on the bug tracker to that effect? in other words, would such an implementation be a feasible undertaking? -- edit: one has been opened: http://sourceforge.net/tracker/?func=detail&aid=3560986&group_id=144368&atid=758618 it is to be hoped the enhancement request is on a par with the objectives of the project. after all, it would have a hard time not being, as the main page notes "chocolate doom is a doom source port that accurately reproduces the experience of doom as it was played in the 1990s."
  19. twipley

    Chocolate Doom

    Well, I am feeling slightly uncomfortable monopolising the thread as I feel I am now doing, but let me do so for be it just a brief moment. Let the choice now be made between, quote unquote, "non-integer vertical scaling and non-integer horizontal scaling," although both resulting in the intended aspect ratio. That would bring us to either: - 1333x1000 (integer-scale-factor vertical scaling); - 1280x960 (integer-scale-factor horizontal scaling); I think those might be two interesting outputs to a 1920x1080 monitor. "Which one, though, would be better than the other?" EDIT: I think the answer to this question might be to go with the 1333x1000 one, because, on the one hand, it is bigger, and, on the other (although I am not sure if that matters at all), it "preserves the scanline structure." EDIT2: I have been thinking about it, and would not it be better to just, upon entering the full-screen mode, integer-factor scale it to the most on the vertical axis, then stretching the horizontal axis so as to reach the intended 4:3 ratio? It seems to me the best that could be done about it, in terms of mimicking the original Doom experience. I know there were not any black borders back then, but hey! (What could one ever do about it anyway.)
  20. twipley

    Chocolate Doom

    Indeed, it's quite obscure a thing to want control over, but at the same time it's the only way for some to maintain the aspect ratio (which can be quite a perceptible thing) while also maintaining the native monitor resolution. I wrote "for some" as for some people, it seems the graphics drivers are not in a position to add the black bars by themselves, and thus need to rely on the software to maintain the native monitor resolution. I am definitely staying tuned for this one. I agree with the "hidden" part of it, but at least it would be there for those who need it. Thanks in advance for keeping this suggestion into consideration, fraggle. You said in an interview you would not know what features will reveal themselves in need of being implemented in the future, and I believe this one is one of them. <(+_+)> Sure thing. [Done.]
  21. twipley

    Chocolate Doom

    Well since, as Mr. Duck Major as put it, and if there is no way for one to use the 1920x1080 native resolution in combination with a "1280x960" output instead of a "1280x1000" one, could a feature request be proposed? It would indeed be nice, in my opinion, to make that possible, for example through "-geometry 1280x960 -width 1920 -height 1080," or something to that effect. Would that be something you would find worthwhile to implement, fraggle? I imagine such features may take a lot of fiddling around to code, test, and implement, but still, what do you think? -- as a due compensation for the double post, here is a bug report: Import the first registry key, then problems will happen on firing up the game, then import the second to fix it back. Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Console\%SystemRoot%_system32_cmd.exe] "FullScreen"=dword:00000001 Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Console\%SystemRoot%_system32_cmd.exe] "FullScreen"=- (Note that I am unable to reproduce this issue, which I had last year, though. In other words, when one sets the Windows-XP "console" to fire up in fullscreen mode from its properties dialog, a flag is added that made Chocolate Doom unable to start up properly. The bug may have been fixed already, but I am pretty sure it was affecting me in v1.5.0 using "-width 1920 -height 1080" under my back-then platform configuration. Hope this can be of any help. Probably an overall-insignificant and -incomplete bug report, though -- sorry about that!)
  22. twipley

    Chocolate Doom

    Porsche Monty, you are right! Doing so (wonderfully!) fixed the issue. I have done some tests, and I think the difference is way more perceptible if using a non-standard aspect ratio such a 1.28. the best thing for 16:9 1080ps might therefore be running a 1280x960 rectangle output inside a 1920x1080 whole-screen output. How would one be supposed to do so, though? "-width 1280 -height 960" switches the screen resolution to the latter non-native value, while what is looked for is maintaining the native 1920x1080 resolution.
  23. twipley

    Chocolate Doom

    Sorry for the double post. -- (I would need a hand here, fellows!) How I am supposed to run it in the 1280x960 centre area of a 1920x1080 output? To run it in a 1280x1000 area, I am using "-width 1920 -height 1080," but when I want to compare that in screenshot form to the former, I wonder if "-width 1280 -height 960" is what should be used in order to keep the native 1920x1080 resolution (and black bars) intact. Another thing I am wondering about is how to take screenshots in order for resolution comparison to be made. I am able to "print screen" using 1280x1000, but using 1280x960 the taken screenshots for some reason contain heavy artifacts, which render the comparison impossible. I am not sure "-devparm" is of any help here, as the taken screenshots are limited to being quite of a low resolution.
  24. twipley

    Chocolate Doom

    Alright. Thanks for the input. Perhaps using such high resolutions, the significance of performing whether integer scaling or not diminishes anyway; in perceptual terms, that is. Indeed. I wonder how did I miss understanding that post to its full extent.
  25. twipley

    Chocolate Doom

    What are you meaning? I thought 1280/320 was giving out 4, therefore integer horizontal scaling in both output cases. But then again, it features non-integer scaling, which, technically, is less authentic than "exact" scaling, is not it? So, how does that weigh less in the scale compared with non-authentic aspect ratios? (I am just wondering really, more so than arguing for the direct sake of arguing.) -- twipley
×