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

saxman

Members
  • Content count

    17
  • Joined

  • Last visited

About saxman

  • Rank
    Warming Up

Recent Profile Visitors

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

  1. saxman

    DOOM 32X WAD Converter

    Here's something to make porting maps to the 32X MUCH easier (effortless in many cases): http://www.4shared.com/file/200725236/6bc239e4/d2conv_32x.html It's a response file for D2CONV. If you don't have D2CONV, I have uploaded a copy of it here: http://www.4shared.com/file/200725078/eb920589/dm2cnv32.html Just run D2CONV from the command prompt using the following arguments: "D2CONV.EXE [in file] [out file] @32x.txt" Obviously, you should replace "in file" and "out file" with the appropriate file names. My response file will change any unsupported thing numbers to those that are supported by DOOM 32X. It also changes any unavailable floor textures to those used by DOOM 32X. Sector types 11 and 17 are changed too since they're not supported. What my response file does NOT do is modify linedef types or wall textures. These do not cause DOOM 32X to crash in any way. Unavailable wall textures are changed to ASH01 automatically by DOOM 32X. Unsupported linedef types may be a problem in certain maps (e.g. fast opening/closing doors don't function in DOOM 32X.) The response file can always be improved. If you want to add to it, feel free to do so.
  2. saxman

    DOOM 32X WAD Converter

    Version 1.10 is now available -- http://www.4shared.com/file/198175058/d230...wad32x_110.html I am not expecting to have any newer releases unless something major changes, like supporting Genesis-native 4bpp graphics editing or something like that. Until then, here's what's new with this latest release: This release was aimed at trying to make both imports and exports look correctly when played. For example, the ASH01 texture actually shows in 32X maps played through the PC version of DOOM now, and likewise, walls with incorrect texture names will now display ASH01 (as they should) in the 32X port since texture names are now sorted in ABC order. COLORMAP conversions now work, so you don't have to delete that lump when playing the 32X data through the PC port. My program's isn't designed to be perfect, but it is designed to try and make porting data back and forth as painless as possible. This version also imports WAD exports from v0.99 and v1.00 of my program using the _32X_ lump as a way to guide it to ensuring backwards compatibility. This isn't a major release, but I felt it was worth making as I feel these were some vital issues that needed to be solved. And as with the previous release, the source code to this version is included in the zip file.
  3. saxman

    DOOM 32X WAD Converter

    That would be quite neat, and could allow hacking the ROM to be easier if people can insert lumps instead of learning how to use a hex editor. Also... http://www.4shared.com/file/192955239/c20aafd2/DOOM_Spinball.html Just for fun to see if it would work -- Sonic Spinball music in DOOM! It wasn't a hard hack, it was all a matter of knowing the addresses (which I got from a post Mikel made back at Sonic Retro.) And for those who haven't seen this -- http://forums.sonicretro.org/index.php?showtopic=18892&hl=GEMS It's information on the GEMS driver. This of course could open the door to making better music for DOOM.
  4. saxman

    DOOM 32X WAD Converter

    I did lots of that kind of stuff with 16-bit Sonic games years ago, before the Sonic the Hedgehog 2 disassembly was created. If you know enough about what certain parts of the code are doing, you can branch to new sections of code that you append to the end of the ROM and start writing brand new code. It's a round-about way of reprogramming things without dealing with size limitations. Though it would be limited to machine code without some tool to make it do otherwise, it could very well make porting new monsters possible. It's especially helpful that there's a DOOM source code to look at. All we need to do is figure out how DOOM 32X handles the other monsters, and then use that as a template for creating new ones. Of course I make this sound easy -- we're probably a couple years away from doing that realistically. With the Sonic games, I had already been hacking those for several years and understood most of the inner workings of the code.
  5. saxman

    DOOM 32X WAD Converter

    Again, not related to my program, but since it's the subject of some discussion, and because I said I would, here are some updated notes: http://www.4shared.com/file/188795040/6033867e/doom32x_notes.html I added several things about the music in there.
  6. saxman

    DOOM 32X WAD Converter

    I know where the entire list of voices is located, as well as the sequence data for each song. I don't have my notes with me at this time, but I'll post them next time I'm around. Each voice in the ROM is made up of 41 bytes. I haven't even attempted to figure out what registers are affected by these bytes. I'm more concerned with the sequence data myself as it appears to make use of macros (probably to cut down on size and repeating of data.) I'll post more on this as I get it, along with the addresses to all these things.
  7. saxman

    DOOM 32X WAD Converter

    Minor update to the WAD converter -- http://www.4shared.com/file/190290264/cebadbf3/wad32x_100.html Version 1.00 features checksum and ROM size corrections to ensure it will work on real hardware. If the file is bigger than 4MB, it will still save, but will warn you about the size. This update should solve any issues people have had with not being able to get their imports working in an emulator. Also included is the source code
  8. saxman

    DOOM 32X WAD Converter

    The YM2612 is an OPN2 chip. It's actually two YM2203's in one, with the added ability to replace channel 6 with DAC. It's very closely related to the Yamaha DX/TX family of FM synthesizers. It's on the lower end of the scale in terms of quality and abilities, but it is definitely capable of doing better music than DOOM 32X. Just download "Sonic Boom" to hear the Duke Nukem 3D theme song playing -- it sounds just like it would on a PC! So it seems to me that they just weren't all that concerned with the quality of the music when they ported DOOM to the 32X.
  9. saxman

    DOOM 32X WAD Converter

    This is unrelated to my utility, but I thought this was interesting: http://www.4shared.com/file/189525118/8e320b90/D32X_music.html Just a little experiment with music. Each level is given it's own song. The reason for this is I discovered some unused tracks in the ROM. Level 10 -- Title Level 11 -- Victory Level 12 -- Intermission (version 1) Level 13 -- Intermission (version 2) The two intermission tunes get layered together in the game. Level 14 does that. Also, the playlist found in the ROM has 21 entries (excluding the zero entry which is there only because level "1" is the first level, not level 0.) If you exclude the two Jag-specific maps and MAP20 which crashes the game, that would make 21 maps. That's me speculating a bit, but it appears the 32X version was going to have 21 levels. Also, on the note about accessing more levels, if you know how to use a hex editor, change the word at 0x000E74 to anything you'd like. This is certain to work in the EU ROM, but the NTSC ROM may have a different address. As for indicating what level is the secret level, last level, etc... I'm not sure about it yet. I'm recently finding that for some reason when I try to enter the secret level from level 3, it's taking me to level 4 (is there something about this I'm forgetting???)
  10. saxman

    DOOM 32X WAD Converter

    http://www.4shared.com/file/188740341/da3c3c32/DEH32X_010.html DOOM 32X DeHackEd Patcher v0.10 It will import thing information from a DEH file. I can't guarantee it works perfectly the way it should as I have given it very limited testing. I know the "width" and "height" may be issues, as well as "speed" on certain things. Help me test it out and let me know what works, what doesn't, and so on. I also included a sample DEH file that modifies a couple enemies.
  11. saxman

    DOOM 32X WAD Converter

    Here's an image of a Chex Quest port in progress from True Dude over at Sonic Retro: http://img686.imageshack.us/img686/275/chexquestlvl1.png Also, for those interested, I'm working on a DeHackEd patcher for 32X DOOM.
  12. saxman

    DOOM 32X WAD Converter

    Oh I forgot about my GMail account. I checked it, and it's there. I'll send you a message when I have some info on the crash.
  13. saxman

    DOOM 32X WAD Converter

    ... I haven't gotten anything. Are you sure you sent it to the right person?
  14. saxman

    DOOM 32X WAD Converter

    If you send me your WAD file, I'll see what's going on that's making the program crash.
  15. saxman

    DOOM 32X WAD Converter

    The MSB in the first character of a lump names tells the game if compression is used or not. If the bit is on, then compression is applied. The size of the data defined in the WAD is it's size after being decompressed. Someone else asked me about this too, so I'm going to copy/paste what I wrote on how to read the compression: You have a byte I like to call the "key." Each bit in the key represents the data that follows it. If a bit is 0, a direct copy is used (no compression.) If the bit is a 1, then at the location the bit represents, a word will be read which tells the decompressor how far to look back to find data, and how many bytes to copy. The upper 12 bits tells the decompressor how far to look backward that number of bytes, plus 1. The lower 4 tells the decompressor how many bytes to copy, plus 1. The bits in the key are read in order from LSB to MSB. When the key has been completely read, a new key will start. To end a file, you use a 1 in the key and use 0x0000 for the word. Also, lumps should be aligned in 32-bit intervals. So, if a file ends at say 0x12345, then you place dummy bytes at 0x12345, 0x12346, and 0x12347. The next lump will start at 0x12348. And that's all there really is to it. That's not to say the lump data hasn't been changed in formatting though. I had to read the sprites differently in the 32X WAD than I would have to in a PC WAD, but that's getting ahead of things. I'll be releasing the source code to my utility which will show everything that is done in the conversion process.
×