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


  • Content count

  • Joined

  • Last visited

1 Follower

About natt

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. natt

    Modified prboom+ for producing videos

    When you use "portmidi", you're outputting to system midi, which can go to any of a number of devices that sound way different than each other, and I have no way of knowing which without more information. Without that, it's hard to say how you could make fluidsynth sound more like portmidi.
  2. natt

    Modified prboom+ for producing videos

    That is normal. There's no way to correctly capture (in sync and at the appropriate speed) system midi output, in general. There are loads of different soundfonts available that can make fluidsynth sound like many different things. What midi device are you playing to?
  3. natt

    PrBoom-Plus, ver.

    That's only if libpng isn't enabled. If libpng is enabled, the screenshots use the same code as the video capture. See write_png_palette() fill_buffer_hicolor() and screenshot_sdl() http://www.crowproductions.de/repos/prboom/branches/prboom-plus-24/prboom2/src/SDL/i_sshot.c They are where I got the code for the software surface readback for video capture. If there's something wrong with video capture, it's also wrong with (png) screenshots.
  4. natt

    PrBoom-Plus, ver.

    Interesting. The video dumping system uses the same code as the screenshot system to get its images, so I'm suspecting some bug in the screenshot system? Probably went unnoticed because one wouldn't normally take enough screenshots to notice something like this.
  5. natt

    PrBoom-Plus, ver.

    Best place to start with something like that is by checking the command output files:The console output from the various commands is redirected to file so you can see it for debugging purposes: cap_soundcommand: sound_stdout.txt sound_stderr.txt cap_videocommand: video_stdout.txt video_stderr.txt cap_muxcommand: mux_stdout.txt mux_stderr.txt If I recall correctly, the example ffmpeg commands were for the current ffmpeg version at the time which required you to use a libx264 presets system that may or may not work anymore. You should check "ffmpeg --help" for your particular version of ffmpeg to see if the commandline makes sense.
  6. natt

    strange spawning cube

    VERTICIES doesn't fit in 8 letters
  7. natt

    What CAN'T run Doom?

    I think that the GBA could handle a more "proper" port of doom, just not terribly quickly. The 16mhz arm is somewhat comparable to some of the 486's that acutally ran doom. The lack of ram is not a problem if you pre-bake the textures, since on a GBA you can have 32MB of ROM.
  8. natt

    PrBoom-Plus, ver.

    Do you have a soundfont by that name in the appropriate directory?
  9. natt

    Make a GPL fork of GZDoom?

    I found PortMidi easy to work with.
  10. natt

    "Runworthiness" of the linuxdoom code?

    A lot of the basic sync fixes are from early PrBoom, so you could look through changes in that for some tips.
  11. natt

    PrBoom-Plus, ver.

    If you're compiling from source, you need to run configure again (and then recompile) after getting the libs+dev packages. That being said, if OPL is what you want, you shouldn't need madplayer or dumb for that. What happens when you try to select midi player OPL?
  12. natt

    VGA Overscan/border

    In the context of analog and digital signals over VGA and DVI-D, what would you call those areas outside the active resolution but also outside the sync pulses? Wikipedia XFree86_Modeline calls them porches, and you can definitely see them on a modern CRT unless you overscan the active area. I agree with you that in the context of NTSC itself, porch may have a slightly different meaning, but the term was re-appropriated. Funny thing, I actually wrote a reply to that sort of question a few days ago. I can reproduce it for you here if you like =p
  13. natt

    VGA Overscan/border

    Correct. There is no underscan of the active image. Also, it's possible that modern video card hardware output forces black on the back porch no matter what. Even if it didn't, you most certainly would only get the correct effect in a vga compatibility mode, so only running the original game in DOS...
  14. natt

    VGA Overscan/border

    In general, hardware of the time put palette color 0 in the dead areas outside the active display but also outside hsync/vsync. As far as being intentional, it probably was. Even if not, they certainly saw it on their hardware of the time, and if they had wanted to remove it, it would have been a simple matter to simply fix color 0 in playpal. Edit: This is distinct from the effect that fraggle is describing.
  15. http://zdoom.org/wiki/License 1) Yes. Nothing particular in the licenses mandate that derived works you make with the code have to run Doom. 2) No. The Doom License forbids commercial gain. If you want to be able to sell your work, use a GPL port.