drfrag

Members
  • Content count

    45
  • Joined

  • Last visited

3 Followers

About drfrag

  • Rank
    Green Marine
  1. 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.
  2. 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.
  3. 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.
  4. 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;
  5. Thanks but i already tried that. It's fixed now anyway. I wanted to do this mainly to prove myself that i was capable of doing it. I guess the compiler will optimize this and the y > 0 condition will not be checked on every iteration of the outer loop but i'm not sure. There's a remaining problem, the image at high resolutions is displaced to the right and i think that's due to the CPU.DataL1LineSize cache optimization in DSimpleCanvas::DSimpleCanvas. I guess the pitch must be different but i don't know how to fix it, i've tried without luck. Edit: fixed as well. Post editing is BROKEN!
  6. As you know i restored low detail modes in ZDoom LE and added a quad mode (4x2). Now i've added a 3x3 low detail mode (4x2 was easy), it works but crashes on exit and i don't know why. I've traced the algorithm and it's right. The only way to prevent the crash is to stop the inner loop with x < rowsize-6 but then the rightmost part of the screen wouldn't be filled and would display junk. I've kept detailxshift and detailyshift at 1 since otherwise would be a mess but i think it doesn't matter. For instance rowsize is 160 and screen width is 320. The problem is in ~DSimpleCanvas but the debug info is not useful. If someone wants to help i would appreciate it. Thanks. // [RH] Double pixels in the view window horizontally // and/or vertically (or not at all). void R_DetailDouble () { if (!viewactive) return; DetailDoubleCycles.Reset(); DetailDoubleCycles.Clock(); switch (r_detail) // (detailxshift << 1) | detailyshift { ... case 4: // x-quad and y-double { int rowsize = viewwidth; int realpitch = RenderTarget->GetPitch(); int pitch = realpitch << 1; int y,x; BYTE *linefrom, *lineto; linefrom = dc_destorg; for (y = viewheight; y != 0; --y, linefrom += pitch) { lineto = linefrom - viewwidth; for (x = 0; x < rowsize; x = x+2) { BYTE c = linefrom[x]; lineto[x*2] = c; lineto[x*2+1] = c; lineto[x*2+2] = c; lineto[x*2+3] = c; lineto[x*2+realpitch] = c; lineto[x*2+realpitch+1] = c; lineto[x*2+realpitch+2] = c; lineto[x*2+realpitch+3] = c; } } } break; case 5: // x- and y-triple { int rowsize = viewwidth; int realpitch = RenderTarget->GetPitch(); int pitch = realpitch << 1; int y,x; BYTE *linefrom, *lineto; linefrom = dc_destorg; for (y = viewheight; y > 0; --y, linefrom += pitch) { lineto = linefrom - viewwidth*3; for (x = 0; x < rowsize-3; x=x+3) { BYTE 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; BYTE c = linefrom[x-1]; lineto[x*2] = c; lineto[x*2+1] = c; memcpy (lineto+realpitch, lineto, rowsize*2); memcpy (lineto+realpitch*2, lineto, rowsize*2); } } break; } DetailDoubleCycles.Unclock(); }
  7. True, however you can actually decrease draw distance both in GZDoom and QZDoom using cvars. And in ZDoom32, ZDoom LE and even ZDoom Classic with a menu slider for it.
  8. Fixed, thanks for reporting. That was truly surprising.
  9. I've finally released a new ZDoom LE version with the old OpenGL renderer for GL 1.2 cards. It's the GZDoom 1.8.4 renderer with later patches. I also backported the QZDoom render cull options by dpJudas from ZDoom32. I've managed to fix the bugs introduced with the restoration of the low detail modes as well. I've switched to FMOD Ex 4.36 for sound. Also there's a last version for win95 without the GL renderer using OpenAL. I've updated the ZDoom classic version, i've merged an ancient GZDoom 1.0.17 GL renderer with later fixes and additions as well. BTW among them i recreated the 1.0.18 fix with Graf's clues (basically he said what to do in another forum). I had to make the merge manually with DiffMerge since there was still no GZDoom repo. Also has an early Direct3D renderer and again the render cull options by dpJudas. It's a good nostalgia trip, i tried to update it to 2.1.7 and even 2.1.6 but kept crashing with GCC. I've also updated ZDoom32. See first post for downloads and detailed info.
  10. I've released a new ZDoom32 version with the OpenGL renderer from GZDoom 1.9.1 with later fixes and additions, has shaders for GL 2.0 cards. I've also switched to FMOD Ex 4.36 for sound. I've also updated ZDoom LE for even older hardware. See first post for download and detailed info.
  11. What's in my gzdoom repo ( https://github.com/drfrag666/gzdoom ), copied from README.md: Some ZDoom based legacy ports with lower system requirements for Windows 9x or later and older hardware. Some branches are discontinued from now on (SEP 04 2017). - gzdoom32 branch: ZDoom32 is a fork of truecolor ZDoom by dpJudas and Rachael and a later ZDoom (https://github.com/rheit/zdoom). It's a merge of dpJudas old truecolor branch (SEP 08 2016) and ZDoom master as of DEC 03 2016. Now merged with the GZDoom g1.x branch (APR 24 2016). - glzdoom32 branch: A merge of ZDoom32 with a later GZDoom master (roughly 2.2) from NOV 17 2016 with later fixes. Discontinued. - zdoom32 branch: Old ZDoom32 2.8.2 branch without the GL renderer. Discontinued. - gzdoomle branch: ZDoom LE (Legacy Edition) is a fork of the ZDoom 2.8.1 maintenance branch (https://github.com/rheit/zdoom/tree/maint) for Windows 98 and old machines. Now merged with GZDoom as of august 2013 (1.8.4a). - zdoomle branch: Old ZDoom LE 2.8.1a branch with OpenAL for win95 (released from the ZDOOM-LE repo). Discontinued. - zdoomcl branch ZDoom CLASSIC 2.1.4a is a fork of ZDoom 2.1.4 for Windows 9x and pentium machines. Now merged with GZDoom 1.0.17 with later fixes and additions.
  12. I've updated the mod to fix the D'Sparil BOSSDEATH special bug and to add a couple of mutators to play with Doom or Heretic monsters only. I'd swear it worked fine. Apparently this was an engine bug and only happens with certain versions since the Sorcerer3 actor (required by random spawner) was an empty actor and won't inherit the BOSSDEATH flag (last flag) from Sorcerer2.
  13. Thanks very much! But the merit is mostly yours and dpJudas' (and Graf's of course), i mainly did the merge and applied and ported patches. I did the dirty work. :) Hope you won't find anything strange. I replied to the 'Add more source port links' thread @zdoom.org but it was moved.
  14. I've just released a final version of ZDoom32.

  15. I've just released a final (non pre-release) version.