• Content count

  • Joined

  • Last visited


  • Rank
    Senior Member

Recent Profile Visitors

634 profile views
  1. My cover photo is a content-aware scale photo of @Bashe with an overlay of the logo of the greatest cable company on the planet
  2. Because people prefer to do things a certain way that they like /thread If I prefer to release a map in UDMF and you have something negative to say because of the format I chose and not anything constructive about the content of the level, then I think your opinion should be discarded. If you're mapping exclusively for ZDoom, there's technically no reason to use anything but UDMF since it is objectively more feature-rich and [subjectively] easier to "wield" than Hexen or binary Doom format, but let's be real, who actually fucking cares
  3. Just chiming in to remind you that criticizing work is always beneficial if the criticism is properly substantiated and it's very bad practice to go around telling people you shouldn't criticize anything. Without criticism, the mod won't improve for people who want it to improve since all Captain Zimbabwe Infinity will hear on the subject is "this mod is perfect" Anyway, I don't like the new version in much the same way I have basically never liked Brutal Doom. I feel that, as with all previous versions I have played, the gameplay essentially boils down to an elaborate session of peekaboo and unfortunately this cannot be really addressed without addressing every single part of the mod, so in the interest of avoiding wasting any more of your time, I will leave my criticism at that barring anyone actually asking me to elaborate
  4. Ask people to give it a try if it seems like a game they would enjoy and if they don't like it then they don't like it I don't understand why this is a thread
  5. dude... too many dildos

  6. Considering the GBA version actually uses the Doom engine, it is objectively superior to the SNES port if we're talking strictly about how faithful the gameplay is, level simplifications notwithstanding Worth noting btw that GBA Doom 2 does not use the Doom engine (it uses a modified version of the Duke Nukem Advance engine)
  7. Here is a set of 3 midis I wrote that are free to be used if anyone would like to claim them for their maps. "A Lot to Learn" - maybe Watch Your Step or Dark Entries? "Animated Specter" - maybe Hectic but idk "Dream, Dream Eternal" - thinking this would work for one of the earlier maps but as with all 3 of these it's entirely up to the mappers' interpretation midis.zip
  8. Hey if you see this, could you get in touch with me?

  9. Database, decompiled C and ASM listing have been updated. Notable changes include some gameplay functions, lots of renderer functions, an early look at a bunch of stuff like LoadGame/SaveGame/LoadMap, and some deeper attempts at documenting some of the script functions. As promised, the map format: //The order in which things are loaded and thus the arrangement of data is like so: { maplump = CA_IndexLump(mapname, &shadowlibptr); fread(tilemapfloors, 2048, 1, shadowlibstream); fread(floorheight, 1024, 1, shadowlibstream); fread(tilemapceilings, 2048, 1, shadowlibstream); fread(ceilheight, 1024, 1, shadowlibstream); fread(tilemapwallsnorth, 2048, 1, shadowlibstream); fread(unknownwallnorthdata, 1024, 1, shadowlibstream); fread(tilemapwallswest, 2048, 1, shadowlibstream); fread(unknownwallwestdata, 1024, 1, shadowlibstream); fread(packeddoors, 1024, 1, shadowlibstream); fread(&unusedmapdata, 1024, 1, shadowlibstream); for ( i = 0; i < 1024; ++i ) *&tilemapunpackeddoors[2 * i] = packeddoors[i]; } /*Thus, this can be abstracted like so: floor = unsigned short[1024] floorheight = signed char[1024] ceiling = unsigned short[1024] ceilheight = signed char[1024] wallsnorth = unsigned short[1024] unk_walln = signed char[1024] wallswest = unsigned short[1024] unk_wallw = signed char[1024] door = signed char[1024] unused = (char)[1024] Doors are then "unpacked" into (probably) unsigned shorts in memory.*/ Note that while doors are indeed defined in some way in *.dor files, their placement on the level is strictly contained in the .map. Notably missing are cellobjects and tileevents. Cellobjects are almost 100% certainly in *.ojt files, whereas data related to tileevents could be in unk_walln/unk_wallw and are almost certainly in *.scr files. In addition, while memory is allocated and used for determining the height of a floor cell, no mechanism exists by which to make use of this data without visual glitches. That is to say you can set the floor height of a tile to whatever you want, but the engine has serious issues when you have areas of differing height like this. The feature was obviously not finished. Ceiling height changes are another story. You can have areas of different ceiling heights, but only in specific circumstances and some additional data is required somewhere to make "slopes". unk_walln/unk_wallw is possibly used here too, to define in what direction and height the renderer should draw the top edge of the texture. There may be a total of 23 doors placed in a *.map. There may be a total of 84 cellobjects placed. Exceeding these limits will crash the game because the arrays that hold the data for these structures is static in size. Tilecontent structures appear to indicate the presence of any of these elements in a cell, but the array that is written to to indicate the presence of tilecontent appears to hold significant values which I do not understand yet.
  10. Shadowcaster
  11. Intermediary update. I performed a cursory examination of many functions by tracing back calls to SC_Error(), a conjectural name given to a function called in many places to throw errors. Among interesting finds were an exact format for several map data structures, some of it known, some not. There is not yet enough known to make a complete map editor, namely the format of cellobjects is not completely known and there is still next to no documentation on scriptfuncs/scriptconditions. I will update later today with a basic map spec and an updated IDA database, C and assembly listings containing the new findings, including at least some examination, naming and type setup for every function that calls SC_Error(). Some good stuff in there like MaskDrawPic, DrawSubPic, MaskDrawSubPic, LoadGame, SaveGame, some functions related to Veste's morphing, HUD stuff, and more. Around 300 of the 1750 or so functions/subs in the executable will be touched in the update.
  12. Triple post, great. I updated the IDA database, listfile, and added a decompiled C listing (see RAVEN_list.zip). A lot of script functions were explored. A lot of them are reasonably sane and only one or two that I have seen actually tell the program to jump around in an unsafe way. More sound code was poked at, and there are now a bunch of early disassemblies of map functions including LoadMap(), which should prove helpful in making a map editor at some point. There is some kind of subsystem related to "tile content" that I do not yet understand, which is apparently different from tile events, scripts, items, et cetera.