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

Zom-B

Members
  • Content count

    179
  • Joined

  • Last visited

Everything posted by Zom-B

  1. Zom-B

    Boom computer

    While I was reading about the Digi Comp II computer (more information), I thought I could make this kind of pinball-style logic with moving floors in Boom. I set myself a goal to make a similar computer with voodoo-dolls. Four days later, this is the result. Because I'm going away for 5 days first thing tomorrow, I'll upload my beta version. I started with copying the registers and counting logic from the Digi Comp II, but made up all the surrounding flow and decision logic myself. All consoles at the start area are interactive, and all use gunfire triggers. (could probably turn them into switches, because it was an old idea of having multiple action lines triggering at once (now replaced by separate program strips (look at the map to see what I mean)) but shooting is faster anyway) Main problems are that the voodoo doll becomes stuck sometimes at a corner or slanted line, because of the infamous DOOM clipping logic. If that happens, then please let me know which vertex is causing the blocking so I can fix it. (it will always be a vertex touching a corner of the doodoo-doll bounding box). Edit: here's the correct wad: http://www.mediafire.com/?93a1417vxhfgtde Some calculations can take a very long time (in the order of 20 minutes) so make good use of PrBoom's speed-up function.
  2. 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.
  3. 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.
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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
  9. 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)
  10. 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.
  11. Zom-B

    Doom Builder feature wishlist

    ^ That's what Slade is for
  12. 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.
  13. 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.
  14. 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
  15. 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?
  16. 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.
  17. Zom-B

    Boom computer

    I was thinking of implementing something like the Relay computer. It will use 8 bits data, 16 bits address (memory will theoretically be limited to 64k), and it has no video output. For these reasons it won't be able to run DOOM. But do you really want to emulate Doom within Boom? Remember Doom on a 386/25MHz ran at 5fps? We already have the proof that Boom is Turing complete, so we don't have to go to such lengths. It just means that given infinite space and time, and the [Boom engine] (without limitations like the 256kb block-map) it can theoretically emulate Doom.
  18. Zom-B

    Boom computer

    Even with this tool, I'd still need to write a program that can translate circuits to the wadc language. I could just as well program something that writes wads directly.
  19. Zom-B

    Boom computer

    It's already asynchronous. And faster than once per game tic? What are you thinking? That's like asking to travel faster than light speed. A game tic is a single update in game state. There's no way to update things twice in a single update. And uncapped framerate doesn't help, that just interpolates the view between the previous and current state. Even one update per tic is hard to reach (just like light speed is). With the current doll logic, the dolls need to be lifted over a ledge, then accelerated, then trigger a walk-over line. Each logic gate in my example has a propagation delay of 6 tics, and shoot buttons are 7 tics. So the entire duration of the adder is 7*6+7 = 49 tics. Assuming this is part of a larger CPU, and adding is the slowest operation, add some safety margin and overhead time and you have a 0.5Hz CPU. My BOOM allows me to accelerate about 700 times before it tops out, which makes it a 350Hz CPU. The 'virtual machine' slowdown is about 2.4GHz/350Hz = about 7,000,000
  20. Zom-B

    Boom computer

    Success! I implemented an 8-bit adder using binary logic. This proves that all primitive digital gates (AND/OR/INVERT) and gates consisting of those (flip-flops, memory) can be implemented in Boom. This opens the door to a real CPU in Boom. http://www.mediafire.com/?9tacawcwcx52tcc I designed a speed-optimized version of the Ripple-block carry look-ahead adder. This precalculates the carries in parallel so each digit doesn't have to wait for the previous digit (which would be very slow). For more information, see these links: The design: http://i56.tinypic.com/2iqjuqd.png Background information: http://www.aoki.ecei.tohoku.ac.jp/arith/mg/algorithm.html
  21. Zom-B

    Boom computer

    I experimented a bit with an OR-gate and NOR-gate, and failed to make an NAND gate. Then I was thinking how difficult it would be to make even an XOR gate. I started thinking from scratch again and thought that different types of signal might work. The previous gate worked with clocked pulse logic. After a clock signal, a doll means 1 and no doll means 0. I thought about how electronics work. A wire is either energized or not; there are no events. The next example uses toggle logic: A doll in one place means 1 and the same doll in another place means 0. I created a prototype AND gate and realized something very useful: the order of the 1 and 0 locations does not matter, so I can easily construct OR, NAND and NOR gates by just swapping tags around. http://www.mediafire.com/?l8vnwvlq4uazlw8 It is even faster than the previous logic style. In clocked pulse logic, when gates are chained, you need as much clock pulses as the longest chain of gates. In toggle logic, a change in input automatically cascades towards the end of the chain. (again, just like electronics)
  22. Zom-B

    Boom computer

    Prototype AND-gate with clock-input: http://www.mediafire.com/?kwx79v8z8xmbdb5
  23. Zom-B

    Boom computer

    Heh I figured my next step would be a programmable computer. It shouldn't be too difficult as I have experience in designing and building CPUs from scratch. It won't have floating point, smart pipelining or cache, though. For this to work, I just need to find a way to bring a single signal to multiple places, like in real electronics or the WireWorld cellular automata. I think I'll start out with a trigger line which releases multiple dolls, and work my way up from that.
  24. Zom-B

    Boom computer

    WHOOPS, wrong wad uploaded. confusing names. computer.wad != calculator.wad Here's the right one: http://www.mediafire.com/?93a1417vxhfgtde
  25. Zom-B

    Boom computer

    Added screenshots
×