drfrag

Members
  • Content count

    55
  • Joined

  • Last visited

3 Followers

About drfrag

  • Rank
    Mini-Member
  1. Doom 1.22 was the 'stable' version for many years but actually was unstable and crashed from time to time. ZDaemon is based on 1.23 beta which was very different and actually stable. The one actually based on 1.22 is Odamex. There's an updated MBF 2.04 version for dos @vogons. For nostalgia you may want to try ZDoom Classic, it's a lightweight version for very old hardware based on 2.1.4 but runs well on modern machines as well. Has D3D (early) and GL renderers and some later stuff added.
  2. Well, this is embarrassing. I've just released a new version since i've found a nasty bug with broken savegames on maps with dynamic lights (i've flagged it as critical). Somehow i missed a bugfix by Graf after porting his GZDoom adjustments for the new savegame code, i usually don't read the entire description for all commits. The problem was already in the previous release after the merge with the old GZDoom but it's not a bad merge. I know i said the last one was a solid release but hey this time is for real i promise. I know this comes after the gcc crash with voxels for the SSE2 version but it was also unfortunate and that doesn't mean this is not a solid product. Some testing would be welcome.
  3. I've just updated the Classic release to fix a crash in GL mode with truecolor PNGs, the crash was already there in GZDoom 1.0.17 when compiled with gcc and it's not related to the addition of that half-assed support in software. That ancient renderer didn't support truecolor PNGs (it's the one using DevIL before the texture management refactoring) and where in VC you got missing textures with gcc you get a crash. Obviously i haven't tested this much, sorry for the inconvenience.
  4. I've tried it and i think it's cool, there are some serious balance issues but this is a beta and Sarge could fix them eventually (has happened in the past). Okay the chaingun fires too fast (to try to make the machinegun useful) and both the assault shotgun and the grenade launcher suck big time. Rockets have no splash damage may be becouse the sprites for monsters sitting down are ugly (?). Some bugs are still there such as invulnerable revenants and game hanging on deep water sectors (infinite loop). I could release a full standalone version of my BD v20c patch which fixed a lot of bugs but i don't feel much like doing it and i think BD20 is dead (but i could do it anyway).
  5. Thanks. They are actually two different projects, a guy @zdoom.org tested the classic version on his 486 @100 and it was slower than expected, he got 10 fps but reducing screen size a bit it could be considered playable (back in the day 12 fps was playable). That was when it was compiled for 486s but i don't think that will make a difference, so please try and report back. That classic version it's a nice nostalgia trip and has some cool later stuff. Your port also has some pretty interesting features. I'd like to add PC speaker emulation to LE (i know it was shitty and i mostly played without sound until i adquired a crappy sound card) but i don't even know where to start. And splitcreen based on WDMP and SSZDoom (this one is very rough), i'd need help with these. Sorry but it won't happen, however LE can already run more mods than GZDoom 1.8.6 since it's nearly two years more recent. Finally i managed to get a good codebase out of it, i had to revert some stuff and now has a lot of later patches applied, i could have numbered it 1.8.3 or so but i didn't dare. Actually i've tried to merge with master @03/10/16 to get anonymous functions and modern decorate support but i got a lot of conflicts and i'd need to review the history and then fix the renderer again so i don't think it's worth. I could also cherry-pick some stuff and apply some patches partially but again it's not worth (but i might do it eventually). You could run only a few more mods and they could crash somewhere else. But SmoothDoom should already play with LE as i mentioned in the zdoom.org thread. I don't know why Gifty added a '+2' to some A_Jump statements since that was never allowed and there are no negative jumps, then there was some copy-pasta. If you change the '+2' to '2' with slade it will run. I could even post a fixed version. About the latest ZDoom32 i've been testing BD v21 and seems it's a rock solid release (the port not BD of course) but some people are still sticking to ZDoom 2.8.1. The problem i can see it's 3d floors not being properly rendered with the old truecolor renderer (missing textures, not a big problem however) and i cannot fix it, i don't even know how to translate from LLVM to C++. I don't know what dpJudas did either. BTW the invulnerable revenants and hanging the game on deep water sectors BD bugs are still there. I guess you're on intel so you could try to run ZDoom32 @320 (since your card should support that resolution natively) with the software Mesa driver (either fdossena or _mental_ version) and could be playable with a decent cpu. Seems like the modern renderer is not compatible with Mesa, here the game is rendered on a small (1/8) portion of the screen. Edit: editing posts is still completely broken (there was a workaround for adding code but trying to quote someone also kills the entire post). This new forum system is a nightmare.
  6. @Cmdr. J.T. Marshmallow: Thanks. They are actually two different projects, a guy @zdoom.org tested the classic version on his 486 @100 and it was slower than expected, he got 10 fps but reducing screen size a bit it could be considered playable (back in the day 12 fps was playable). That was when it was compiled for 486s but i don't think that will make a difference, so please try and report back. That classic version it's a nice nostalgia trip and has some cool later stuff. Your port also has some pretty interesting features. I'd like to add PC speaker emulation to LE (i know it was shitty and i mostly played without sound until i adquired a crappy sound card) but i don't even know where to start. And splitcreen based on WDMP and SSZDoom (this one is very rough), i'd need help with these. @Brewtal_Legend @Graf Zahl: Sorry but it won't happen, however LE can already run more mods than GZDoom 1.8.6 since it's nearly two years more recent. Finally i managed to get a good codebase out of it, i had to revert some stuff and now has a lot of later patches applied, i could have numbered it 1.8.3 or so but i didn't dare. Actually i've tried to merge with master @03/10/16 to get anonymous functions and modern decorate support but i got a lot of conflicts and i'd need to review the history and then fix the renderer again so i don't think it's worth. I could also cherry-pick some stuff and apply some patches partially but again it's not worth (but i might do it eventually). You could run only a few more mods and they could crash somewhere else. But SmoothDoom should already play with LE as i mentioned in the zdoom.org thread. I don't know why Gifty added a '+2' to some A_Jump statements since that was never allowed and there are no negative jumps, then there was some copy-pasta. If you change the '+2' to '2' with slade it will run. I could even post a fixed version. About the latest ZDoom32 i've been testing BD v21 and seems it's a rock solid release (the port not BD of course) but some people are still sticking to ZDoom 2.8.1. The problem i can see it's 3d floors not being properly rendered with the old truecolor renderer (missing textures, not a big problem however) and i cannot fix it, i don't even know how to translate from LLVM to C++. I don't know what dpJudas did either. BTW the invulnerable revenants and hanging the game on deep water sectors BD bugs are still there. I guess you're on intel so you could try to run ZDoom32 @320 (since your card should support that resolution natively) with the software Mesa driver (either fdossena or _mental_ version) and could be playable with a decent cpu. Seems like the modern renderer is not compatible with Mesa, here the game is rendered on a small (1/8) portion of the screen. Edit: editing posts is still completely broken (there was a workaround for adding code but trying to quote someone also kills the entire post). This new forum system is a nightmare.
  7. I've just released new versions of all my legacy ports: ZDoom32, ZDoom LE and ZDoom Classic.

  8. I've released new versions of both ZDoom LE and Classic. This LE update mainly adds a couple of new low detail modes and fixes the BD v21 crash with large textures on old graphic cards in software. See first post.
  9. I've released a new version. This release mainly adds the truecolor capped sky drawers and a couple of new low detail modes and fixes some crashes (large textures on old cards and SSE2 executable with voxels). See first post. I've changed version numbering as well (still it's very conservative). I've updated ZDoom LE and Classic as well.
  10. I updated the mod yesterday to fix some ammo balance issues with the Hellstaff and the Doom Rod. Also i've decreased the damage for the Doom Rod's alt fire, it was extremely overpowered. It's not a helloween special edition just a minor update. I've been playing HUMP these days with Heresy II but i still have some pending classic Heretic wads to play.
  11. Then you might want to try Romero's Heresy II. A pretty cool mapset BTW.
  12. Yes, it's possible on paper but i still don't know how to do it. 3x3 wouldn't be very useful anyway, i've added the 4x4 mode instead and it was not as easy as i expected. I've corrected horizontal position with reduced screen sizes as well.
  13. I didn't know about the double click, i just deleted the code and it's not possible to add new code without killing the entire message. I've uploaded the final version to https://github.com/drfrag666/gzdoom/commits/gzdoomle (and gzdoom32 and zdoomcl). On the 3x3 thing with linefrom += realpitch*3 actually there were many missing lines (missing data) and i couldn't fill them. I don't think it's related to those extra bytes in the pitch for aligment. With pitch*2 there was an extra line i could not fill (quadruple vertically would be easy). I don't know what you mean with divide by three. I even drew an sketch on paper but i could not get it to work. Anyway as soon as you do something strange the engine will crash in GillotineBinPack.cpp. Note that there are no extra bytes for low resolutions and then realpitch is equal to the screen width.
  14. Since can't edit posts with code... Your reply was actually useful but i was already debugging and then it crashed inmediately in r_draw.cpp upon changing video mode to 1024 with lineto being out of bounds. Edit: actually it's a 3x2 mode. I think 3x3 is impossible, i'd need to use linefrom += realpitch*3 but i get junk. Same for 3x1, setting detailyshift to 0 makes the engine crash somewhere else.
  15. Missing code, this forum system is a nightmare: case 5: // x- and y-triple { int rowsize = viewwidth; int realpitch = RenderTarget->GetPitch(); int pitch = realpitch << 1; int y,x; BYTE *linefrom, *lineto; BYTE c; int offset = viewwidth > 320 ? CPU.DataL1LineSize : 0; linefrom = dc_destorg; for (y = 0; y < viewheight; ++y, linefrom += pitch) { if (y > 0) { lineto = linefrom - viewwidth*3 - offset; } else { lineto = linefrom - viewwidth; } for (x = 0; x < rowsize-3; x=x+3) { c = linefrom[x]; lineto[x*2] = c; lineto[x*2+1] = c; lineto[x*2+2] = c; c = linefrom[x+1]; lineto[x*2+3] = c; lineto[x*2+4] = c; lineto[x*2+5] = c; } x = rowsize-1; if (viewwidth >= 200) { c = linefrom[x-2]; lineto[x*2-2] = c; lineto[x*2-1] = c; } c = linefrom[x-1]; lineto[x*2] = c; lineto[x*2+1] = c; if (y > 0) { memcpy (lineto+realpitch, lineto, rowsize*2); memcpy (lineto+realpitch*2, lineto, rowsize*2); } else { memcpy (lineto+realpitch, lineto, rowsize*2); } } } break;