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

xttl

Members
  • Content count

    342
  • Joined

  • Last visited

6 Followers

About xttl

  • Rank
    Member

Recent Profile Visitors

1200 profile views
  1. xttl

    Crispy Doom 5.10.0 (Update: Jan 12, 2021)

    It looks like on the Doom side P_GiveWeapon in p_inter.c was modified to print weapon pickup messages using a new string pointer array: WeaponPickupMessages (to make the messages visible in multiplayer modes where weapons stay). The same array is also reused for printing messages in the give/take weapon cheat. Crispy Heretic does not have this feature. If I make this modification (show weapon pickup msgs in netgames) to p_inter.c, it is not a strictly cheatcode related change, but it *is* a good change which should be made at some point anyway (though in Heretic only affects cooperative because old-style deathmatch is missing... which in itself might be another good future addition), and it makes sense to use the same array for this and the cheatcode. So I created a pull request just for this first on github now.
  2. xttl

    Crispy Doom 5.10.0 (Update: Jan 12, 2021)

    Yeah, I noticed it compiles just fine (just not built by default) which is how I also noticed it has working hires support (by compiling and running it). :P I created an account on github now. I could actually port all the new cheat codes from Crispy Doom to Heretic while I'm at it. I forked the repo and cloned it locally, next I should create a new branch (called eg. heretic_cheatcodes), make my changes there (only the cheat related ones) and then submit a pull request to you, right? I didn't even know about this Doom source port before. I'll check it out.
  3. xttl

    Crispy Doom 5.10.0 (Update: Jan 12, 2021)

    I have about zero previous experience using git and github other than git cloning a repo to build something locally, but I can try. :P I also attached a diff of the changes so far in the previous post. Btw. is something like support from loading maps directly from PSXDOOM CD images or extracted data files (while still using the PC IWAD for everything except textures and maps) out of the scope or too hacky for Crispy Doom? Those could benefit a lot from the truecolor renderer, they have partially transparent textures and coloured sector lighting. (also everyone please don't take this as a promise to definitely code something like that, I'm just asking to make sure it wouldn't become wasted effort in case) Also, what's the status of Crispy Hexen, is it discontinued / not maintained anymore? Seems it's not even built by default and has no "crispness" menu, but still features working hires mode. I might be interested in fixing widescreen support in it too.
  4. xttl

    Crispy Doom 5.10.0 (Update: Jan 12, 2021)

    I'm trying to add widescreen to Crispy Heretic. It was really easy (<30mins job) to get sprites and walls (ie. everything drawn as columns) working properly by copying a bit of code from the Doom side, but flats (spans) have serious distortion I've yet to figure out how to fix. Any tips, @fabian? Okay, I was looking in the wrong places, I just adapted/copied the "accuracy improved" R_MapPlane code from Crispy Doom and it seems to be working fine in-game now with screenblocks==11. Then I need to catch and fix all the HUD, intermission, etc. stuff that needs fixing. Current status: automap and page drawing (titlepic, etc.) are still broken but otherwise everything (game view, HUD, intermissions, etc.) seems to be working. I need some rest right now, however. I also ported the notarget cheat from Crispy Doom because I like it. Just before posting this I noticed the top border is not always drawn correctly in hires mode for all reduced screen sizes, but it happens in Crispy Hexen too (which I haven't touched at all) so seems it's not caused by my changes. Attachments include source diff and a Windows binary. Binary was built with MSVC (2015) so it may have some hidden problems. The PACKED_STRUCT macro that's apparently supposed to handily pack certain structs on both GCC and MSVC didn't work at all for me (caused zillions of <class-head> errors), so I removed it completely and compiled with /Zp1. This change is omitted from the source diffs since it is not necessary for GCC builds. I also couldn't get libsamplerate to work at all without crashing (perhaps because it's *not* been compiled with /Zp1? SDL still works...) so use_libsamplerate is disabled. Compiling on not Windows should be very straightforward (at least was for me) but don't --enable-truecolor when you compile it, that currently breaks Heretic completely. crispy_wide_tic_srcdiff.zip crispy_wide_tic_bin.7z
  5. xttl

    Crispy Doom 5.10.0 (Update: Jan 12, 2021)

    It seems some stray invisible characters slipped into the doom/r_draw.c changes :-) and so on for lines 436, 503, ... After removing those it compiled fine. I think the initial screen wipe in widescreen mode could be fixed by simply checking for st_firsttime in st_stuff.c line 485, ie. this if ((SCREENWIDTH >> crispy->hires) != ST_WIDTH) becomes if (((SCREENWIDTH >> crispy->hires) != ST_WIDTH) && !st_firsttime) edit: unfortunately not, if using Unity WAD's widescreen status bar it is still broken. But adding a check for st_firsttime to the beginning of ST_refreshBackground does work with both regular and widescreen STBAR, ie. if (st_classicstatusbar || force) becomes if ((st_classicstatusbar || force) && !st_firsttime) not sure if it's the best solution though.
  6. xttl

    Crispy Doom 5.10.0 (Update: Jan 12, 2021)

    I don't have much of an opinion on the transparencies because I've generally always disabled them in all ports except when playing maps or mods I know to use them (so mostly ZDoom/GZDoom-exclusive stuff which I only play occasionally, with the odd Boom map that actually uses transparencies). From what little I looked at it now, yes, in general the transparent items look better (at least more consistent). It seems Crispy Doom already didn't have the worst transparencies in 8-bit mode anyway, compared to old autogenerated Boom TRANMAPs for example (they made a lot of transparent blues and greens always look gray). Truecolor rendering would certainly benefit transparent textures very noticeably, but alas, Crispy Doom has no support for Strife or Boom maps. :P The big reason I was interested in truecolor was lighting and yes, that definitely looks better now. Especially when certain colors (pink and red) and dark environments are involved. The partial invisibility effect looks too dark/opaque against most backgrounds compared to the 8-bit renderer, so partially invisible sprites are too easy to see (look at the comparison pics of map03 Spectres), but it's probably hard to make it look just right always in all cases when not using the old colormap based approach. Oh yeah, there's a new minor bug now with the initial screen wipe when going to directly to game on startup in widescreen mode (see corners): The same bug also appears with the widescreen assets from Unity engine port IWAD loaded, just with data from the new status bar graphic instead of border padding: Using higher d values (0xF0 in this case) for I_BlendDark gives results closer to the old renderer in MAP03: But then the effect looks too transparent compared to the old renderer in bright environments, 8-bit paletted: Truecolor with d=0xF0: I tried 0xD8 as a midway compromise between 0xC0 and 0xF0 and it looks about right in fullbrighted E1M3, but is already too dark in the MAP03 location. Also, these screenshots starting to eat away a lot of attachment space, I think I'll have to remove them or convert to jpegs later... One more thing I thought I might be worth trying is to copy the formula from dcolors.c that was used to calculate colormaps[6] in the first place (well, the colour values that were then used to find the closest available colour from the palette anyway): red = (red*(NUMLIGHTS-l)+NUMLIGHTS/2)/NUMLIGHTS; green = (green*(NUMLIGHTS-l)+NUMLIGHTS/2)/NUMLIGHTS; blue = (blue*(NUMLIGHTS-l)+NUMLIGHTS/2)/NUMLIGHTS; for l=6 becomes pixel_t FuzzBlend(pixel_t original) { uint32_t r,g,b; pixel_t newpx; r = (original & rmask)>>16; g = (original & gmask)>>8; b = original & bmask; r = (r*26+16) / 32; g = (g*26+16) / 32; b = (b*26+16) / 32; newpx = (r<<16) | (g<<8) | b; return newpx; } used in R_DrawFuzzColumn in place of I_BlendDark like this /* *dest = I_BlendDark(dest[fuzzoffset[fuzzpos]], 0xC0); */ *dest = FuzzBlend(dest[fuzzoffset[fuzzpos]]); Unfortunately the result still seems slightly too dark against some backgrounds, so either there is something I'm missing or the 256 colour quantization process (esp. when combined with repeated lookups from the colormap?) affects final perceived brightness enough that a more complex calculation is needed to simulate the original look: On the other hand this spot in Plutonia doesn't look so bad using the formula from dcolors.c, 8-bit: Truecolor with dcolors.c formula: I_BlendDark with d=0xC0 (shot is taken in low detail mode because I left the code for that untouched so I can easily switch between original and modified fuzz blending): Only I_BlendDark w/ d=0xC0 looks very noticeably too dark here. I think fullbright E1M3 doesn't look bad either with this formula (compare with 8-bit above): Yet another thing I noticed now is that the truecolor fuzz drawer should also probably always multiply fuzzoffset[fuzzpos] by SCREENWIDTH like the 8-bit code does. It works just fine and looks better, and more like the 8-bit mode. one last update: If I understood everything correctly, then using I_BlendDark with d=0xD3 (alpha value 211 or ≈0.82) should give the same results as using the dcolors.c colormaps[6] formula. So still not perfect as can be seen from the MAP03 shots, but generally closer to 8-bit than 0xC0.
  7. xttl

    Crispy Doom 5.10.0 (Update: Jan 12, 2021)

    Yes, both --disable-truecolor and --enable-truecolor=no seem to work as expected now (CRISPY_TRUECOLOR not defined in config.h), and the screen border fill in widescreen mode also has the correct palette even when built with truecolor enabled.
  8. xttl

    Crispy Doom 5.10.0 (Update: Jan 12, 2021)

    Help text with a quick glance said: --enable-truecolor true-color rendering (experimental) [default=no] so I just went by that. Seems it also says: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) so probably it should have worked, but w/e, at least it works now. I tried it again, and I really do get that bug with the widescreen status bar borders if I compile with --enable-truecolor=no. --disable-truecolor also builds a buggy binary. Only leaving out the parm completely works!
  9. xttl

    Crispy Doom 5.10.0 (Update: Jan 12, 2021)

    Yeah I removed it because the problem was caused by enabling the truecolor mode which is still marked as experimental. But if you want to see what it looked like, here: (notice the bottom left/right corners, regular reduced screen size border still worked fine though)
  10. xttl

    Crispy Doom 5.10.0 (Update: Jan 12, 2021)

    edit: nevermind, seems --enable-truecolor=no still enabled it :) (I tried compiling with =yes first, then recompiled with =no when I noticed a problem, but it seems I had to remove the parameter completely instead to disable it...)
  11. They did at some point: the hardcoded texture animation tables in vanilla have WFALL1-WFALL4 which was added for Doom 2 in v1.666. Also, the development material released by John Romero contains unused waterfall textures. In the end, Doom 2 didn't have any waterfalls though so the textures got left out from the WAD. Somebody just forgot to remove the animation table entry. (or left it in on purpose for modders?) There is also an unused flat animation defined (even in the oldest Doom 1 only executables) for another style of water floor: SWATER1-SWATER4. This was also included in Romero's data dump.
  12. xttl

    DOS Doom Code Execution

    Ya, but not really by design, unlike if HIGHBLIT was kept in. I'm tempted to say it would have been chaos in the 1990s if it was kept in (have fun scanning wads and hoping someone just didn't write their own virus or trojan which the scanners don't yet know about), then on the other hand, I don't recall many problems with Quake 2's approach which -- as mentioned above -- allowed or rather required mods to run native code. I do faintly remember something about people finding out about a backdoor id left for themselves in all Q2 servers and going wild with it though. Basically the game had a hardcoded check for packets coming from certain IP address ranges which belonged to id, and if your packets appeared to come from those addresses then you could administer a server (eg. kick people) without authing via rcon first. The source address could be spoofed because you didn't even need to have an established connection to the server, and ISPs back then didn't do as aggressive egress filtering as nowadays. It was discovered even before the Q2 source got released in 2001, but IIRC QW has the same backdoor so perhaps they forgot to remove it from the publicly released sources? It might have been discovered even before the Q1/QW source release actually... (though Q2 was definitely already out) Speaking of Q1, I'm willing to bet the progs.dat interpreter can also be somehow exploited to execute native code, and that the bug is something that could have been plausibly discovered even before the source was released since there were huge and successful reverse engineering efforts going on already even in the Q1TEST days. :-) The first published working QuakeC compiler* wasn't even Carmack's official one. (plus, Q1 v1.01 source code leaked years before the official v1.09 source release anyway...) * I wish I'd remember the name, but it was written by a French-speaking person (all the error messages were in French). He also wrote a decompiler (obviously had to since the game's QC sources weren't yet released), and his compiler didn't compile proper Quake C but only the weird language his decompiler produced which had some influences from Pascal but also C-style curly braces. It is deacc/reacc by Armin Rigo (who's Swiss judging from the email address in readme). And looks like I was wrong about it being released before Carmack's QCC: files in the zip have timestamps in August 1996, Carmacks's files are dated late July 1996)
  13. The "noise" is just the floor/ceiling texture, downsampled a lot (drawn as it was somewhere far away up/down) and floodfilled towards infinity because there is nothing to stop it. https://doomwiki.org/wiki/Moiré_error Anyways cool trick.
  14. xttl

    EXE hacking

    I bet the documentation does exist, but only in an old book somewhere. :( Or possibly in a hard drive that is holding files from somebody's old BBS system that never made it into the Internet age. That's interesting, never heard of that one. DJGPP is the only port of GCC to DOS I knew about... My understanding is that Phar Lap extenders were relatively pricey to license back in the day, and so they mostly only got used in expensive professional software like AutoCAD for DOS. I wouldn't be surprised if there simply aren't any games out there that use a Phar Lap extender. Still, the same formats seem to have been used by extenders from other companies (such as here by Intel). I think Watcom actually used to generate protected mode binaries only for Phar Lap until DOS4G and others came along, even Open Watcom still supports some Phar Lap formats in addition to DOS4G. Btw. the last generation of Phar Lap's DOS extender (TNT) actually used the same executable format as Windows NT (including all current versions) uses: PE. It even provided at least some subset of the Win32 API under DOS, including threads and stuff, in 1993. Nowadays there are some free extenders that also do this (see HX DOS Extender), people have got things like media players written for Windows to run in DOS that way. The Japanese Doom and Wolf binaries are in Phar Lap formats too: Doom & Doom 2 use "MP", and Wolf uses "P3". You can actually find some information about these on the 'net. MP seems very simple, not many fields in the header. I wonder if it's related to MQ/MR/MT which all have very short headers, like the version preceding MQ? It's too bad all the Japanese id games were built without relocation tables for some reason even though the formats can do it, maybe their weird Japan only(?) DX DOS extender doesn't support rebasing? That makes it hard to add support for them into LE Loader because it isn't possible to control at what (virtual) addresses you get memory buffers from the OS. :( Well, actually you *can* ask VirtualAlloc on Windows or mmap on Linux/Unix for memory at a certain virtual address, but you aren't guaranteed to get it. I've tested this with asking for memory at 0xA0000 so that a game which uses standard no-frills VGA mode 0x13 could run without any patching or trapping of the graphics code, and it does often work but unfortunately not always (not even when ASLR is disabled from the program header). However, the Japanese binaries must be loaded at very low addresses which makes the required allocations unlikely to succeed in any environment. I would have loved to support at least Wolf3D since it's the only official 32-bit port of the original PC version. :( well, maybe I could go through the binary and try to build a relocation table for it myself but that'd be a LOT of effort... I was going to save this long post until I have some more substantial info about MT, but it's not happening today and probably not tomorrow either. :P Only things I can add right now are that none of the originally zero header fields seem to control the entrypoint. Thought one of them would be it, MQs have an entrypoint field which however is zero by default in REX files built with Code Builder 1.0. Perhaps they removed that option from MT and just always start execution at the beginning... Also, in the main header, the value at 0x18 is definitely a 16-bit word (XMLOD code reads it as 16 bits with movzx), not a 32-bit doubleword. That probably makes the one before it 16-bit too (but you could split the preceding fields in different ways, needs more analysis of XMLOD to be sure). I also finally confirmed that the size of a few other fields is 32 bits. Current guess at header format looks like this:
  15. xttl

    EXE hacking

    Viewing with the DOSBox debugger, it seems Doom v0.2 gets loaded at 0x2000010: 0038:02000000 CD 21 61 C3 00 00 00 00 00 00 00 00 00 00 00 00 .!a............. 0038:02000010 EB 0E 64 62 67 6F 74 6F 20 3D 6D 61 69 6E 00 00 ..dbgoto =main.. 0038:02000020 FC 60 DB E3 BE 68 D9 00 02 66 C7 06 5A 5A DD 3E .`...h...f..ZZ.> 0038:02000030 80 3E 00 75 1E D9 3E 66 8B 06 66 25 3F 10 66 83 .>.u..>f..f%?.f. 0038:02000040 F8 3F 75 0F C7 05 6E D9 00 02 01 00 00 00 E8 F1 .?u...n......... 0038:02000050 8E 00 00 61 E8 D3 8D 00 00 E8 DE 8E 00 00 E8 2D ...a...........- 0038:02000060 00 00 00 E8 84 88 00 00 0B C0 74 06 50 E8 02 8F ..........t.P... 0038:02000070 00 00 FF 35 E0 D5 03 02 FF 35 F8 D3 03 02 FF 35 ...5.....5.....5 ...at least with my DOSBox memory settings and version/build; if it works like DOS4GW and LEs then the load address can change depending on those. Also there are some bytes before it that are *not* coming from the exe file (well, at least not the main MT part) which translate to: int 0x21, popad, ret. There are not enough zero bytes before the jump in the exe for that pad to 16 bytes either. Can also confirm pointers change in memory vs. on disk (the thing that comes after the main MT header always looked like it's a fixup table anyway, this just confirms it is indeed rebased on load). (I calculated that base address by breaking into debugger and then finding the bytes at EIP on disk, and before you ask: under 0x2000000 there is just a lot of zero fill, CS,DS,ES,SS,GS,FS all point to the same memory as usual) just checked: Doom v0.3 is loaded at the same address and changing xms,ems&umb from true to false has no effect on load address. btw. header value #10 (126445 bytes for v0.3, 58535 bytes for v0.2) is always very close to size of what you get if you cut everything from the MT before the first jump or at the offset the first header value specifies (and also all the debug info from v0.2), but neither matches it exactly. Cutting at the point specified by value #1 is only off by one byte though... or I am cutting wrong :P I wonder what is value #6, it is the same large number on both (0x3a0000 = 3801088), I thought it could be the amount of memory to reserve (the version of the Intel compiler I have defaults to 3MB and that number would be close at 3,625MB) but changing it even by one in either direction causes the programs to crash DOSBox. update: if you cut everything before the offset given by the first value in the header, you'll get a chunk that is the same size as in MT header value #10 (58535 bytes in v0.2, 126445 in v0.3). I think the first 12 bytes (so 3x 32-bit values) in that chunk before the jump + string are some kind of further header values. The second and third values are 1 and 0 respectively in both alpha exes. The first value seems to be a further offset, if you use the value to jump to a position inside this chunk you get to some very similar looking content in both exes (beginning with 5D C3 00 0D ...). Based on some strings further down it might mark the start of library code, but why would they want or need to demarcate it like that? (it is not a code/data split either). I noticed in a DOSBox memory dump that some of the stuff near the end of the MT does not appear where you'd expect it to, so the loader probably does something with that value... but what and why?
×