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

SaladBadger

Members
  • Content count

    1475
  • Joined

  • Last visited

Posts posted by SaladBadger


  1. descent1palette.png.faaf361eb76858000bae2bd1bfd05af5.png

    defaultcolormap.png.9529d6218c5f784142be966b52767c4a.png

    Here's a palette I have some mixed feelings about. Descent 1. It feels like it could be so good, having a reasonably wide selection of ranges, but what's with the weird seemingly random contents of the first 3 rows? (it almost looks like it's generated from the colors used by the cockpit graphic). Two rows of grays, and then a varied selection of different colors. 2 purples, 2 blues, 3 greens, 3 yellows, two reds and an orange, and that kinda weird tanish color. The problem I see is that due to those 3 rows being wasted by the cockpit colors, many of the ranges get crunched pretty tight, leading to some messy fades in the colormap.

     

    Though for all it's faults, at least it's about 10x better than the highly redundant, unordered, machine generated palettes that plague Descent II:

    waterpal.png.6a7b942dea6744931dfd90198b943309.png

    The first 6 rows for all Descent 2 palettes are the same, but the color choices are so weird. Why is there no true grayscale range? Why are even the colors common across all palettes unordered and machine generated? Why is an almost entire row taken up by dark colors that are almost impossible to perceive? why does the water palette have so many colors that are basically black? The game probably would have looked tons better if more care was put into making the individual palettes.


  2. 10 hours ago, Urthar said:

    (Edit: Seems to work, but doesn't appear to support the updated models,

    Port support for the new models will be interesting, since they're using Doom 3's MD5 format instead of the original. I do hope some ports implement support for it.


  3. since ff2 has been brought up, I'll admit I've never ground the conventional way in that. In general my battle plan was to always beef up evasion with equipment and magic use, and simply avoid all damage rather than beef myself up to take it on. This strategy has worked wonderfully, though it does still involve grinding for spells like Blink, and it always comes as a shock to people when I show up to the last boss with half my team <1000 health. (I don't actually recommend that, though, it's resulted in some hairy fights) The GBA version automatically advances your health as you fight battles, though, so you'll usually end up with >1000 just by playing.


  4. I guess it depends on when you ask me. This video is 11 years old according to youtube, from back when I was a high school student. Free time wasn't in short supply during this time and I spent much of it playing games. I stumbled upon this by accident one time when playing ff6 for like the 10th time, and decided to see if I could pull it off since me from 11 years ago felt that was fun. I ground games like no tomorrow since I felt it was fun enough to fill that free time.

     

    Nowadays? I guess it depends on how invested I am in the game. Some RPGs are still fun enough that I like to build my characters to be as strong as they can be to get more out of it, but other things are eh. At some point, things like the novelty of grinding out all 31 IVs, maxed EV shiny pokemon has completely gone away for me.


  5. Decino did a vid recently about mancubus fireballs going through walls, which is pretty well known but something interesting I learned recently is that this wasn't always a problem. In the old press release beta, things were separated into distinct classes, with only players going through what would become the normal movement code that the release game uses. Projectiles used a much simpler physics model where they performed a line trace based on their velocity, and if that was unobstructed, they did a full move. So, excepting any bugs in the line trace code, of which there are many, projectiles should never be able to go through walls, and they also have the interesting trait of being infinitely thin.

     

    When every thing type was merged into the mobj type, I guess they decided it wasn't worth having special physics for projectiles and made them use the now normal movement code.


  6. 1 hour ago, Jayextee said:

    I'm halfway through Dissolution of Eternity and am sick to the back teeth of switching my weapon back to the one I had selected because the game decided to switch to the new weapon (or ammo for a previously-empty type) that I just grabbed. Can we get an option for that?

    Changing this at the engine level might be difficult since weapon switching is controlled entirely by the QuakeC code, but it does mean at the very least it can be done with a mod.


  7. Netflix feels like the first company that can make streaming games a reality since they already have a large enough fanbase to introduce to the concept, and this terrifies the living shit out of me. I already hate streaming enough due to the associated loss of ownership, and it's even worse with games for me. Please don't let this be the future of games, the present of games as a service is already bad enough.


  8. You know, when I look at my switch, the disappointment the new model is generating, and all of the weird shit Nintendo does, I can't comprehend why I love my switch, but it's the only console I've found any enjoyment in over the past many years. Anything more beefy I play on PC, the other consoles just don't hold my attention for whatever reason.

     

    But I don't really feel any strong motivation to pick up the new one. If it was a big upgrade like the hype stated (though I also don't understand why anyone thought the thing was going to be pulling 4K) maybe I'd be interested, but it's a small incremental upgrade that doesn't really appeal to me.


  9. Potential segment violations in cases like these are usually disguised by the zone allocator, which is why it generally doesn't crash. The patches are always in the zone heap, and unless in the exceptional circumstance that particular patch and that particular column is right at the end of the zone heap, it won't crash because in the eyes of the operating system, all the memory in the zone heap is fair game for your program.

     

    As for the actual bug here, I'm going to assume it's a rounding error, since frac is coming up negative, and I don't really think there's any reason for it to start negative when drawing columns for sprites and masked walls. Doom has some problems with them, where you'll see things like the lefts and rights of textures peek in on the opposite side even on perfectly sized and aligned walls.


  10. 19 hours ago, Bauul said:

     

    Discord have basically got the gamer segment all sewn up - they're the de-facto PC and mobile cross-platform choice for chat and voice, and with Sony planning on integrating them into PlayStation there's only so much more growing in the gaming segment they can do.

     

    The next steps are likely people beyond gaming.  They're looking at competing with companies like Zoom and Microsoft Teams (why do you think MS wanted to buy them?).  If you're going to start positioning yourself as a general purpose community service for professional as well as amateur users, having overly gamer-centric branding isn't going to be of much use.  The challenge was to create a rebranding that existing users still recognize, but new users don't instantly think "oh it's just for gamers". 

     

    This isn't about going after Discord rejectors, this is about setting the stage for going after completely different types of people in the next few years.

    I guess my confusion comes from... discord already felt that way? I think the most out-of-place element for it would be the wordmark, which used a relatively angular and sharp font, which yeah seems to clash a little with the theme, so I get why they changed it even if I think the new font is hideous. But the logo still looks like a game controller, even more so now, honestly.

     

    But beyond that, the old branding already was trying to target more than gaming. I found an archive of the website, which I haven't looked at in years (which I guess does give an impression how much any of this actually matters...). The old slogan was "Your place to talk", the description mentions it's your place to talk whether you're part of a "school club, gaming group, worldwide art community, or just a bunch of friends wanting to talk". All the rebranding did was take this description and reformat it to fit the new "Imagine a place" slogan, changed the wordmark (which makes sense as mentioned above), changed the logo (I understand their rationale), and changed the colors and art branding, which is where things start getting fuzzy to me on how much this would actually attract new users. The rest of the branding is basically the old branding, but reformatted some to fit a new slogan. But they have the usage stats and I don't, so maybe it's a resounding success.

     

    random edit: some people on the subreddit have noticed in a few places the old branding peeking back through again. Apparently for a while the google play page for discord was showing an alternate video with the new icongraphy and colors but with a new "your place to hang out" slogan, and there's a link hidden away on the website (a comma by the logo at the footer) that goes to an alternate home page with the "your place to talk" slogan. I wonder if this is just unfinished work, since there's a lot of rough places with the redesign where old elements show through, but who knows.


  11. the art style feels like that fake-feeling corporate art style, icon is weird, and I absolutely cannot for the life of me figure out what demographics they're attempting to target (presumably they want "all of them", but it feels too childish), but eh. After 4587569387 redesigns like this, it's kinda hard to get worked up. the amount of people complaining is nowhere near enough to get them to revert it, most people are probably just meh on the whole thing. 

     

    I am, however, super interested in how many people doing something like this actually gets on your platform. There's a lot of rebuttals to the redesign anger like "imagine wanting to leave a chat program over some colors and icons", but the intention of changing said icons and colors is to get more people on the platform. Is there someone out there that's going "heck yeah! I wasn't sure about discord, but now that they turned up the saturation and added a weird trumpet-shaped character to the login screen, I'm now absolutely enthralled with discord!" And if so, I really want to know who this person is.


  12. ah, I should have clarified, the chaingun is odd. It has a 9 frame firing sequence, which it always has to go through before it'll stop firing. If you're still holding the fire button by the point it gets to I think the fifth frame, it will start firing two bullets per frame. Hold it by the 10th frame (I need to double check these numbers myself, but I know the basic nature of this is accurate), it'll start firing 3 at a time. If you aren't holding down fire by the time it gets to these frames, it won't start firing multiple bullets and just use the 9 as expected.


  13. You're not incorrect with the firing rate thing, though the amount of bullets fired by the chaingun is (it just fires 3 at its top speed). Quake 2 ran at a staggeringly low 10hz tick rate (though the client ran faster and would interpolate), I think picked since that was the speed animations and monster thinking happened in Quake 1.

     

    The chaingun goes from firing one shot per tick (the same as the machinegun), to two, and ending at three as you hold down the fire button, with the client running multiple sounds to make it sound faster. Without such hacks, the fastest you can get is the machinegun or hyperblaster. (the mods with double speed firing powerups would usually run two weapon frames in one game frame, and then make spinning weapons look like crap thanks to the simple linear interpolation for models)


  14. The unity port has deathmatch, and explicitly introduced a new mode relatively recently which is like altdeath but makes weapons stay, long considered the one major weakness of altdeath rules. Maybe it doesn't on some platforms...

     

    Decino freely admits he isn't the best doom player. With regards to his recent No Chance run, he mentioned that UV play was explicitly reserved for the doom gods and mentioned a number of the players who took the credit for clearing that seemingly impossible challenge, and an 86 run death compilation certainly gives context for where he lies. He's a good and entertaining player, but I don't think we need to ascend him to godhood.


  15. For whatever it's worth, I had some time so I started cleaning up the code. There's a lot of super raw straight-from-the-decompiler-and-then-cleaned-up-to-function-but-not-very-pretty code in the thing, which was bothering me, so I went ahead and used the debugging information present in the executable to add accurate stack variable names where I can and also went ahead and changed while loops back to for loops when they were originally fors and so on. I've done this for the playsim only so far, but I want to do it to all the game's modules, and 0.5 is the only version where we can get such accurate information.

     

    One thing I'm a little on the fence about is whether or not I should heavily revise functions to match what they look like in the actual doom source. compare my version of EV_VerticalDoor with the one in the official Doom source release. The flow for things how it handles a door sector already having a thinker is somewhat different, and this can be noticed with a lot of these funcs. I kinda want to try reconstructing the source code as closely as possible, but it's a lot of work for little gain.

     

    I'm also still eyeballing getting this working with Open Watcom or a similar DOS compiler because I can't make this the "definitive" source because certain bugs would cause segfaults on modern operating systems if I kept them. Ah well, at least the gameplay logic and rendering seem accurate, accurate enough to run the original demos, for whatever it's worth. At least they desync in the same way as the original.


  16. WRT heretic being forked, while the engine code does mostly resemble 1.2, it's weirdly interesting to note that the texture mapper in heretic more strongly resembles the PRB one, using a large unrolled loop with a table of branches into it to draw less pixels, rather than the self modifying code that Doom itself uses. PRB's debug symbols explicitly mention linear.asm so it's probably the same source, just pruned of low detail drawers. I suspect id kept around a lot of the mode 13h stuff used in the PRB and the heretic source ended up making use of it.


  17. Have you gotten any of the pre-PRB versions in leloader working before? I worry some they might be tricky since the timer interrupt does a lot of work in them, such as collecting user input and advancing playercmdframe. I suspect that's all emulatable with some work, but it makes things trickier


  18. That was my assumption for a while, but I eventually realized I wouldn't get sane values at all unless I always masked out the highest bit. Like I had my program set to ignore any values where it was set and then nothing loaded at all... At the moment I'm just throwing out the first table because I can't make heads or tails of why the values are the way they are. Everything else seems to work so far, I'm analyzing a relocated flat binary right now in ghidra and there's no obvious issues.. I'll compare the output against your DosBox capture and see if I can determine where anomalies are rising. 

     

    edit jesus i'm a fucking idiot the anomalous values were coming from the FPU emulator executable, which I process for... some reason? (actually I started processing it just to ensure my assumptions are correct) everything is fine please proceed as normal. Don't do this when you're running on no sleep, I guess is my moral of tonight.

     

    and yeah, with these changes, I mostly match the dump. There's some exceptions, since the C CRT and the like have started up at the time of your dump, some values in memory have changed, but my relocated values in the code data all seem to match.

     

    Here's my version of MTLoad for the night. It will generate a simple address map when there is sufficient information, and you can now specify a base address with the -b command line parameter.

    MTLoad.zip


  19. Ah heh, I had missed that since I've been buried in my output. I resolved the issue of the missing texture mappers, I was just being dense. The texture mapper fixups are present in the table with the offset value of 1, but they appear before the function fixups, creating a discontinuity. For now, I'm trying to apply values while ignoring the flagged entries because I don't get them. They're there so they probably have a meaning, but I can't comprehend what it is yet.


  20. thank you so much for the research xttl. The lowest fixup records are giving me confusing results, usually not directly aligning with a memory access, but later ones seem to start being more sensible. Against my 0-based flat executable, I'll see a record against 000079A7 and then I poke at 000079A5 in ghidra and there's a cmp ebx, dword ptr [#0003a1d0] (3b 1d d0 a1 03 00) which corresponds directly. I'll get fixup support implemented tonight, and hopefully I can dump my new sources with the MAP generator and fixup support added tomorrow.

     

    One minor issue I'm still yet to track down is that the texture mapping function tables (the alpha texture mappers in all builds I've studied is much like the heretic one, essentially using a huge unrolled loop with jumps into it depending on how many pixels need to be drawn. I think it evolved directly into the heretic one actually, from my work with 0.5) don't appear to show up in the information, but I may just be being dense parsing my own output. The ASM texture mappers seem slightly enigmatic to me since they don't register in the symbol tables at all, but I'm sure I'm just missing something obvious.

     

    edit: I think the second value is just an offset applied to the values, kinda. The first int16 is the amount of records, the second is added to the read values * 32768. This has had successful effects for me. I'm now really curious what the highest bit of the records indicate.

     

    edit (god here we go again) 2: Something definitely is fishy with the values that have the high bit set, masking out the highest bit doesn't seem to create coherent values. All without the high bit set correspond directly to memory addresses in the code. I'll spend a little more time analyzing it.


  21. Oh, the debug information being offset to the beginning of the MT would explain why all the values were so confusing, now it suddenly makes a lot more sense. I was exploring some of the sub-tables. The first just seems to be basic information, the second seems to be type information, with structure dumps, and the third seems to be the delicious symbol data, containing information on all functions, their stack variables, and heap values and their offsets. I've been working on figuring out this format, and I can extract stack values from it at the moment, but I need to validate that I understood things properly still.

     

    Each entry has a header defining the offset in memory where the heap variables will be loaded, as well as it's name. There's some other bits in there I'm still figuring out. Heap symbols always seem to start with a 0x05, followed by a 4-byte value which defines the offset from the offset specified in the header. Following that is two unknown bytes. My guess is that the first or possibly both define type information, as they seem equal across things with the same type (ie: it's 0x14 for all the s_ variables that define monster states, but different for something that isn't a s_ variable.). Following the two bytes, there's one byte that contains the length of the symbol string, followed of course by the symbol chars.

     

    I'll explore this more today and work on getting extracting this information working in my MT load program.

     

    Edit: Having some good success here. A couple of my assumptions were wrong, but I've been able to correct them and get something that works. Here's the first 100 symbol table entries as reported by my MTLoad: https://pastebin.com/04BTSKu1

     

    Edit 2: Okay, yeah, some tweaks later, it loads the entire thing just fine (loading from pointer 2 in the table to pointer 3). The symbol information is basically a table of "commands", here's what I determined:

    Command identifiers are specified by a single byte, followed by the payload. Here's the payloads:
    All strings are an array of char, with the length specified by a preceding byte. "String" will be encoded as 06 53 74 72 69 6E 67 
    
    cmd 0: Defines module
    int32_t codesize; //Size of code in bytes
    int32_t codestart; //Offset of the code
    str name;
    
    cmd 1: Defines function
    int32_t offset; //Absolute offset from the base address
    int16_t typeid; //Type id of return type, I think
    int8_t b1: //unknown
    int32_t stacksize; //assumption
    int32_t dw1; //unknwon
    str name;
    
    cmd 2: Ends block. No payload. After a function or module. 
    
    cmd 3: Specifies that following variables are relative to the specified offset.
    int32_t offset;
    
    cmd 4: Specifies that following variables are relative to the stack, or something like that. Used for parameters.
    
    cmd 5: Variable. Can be relative to the stack or a heap pointer from the previous two commands
    int32_t offset;
    int16_t typeid;
    str name;
    
    cmd 15: Unknown. Usually before heap variables
    int8_t b1; //always 0 in Doom 0.2, I think
    
    cmd 23: Unknown. Usually before heap variables
    int8_t b1; //always 0 in Doom 0.2, I think
    
    cmd 64: Register variable. Can be used for args, but args are always passed by stack. Args specified this way appear to be MOVed into a register at the start.
    int8_t b1; //Probably identifies the register
    int16_t typeid; 
    str name;

    I'm not 100% sure I can create a coherent .MAP file, mostly due to the weird sectioning scheme compared to other executable formats like PE. Creating IDC should work, if there's some documentation on how it works. But creating some sort of table to get absolute addresses in memory should absolutely be possible.

     

    edit 3: Actually looking at the heretic/hexen .MAPs it shouldn't be impossible, but lacking any further information about how things go I'm kinda forced to just give everything the same selector. It's not really a big deal, I think? But it looks strange. So far as I can tell, the memory bits in the executable have absolutely no way of distinguishing between TEXT and DATA sections, everything's.. just.. memory... There's nothing that even resembles a BSS section, beyond the bit in the header that specifies how large the program's address space is.

     

    ah, let's just try this for now. I just gave all heap vars a selector of 0001 for now. Why not... It should be functional though, and it's been helpful for my own use.


  22. Segmented would be a little weird for a 32-bit program (32-bit x86 programs are segmented via a much different scheme), but I'm really not sure. The only thing I see in the fixup table is a pile of increasing 16-bit numbers that eventually wrap over at some point. It doesn't correspond to fixup records I've seen in other executables, but at the same time I've never pursued it too closely. I need to study things closer.

×