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

Zom-B

Members
  • Content count

    179
  • Joined

  • Last visited

About Zom-B

  • Rank
    Junior Member

Recent Profile Visitors

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

  1. Zom-B

    Slade 3.1.0 released

    In 3.1.0 Beta 6 Whenever I start it, it asks me for the temp folder, resources and node builder. It remembers the resources so there I only have to click OK. It forgets all other settings, also settings found in the preferences, and even settings in some dialoga that I expect it to remember (like the last game configuration in map editor launcher). When I tried to open a map using an extra resource pwad, it froze with 100% cpu.
  2. Zom-B

    Boom computer

    https://dl.dropboxusercontent.com/.../boombomputerfiles.zip This excludes the Java files used to generate logic maps from a template file. Reason for this is that I updated the WAD loader/saver and that broke things. I'll look into that in the near future. [Edit] I dumped even more stuff in the zip file. I don't know if everything works though. btw, .circ files are for Logisim.
  3. Zom-B

    Doombuilder 3d mode problem

    I've had the same problem for over 2 years now, and I run servers so I can't shutdown or even interrupt windows. My jerkiness is so bad each step takes a second. Windows has been running for almost 7 months straight. I'm using r1553 and the problem still persists. It is a bit random for me though. I've had two cases (out of many dozens) where I started DB2 and the 3D mode wasn't jerky at all but perfectly smooth, but right after I play-tested the map it became jerky again. I'll try the GL mode now. [Edit] Tried it, and the 3D mode is smooth now. I had to manually copy my old game configurations. However, the interface itself is very slow. Every time I do some action involving files (starting, choosing different game configuration, loading wad, changing resources), it freezes for a couple seconds, and at non-classic mode changes it seems to save the entire map to my temp folder (seen in the log) for no apparent reason causing severe freeze. Furthermore, some plugins, like Nodes Viewer and Visplane Explorer crash GLDB immediately. I tried disabling all plugins, but that way, whenever I load a map, it just comes up with a black area, not even a grid, and the freezing still persists. [edit2] It seems BuilderModes is a required plugin in GZDB
  4. Zom-B

    DB2 3D Mode is not smooth

    In continuation of locked thread http://www.doomworld.com/vb/showthread.php?threadid=54161 I always keep my pc on because I run servers, so I also got severe slowdown in the visual mode. I thought I already reported this problem 2 years ago but can't find it. My framerate steprate is typically 1 fps and one 'step' of walking is more than 500 doom units. Very irritating. I also noticed there were at least 2 official releases after you, Pascal, learned of this problem, and it's still not fixed. But here's the strange thing: I noticed that about 5% of the times when I start DB2, it's perfectly smooth! It's completely random when this happens though. Even when it's smooth and I playtest the wad, it's not smooth anymore afterwards. Maybe this hint will help you fix it.
  5. Zom-B

    Doom Builder feature wishlist

    ^ Again, Slade. Doom builder is a MAP editor, so it is only concerned with map-specific lumps. Any lump that is global to the wad file should be edited by slade. If Slade cannot do this (yet) then go ask in Slade's thread.
  6. Zom-B

    SLADE v3.0.2

    I could even give you some source code of how to 'convert' the spline style Ultra Fractal 'gradients' to 256-point palettes, if you like, which I painstakingly reverse-engineered from looking at the spline behavior.
  7. Zom-B

    SLADE v3.0.2

    Nice that a new version is released, but I can only find 3.0.2 on the slade website, which I already have. Here are JASC palettes some saved with PSP 5.0: http://www.mediafire.com/file/7nzet1bb2zd0g1a/rgb232.pal http://www.mediafire.com/file/fk7oz6vkzauo3vi/dos256.pal http://www.mediafire.com/file/trna6d3q8wndjck/dos16.pal The last one has 16 entries, so I expect that sould give an error. I also have Fractint palettes, which was a popular fractal generator before the time of Ultra Fractal: http://www.mediafire.com/file/5r61y82vmvam8j2/chroma.map
  8. Zom-B

    Boom computer

    I finished my wad compiler to generate boom-logic maps from simple scripts. The input is a so-called boom-logic script with commands resembling the following: A & B C This reads, A is the result of the AND function of B and C, where A, B and C will automatically be mapped to tags. Here are some example wads: Test map Adder Subtractor Program Counter (PC) The Test map contains some basic gates wired directly to the user inputs/outputs. What which bit does is visible on the map (except one, the output of a flip-flop). For the Program Counter wad, you better note the following on a piece of paper: B0 (green 1) = ~Clock (increment on on-to-off transition) B1 (green 2) = Load (loads number A) B2 (green 4) = Reset (go to zero) For those interested in the complete logic description behind these maps, here is a zip with the scripts: zip (does not contain the compiler)
  9. Zom-B

    Slaughterfest 2011

    I haven't been following lately because I'm busy with other projects like the Boom computer, and lots of IRL projects. I'm just dropping by to say a few things. I won't be able to make a Crest of Simplicity, Part 1, so when the wad will be built, you can just leave out Part 2. I made MAP01 just as a joke, not to be actually included. I don't even know if it's allowed as I copied the map architecture unaltered, and only altered the things. If you decide to include it after all, I won't mind it getting spot 31 or 32 as those are the spots most megawads place their joke wads in. If those are already claimed then I don't mind any other spot or not being included at all.
  10. Zom-B

    Doom Builder feature wishlist

    ^ That's what Slade is for
  11. Zom-B

    SLADE v3.0.2

    I found a bunch of other bugs in the TEXTUREx parser. All files involved: no_bug.wad (just Doom2 1.9's TEXTURE1 and PNAMES lumps) bug1.wad (changed from no_bug.wad) bug2.wad (changed from no_bug.wad) bug2.wad (changed from no_bug.wad) bug4.wad (original, saved with faulty algorithm) fixed.wad (same origin as bug4.wad, but saved with good algorithm) Bug #1 When the length of the TEXTURE1 lump in the WAD directory is recorded wrong, smaller than actual, the Texture Editor tab will be missing the TEXTURE1 tab, and a corrupteed gui element is visible in the upper-left corner of the pane: How to reproduce: 1. Open no_bug.wad in a hex editor 2. find the string TEXTURE1 (address 0x61C4) 3. go back 4 bytes (address 0x61C0 in no_bug.wad) 4. change the 32-bit little-endian integer to a lower one (default: 0x00005304, change to eg. 0x00005000) 5. save (bug1.wad) 6. open in slade 7. open TEXTURE1 in the Texture Editor 8. Corrupt panel is visible without the TEXTURE1 tab. Bug #2 - #4: When the header of the TEXTURE1 lump is corrupt, one of three bugs can happen. See: http://doomwiki.org/wiki/TEXTURE1_and_TEXTURE2 How to reproduce bug #2: 1. Open no_bug.wad in a hex editor 2. change the numtextures entry (address 0x0C) to a number higher than original (eg. 0x00004321) 3. save (bug2.wad) 4. open in slade 5. open TEXTURE1 in the Texture Editor 6. the Texture Editor panel flashes real quick and disappears before you notice it. How to reproduce bug #3: 1. Open no_bug.wad in a hex editor 2. change the first offset entry (address 0x10) to a number higher than original, and which is not the start of an actual maptexture_t entry (eg. 0x00003333) 3. save (bug3.wad) 4. open in slade 5. open TEXTURE1 in the Texture Editor 6. Same effect as Bug #1 happens How to reproduce bug #4: 1. I don't know how it's corrupt, so just open bug4.wad in slade 2. open TEXTURE1 in the Texture Editor 3. note that it erroneously detected the "Nameless (Doom Alpha)" format. 4. Whenever you click a texture in the list, it crashes the app.
  12. Zom-B

    SLADE v3.0.2

    Sorry, I didn't see this reply before. The steps are just like that. If you are unsure of any steps, ask me. 1. Make a PNG file, 2. add it to a texture wad, 3. add the texture to the PNAMES lump, 4. rename the texture, 5. rename the PNAMES entry of the texture, 6. change the PNG file, 7. add it to the texture wad again (there are two different textures now), 8. add to PNAMES, 9. go to the TEXTURE# editor 10. note that both PNAMES entries show the same image, even though they are different. Saving the WAD and restarting SLADE resolves it.
  13. Zom-B

    Doom Builder feature wishlist

    I finally got my finger around one of the bugs (ie. reproduce). It's a different crash than the ones in the post above, though. It triggers when you use "Edit Selection mode" on two or more connected sectors, where at least one of the sectors has zero area. I submitted it here: http://www.doombuilder.com/forums/viewtopic.php?f=7&t=545
  14. Zom-B

    Boom computer

    Considering that in the 70s Pong was the benchmark for real computers, I can imagine that in the 2050s Doom will be the benchmark of virtual computers, but virtual in which future system? and what future game will be the benchmark of real future computers, that emulates doom in real-time?
  15. Zom-B

    Boom computer

    I'm thinking pong might be a nice goal. A display can be made with the 'Light to 0/255' specials, but it will be a floor display like a disco floor.. A vertical display made from shutters will definitely look bad/distorted from any angle. A 16x16 pixel display (like the original pong) will cover about 1sq foot floor space with 1x1 unit sectors, for minimum distortion. I've also looked into replicating the 6502/7 but that would consume about 50-80% of the usable map space (blockmap limit). It wouldn't leave much room for memory and motherboard logic. The processor also contains a lot of things like bulky instruction decoder ROMs and interrupt logic, which aren't technically needed. I've been studying on different architectures. Most architectures optimize on different practical things, like number of transistors, memory bandwidth vs ALU bandwidth, wire length/thickness, fan-in and fan-out (how much transistors a single transistor can drive) and power consumption. Most of these 'limitations' are not necessary for Doom. For example, a 'wire' is just an agreeing tag between trigger lines and sectors, so distance and fan-out don't mean anything anymore. This very fact already helped me make a more efficient adder than normally possible. There are some architectures that will be impractical in real electronics, but will be very useful in the Doom universe. One of those is the use of ALU registers. A dozen or so memory locations don't actually exist, but when read, you get a value that is a function of one or more other registers, like the arithmetic and logic operations. A final register contains the program counter, and a write to that register makes a program jump.
×