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

andrewj

Members
  • Content count

    2110
  • Joined

  • Last visited

About andrewj

  • Rank
    Senior Member

Recent Profile Visitors

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

  1. You know, something I just thought of... Is there a function within EPI endianess routines to convert from an Integer to unsigned short? I just realized...if I did that i could technically avoid having ROTT patches in their own struct entirely. . .keep the code tidier by just having everything in the base patch_t structure and that could potentially make it easier to handle those patches.

     

    Also, does EDGE explicitly require a pnames and/or TEXTURE1/2 for textures and patch displays? Since ROTT just displays patches directly, i wonder if even a lone dummy value would work..its either that or i would need to meticulously hand-roll one... I want to say EDGE has that capability but I could be wrong. .

    1. andrewj

      andrewj

      Sometimes a struct like patch_t is used to represent the exact (bit-for-bit) structure of the binary data in a lump or file.  So you cannot change, for example, a short to an int in that structure because the sizes are different (16 vs 32) and it won't read the binary data in the lump properly anymore.

       

      Other structs are used in memory, and it is less important if a field is a short or an int.  EDGE code does not make the distinction between these two usages very clear.  In Eureka and AJBSP, the file w_rawdef.h contains the structs for on-disk binary data, and they are only used to read/write the binary lumps, other structs are used for in-memory version (of a linedef, sector, etc).

       

      For example, raw_linedef_t is a struct for the raw (on-disk) representation of a DOOM linedef, and raw_hexen_linedef_t is the variant use in the Hexen map format.  These are converted to a single in-memory struct "linedef_t" by code which reads the LINEDEFS lump in maps.  This linedef_t has enough fields for both the DOOM version and the HEXEN version.  The types of fields can be "wider" too, e.g. the "flags" field in linedef_t is an "int" (32 bits) whereas the on-disk structure uses a 16-bit value (a "short").

       

      The EPI endianness conversion functions need to be a specific size, like 16 bits, since they need to work on the raw representation of binary data.  If you are reading the value into a different struct, you can have a wider type (like an "int"), but you don't need any extra endianness functions, in C and C++ integers of different widths are automatically converted.

       

      (will answer the other question later)

  2. The CREDS lump is out of date, says 70 skins.
  3. andrewj

    Maps for FreeDoom

    I don't think the intention here is to contribute to FreeDoom, these are simply maps you can play with FreeDoom.
  4. andrewj

    k8VaVoom: no good thing ever dies!

    That sounds like a reasonable approach. If I were you I would use plain text, omitting fields containing default values -- much nicer to debug. Quake did this (if I remember correctly).
  5. andrewj

    k8VaVoom: no good thing ever dies!

    I wouldn't bother trying to make a save format that is future proof. I spent a great effort doing that with EDGE (long ago), but consider it a waste of time now. ZDoom broke savegames all the time, and nobody stopped using it because of that, people will just finish their current game before upgrading.
  6. There are two possible ways it could be done: 1. use a method similar to Chocolote-Doom which is similar to the original DOOM networking, every client has to be in lock-step with every other client. This is doable, but it is only good for LAN play, very unsatisfactory for internet play. 2. use proper client/server networking like Quake, Odamex, ZDaemon, Zandronum (etc). It is very difficult to modify an existing engine for this, requiring major surgery to the code (which is why ZDoom and GZDoom never got it).
  7. andrewj

    k8VaVoom: no good thing ever dies!

    Ah I never knew about that function.
  8. andrewj

    Hall Of Mirrors going ape in Chocolate DooM

    I don't know about the DB plugin, but in Visplane Explorer (the program) you can see the drawseg numbers by pressing 'D' key, and go back to visplanes by pressing 'V' key.
  9. andrewj

    k8VaVoom: no good thing ever dies!

    I can answer that. In Windows, a program is either a console program or a GUI program. Console programs can print to the console, and GUI programs cannot. It is a really stupid system, but that is how it is.
  10. andrewj

    Could the CDI run Doom?

    The GameBoyAdvance has a 16.8 MHz 32-bit CPU and 256kbyte of RAM, and DOOM runs on that, so I reckon the CDi could handle it about as well as the GBA.
  11. andrewj

    k8VaVoom: no good thing ever dies!

    That is an impressive list of changes :) Function calls without parentheses seems a bit iffy to me, I remember QuakeC had some support for first-class functions (e.g. the th_pain stuff) so you need to differentiate a reference to a function from a function call. Anyway, happy hacking!
  12. andrewj

    Texture alignment conundrum with seg splits

    That sounds overly simplistic. The camera angle is almost never going to be *perfectly* perpendicular to a diagonal wall, but if it were, and the distance was right so that each column in a texture corresponding to 3 screen pixels (say), then I don't think you would see the right-most pixel being narrower than the rest. Rather I think it will be quite random which columns of the texture will be rendered wider or narrow than others. Especially when you add perspective into the mix, where the texture column is not a linear function of the on-screen X coordinate.
  13. andrewj

    Chocolate Doom Crash with no Error Message

    Yeah I forgot to use -merge instead of -file. Getting a crash (instead of an error) had me assuming something weird was happening. When I tried it properly, I couldn't reproduce your crash here. Running some checks on the map in Eureka shows that some sectors have a ceiling height lower than the floor. This situation can cause crashes in certain circumstances. Everything else seems fine. I also unpacked the wad using JeuTool and packed it back up again, with no issues reported.
  14. andrewj

    Chocolate Doom Crash with no Error Message

    I was trying to run this with an older version of Chocolate-Doom, but it crashes immediately, so I extracted the map into a separate wad and "fixed" all the unknown textures and flats, and THAT is the map that produced the high visplane counts (though I don't understand why there are more visplanes, perhaps because a different nodes builder was used). I'll try the map on the latest Chocolate-Doom (once I get it working on my machine). P.S. even the latest Chocolate-Doom crashes immediately here with your wad (when trying to start the map) -- so something is definitely wrong, perhaps with the textures (as the crash occurs in R_PrecacheLevel just after precaching textures).
  15. andrewj

    Chocolate Doom Crash with no Error Message

    I'm guessing visplane overflow, as Visplane Explorer shows that particular spot to be particularly high (around 137 visplanes). Not sure why it happens on weapon firing (though there is a flash when you fire guns, so perhaps that has some effect). Or why you didn't get a proper error.
×