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

natt

Members
  • Content count

    248
  • Joined

  • Last visited

Everything posted by natt

  1. natt

    Did the original Boom have the tutti-fruitti bug?

    Ooops. Well you can't blame me, it was only one letter difference =p There's a WinMBF port somewhere, don't know much about it. But you're probably right. Of course, if you really want to test thoroughly, you can use Boom in dosbox.
  2. natt

    Did the original Boom have the tutti-fruitti bug?

    Chocolate doom is the closest thing to original doom in a modern package. It even does tutti frutti (although it doesn't look quite the same).
  3. natt

    Sound issues in PrBoom

    sdl_mixer strikes again! What version of prboom are you using? What operating system are you running?
  4. natt

    Did the original Boom have the tutti-fruitti bug?

    Boom fixed tutti-frutti. I checked the location in prboom-plus where the tutti-frutti fix is and didn't see anything turning it off or complevel related, so I'm going to say no to the other two questions. Note that while drawing garbage when wrapping a texture that's not 128 high is easy, drawing the RIGHT garbage is hard; exactly what Doom drew in the tutti frutti case was a buffer overrun and had to do with internal memory arrangement.
  5. natt

    Fluidsynth / Synth Players

    I protest! My awesome soundfont is not broken. It just doesn't supply anything for a lot of instruments because it's not intending to cover the general midi instrument set.
  6. It gets better if you have custom hardware. Since the cartridge has an IRQ request line, it can synch up to the PPU and generate Hblank IRQs. The whole thing would be a mess, but you'd be able to change palettes every scanline. You're still somewhat limited in the horizontal direction, and also, your total color palette is actually pretty small; 64 colors I think? Of which there are quite a few blacks.
  7. Well, what does the PPU do when it wants to display a tile? It asks the cartridge for it; sets the appropriate CHR A? pins, pulls down CHR /RD, and waits for the result on CHR D?. If you hook up special hardware there, and it's fast enough, you could completely forego the concept of CHR ROM or CHR RAM and simply generate tile data on the fly. I seen no reason why you couldn't generate full motion images at 256x240 and send them to the NES screen at 60fps. Your external CPU could render whatever it wants to an internal framebuffer and then translate the PPU's read requests on the fly. Course, you still only get 4 colors at a time. And it would be the most pointless project ever; simply having the specialized hardware generate its own composite video signal would be cheaper, easier, and not subject to arbitrary color limitations. Of course, at that point, it's no longer a nes cartridge.
  8. natt

    light transfer to walls

    Note that it doesn't even need to be "thin", because its light levels will be set to whatever you want by the transfers.
  9. natt

    Fluidsynth / Synth Players

    Fluidsynth works on WinXP. You can email me your test application if you like, and I'll take a look at it.
  10. natt

    Fluidsynth / Synth Players

    Heh, fluidsynth. I use the fluidsynth.dll I compiled myself, however I'm fairly certain I invoked a few black magics for that, so I'd recommend against it, what with the pig blood and all. Randy Heit maintains a fluidsynth.dll which is better than mine (doesn't pull in glib or gthreads dependencies). But if you just have a .dll, you need to use a .lib (msvc) or a .a (mingw) file at link time, which you can get by doing magic to the dll: pexports fluidsynth.dll > fluidsynth.def dlltool -d fluidsynth.def -l libfluidsynth.a lib /def:fluidsynth.def This creates libfluidsynth.a (usable by mingw at link time), fluidsynth.lib and fluidsynth.exp (usable by msvc at link time). 'pexports' and 'dlltool' are from mingw, 'lib' is from msvc I believe this is what entryway uses for the official prboom-plus builds; Randy Heit's fluidsynth.dll and a .lib file created as above. If you don't have the appropriate toolchains, I can email you the files no problem. One thing I can say that's good about this, is the exact same build script works on mingw and linux (and presumably any other posix-like system that fluidsynth compiles on), so you don't lose any cross-platform compatibility. As far as writing your own synth, IMO it mostly depends on how complex things get. My midi converter spits out "unknown" tags for quite a few of the Doom64 midi events. I know you've looked more closely at the Doom64 sound code than I have; but if one of those turns out to be "set reverb level" and one turns out to be "set lowpass resonance" etc etc, then you're writing a full fledged dsp and you might as well use fluidsynth at that point. I don't know any real alternatives though. I don't think timidity has a good API. There are a lot of good module file players out there, but I don't think most of them expose their synthesizer as an API either. I did a lot of synthesizer searching when I wrote new sound code for prboom-plus.
  11. natt

    .

    Floor, Ceil, Door, Keydoor, Lift, Stair, or cRrusher? [F/c/d/k/l/s/r]: k Kind of Door [0=Open-Close, 1=Open]: 1 Speed of Door [0=Slow, 1=Normal, 2=Fast, 3=Turbo]: 3 Door Key [0=Any, 1=RC, 2=BC, 3=YC, 4=RS, 5=BS, 6=YS, 7=All]: 3 Are skull and card keys the same, for this door? [Y/n]: y Trigger Type [0=W1, 1=WR, 2=S1, 3=SR, 4=G1, 5=GR, 6=D1, 7=DR]: 6 Linedef special type is: 15102 (dec) 3afeH (hex) Functional description: D1 Opn T RK, is this correct? [Y/n/Q(uit)]: q Trigger types starting with "D" mean that the tag is ignored and the backside sector is acted on instead. That's what the "D" trigger does.
  12. I've observed the following in DosBox (I'd do a real test, but my SB16 went south 10 years ago): When you pause the game, currently sustained notes are cut, but those notes aren't restarted when you unpause. I'd like to be sure that this is the way it was originally done and is not due to some bug in DosBox OPL2 emulation. The relevant section of chocolate doom (src/i_oplmusic.c, I_OPL_PauseSong() and I_OPL_ResumeSong()) do the same thing, with the additional comment "This is what vanilla does". Perhaps whoever wrote that comment has more information, perhaps from disassembly? The observations of anyone who can play Doom on a real OPL in real DOS would be helpful as well. It's easy to hear the difference in any music track with long, sustained notes; Doom2 MAP05 is one good one.
  13. If you still have that setup, you might consider trying it with the latest prboom-plus (use the "portmidi" midi player option). It's a different midi out codebase that doesn't use SDL mixer, and if there are any problems with it I might be able to fix them for you.
  14. Right, the notes would have new attacks so it wouldn't sound quite the same, but you could do it more or less.
  15. Sounds pretty definitive to me. Thanks for the testing.
  16. Yes, I understand all that. But nothing's stopping the program from resounding the notes that it cut off at the pause on resume.
  17. GZDoom, when using Fluidsynth, doesn't do it that way; the notes restart seamlessly after the pause ends. A patch will be committed soon to Prboom-Plus that makes it behave the same way as GZDoom when using Fluidsynth. I wrote this thread because I'm not sure whether I should do the same thing with the OPL2 emulator in Prboom-Plus; which is why I'm interested particularly in how it sounds on actual hardware.
  18. natt

    "Runworthiness" of the linuxdoom code?

    Let's not be too harsh; after all, at the end of the day, we got the source code to Doom.
  19. natt

    Another weapon in doom?

    meh http://imageshack.us/photo/my-images/11/doom04q.png/
  20. natt

    Pause key in PrBoom+

    Only when using SDL_mixer; otherwise it works fine.
  21. natt

    Texture pack error

    Your TEXTURE1 lump replaces the original TEXTURE1 lump. Every texture you use must be in it. Could you tell me more about the SlumpEd/XWE double shuffle?
  22. natt

    Texture pack error

    So I loaded up the texture pack with Doom2 MAP01, and saw HOM in the first room. Checked stdout.txt: bad texture 'PIPE4' in sidedef 9 bad texture 'PIPE4' in sidedef 9 bad texture 'PIPE4' in sidedef 11 ... Confirmed in map editor that the wall I was looking at was in fact supposed to have PIPE4 on it. Loaded the WAD into slade, and there's no PIPE4 texture. Loaded WAD into XWE, and there's no PIPE4 texture. Loaded WAD into hex editor, and there's no PIPE4 texture. There's a "PIPE4 1" texture though... smells like some sort of crappy string handling. What tool are you using to edit the textures?
  23. natt

    Chocolate Doom

    Not really a good test though. The way -timedemo works in prboom is like this: regardless of what speed the video is going at, the audio is still only rendering at realtime. So if you do a 10 minute demo in 1 minute, while 10 minutes of game engine and 10 minutes of video rendering were run, only 1 minute of audio rendering was run, so the audio will appear to take 1/10th of the relative CPU time that it would take if you were playing normally.
  24. natt

    Chocolate Doom

    The benefit is that you can connect any compliant midi device you have, including an advanced soundcard synth, external hardware devices, or oddball software synths. But for most users these days, system MIDI output means Microsoft GS Wavetable SW Synth and nothing else, in which case there's no real benefit at all.
  25. natt

    Bridge on Boom confuguration

    Then open boomedit.wad in an editor and see how they did it.
×