AnotherGrunt

What? I'm not sure but I think official release (DOS) never supported anything other than Mode 13h. Look into source code: =================== = = I_InitGraphics = =================== */ void I_InitGraphics (void) { if (novideo) return; grmode = true; regs.h.ah = 0; regs.h.al = 0x13; int386 (0x10, &regs, &regs); screen = currentscreen = (byte *)(0xa0000 + __djgpp_conventional_base); destscreen = (byte *)(0xa4000 + __djgpp_conventional_base); outp (SC_INDEX,SC_MEMMODE); outp (SC_INDEX+1,(inp(SC_INDEX+1)&~8)|4); outp (GC_INDEX,GC_MODE); outp (GC_INDEX+1,inp(GC_INDEX+1)&~0x13); outp (GC_INDEX,GC_MISCELLANEOUS); outp (GC_INDEX+1,inp(GC_INDEX+1)&~2); outpw (SC_INDEX,SC_MAPMASK|(15<<8)); memset (screen, 0, 65536); outp (CRTC_INDEX,CRTC_UNDERLINE); outp (CRTC_INDEX+1,inp(CRTC_INDEX+1)&~0x40); outp (CRTC_INDEX,CRTC_MODE); outp (CRTC_INDEX+1,inp(CRTC_INDEX+1)|0x40); outp (GC_INDEX,GC_READMAP); I_SetPalette (W_CacheLumpName("PLAYPAL", PU_CACHE)); I_InitDiskFlash (); Reason was speed of ISA bus as most graphic cards (and sound cards) were on ISA bus. If you're interested more details here. I have here pretty much vanilla DOOM and on i80386dx and on Tseng Labs ET4000 won't give you much more than 20fps. Refresh rate was problem.

Hmm, OK:

I actually admin a few computers at work so I know it definitely isn't the first update to break otherwise perfectly functioning computer. Or in my case computers in row. One fine day in the morning. So let me please correct your statement: "Do not install Windows 10 Updates" or even better "Do not install Windows". If you don't have to. Cheers.

@beast: I like djDoom much more because it is as close to vanilla as possible, but still in C code. Or to be more specific, in DJGPP translatable code. Chocorenderlimits I know and I use, but it is not in my power to traverse entire WAD and test it. Visplane Explorer is much better idea (I wasn't aware of). So thank you for this answer. What is my plan: Download, build and test Visplane Explorer. I need a number. Or to be specific combination of SEGS and VISPLANE limit for every map in Sigil/Sigil2. Then I will attempt to port higher episode support from MBF into djDoom. And lower down MAXDRAWSEGS and MAXVISPLANES macro as much as possible. Original visplane algorithm doesn't scale up as good as what is used in MBF (hashes). I believe only reason why djDoom didn't crashed is good combination of static limits (MAXDRAWSEGS+MAXVISPLANES) and I simply have to find another (higher) still sufficient combination of these static limits. And then test and test and test. And maybe release binary for testing. My original intention why I've started poking into MBF four years back was to tease Romero how he should optimize before releasing anything. That was when Sigil1 was released. But who the hell I'm to teach the master? I'm not mapper and I admit that. I'm much better with code ;-) ----- So I'm starting my analysis and it is exactly as I predicted: (brown is vanilla limit (128 visplanes) red is vanilla overflow (128+ visplanes) and white shade is even more (256+ visplanes)) 256 visplanes should be just enough and even though the some maps can contain 256+ visplanes is better to cut down geometry or MAXDRAWSEGS than shift the limit further up. I don't know how much time it can take, but I'm planning to convert SIGIL1, cut down unnecessary geometry and go through all maps in SIGIL1/SIGIL2. Wish me luck.

Nice. Maybe you should add some example.c file.

I've tested DJDoom in DOS and my truncated version. Of course R_FindPlane: no more visplanes as WAD isn't optimized for vanilla DOOM. Although as I raised MAXVISPLANES to 256 planes, believe it or not, no problem playing up to map e6m4. Then it crashed. Unrelated to renderer though. I have very strong suspicion WAD was designed with budget around 256 planes in mind. Is there some systematical way how to check all maps for visplane and SEGs limit? I mean other than just play and wait for crash.

So, pretty much done (just missing level and half and minus secret level). First take in DOS and took me an afternoon and something. First opinion on the game-play: Sigil2 seems a little fuzzy to me. I personally think SIGIL 1 was better. Maybe it just theme as I was never fan of Inferno episode in original Doom campaign. Although maps e6m4+e6m5 just perfect. It should have been done in a different order. Romero's take for UAC installations on Deimos would certainly be interesting. But yeah, nice small WAD for casual player. Just don't start on Ultra Violence. I've felt ammo and health dry even on HMP skill.And use "Save game" button often. As you find secrets, it is much more tolerant. And now technical standpoint: Of course WAD/BSP isn't optimized for software renderer. Why even bother these days? Full of slime trails, poor performance. But just take it through Zennode and problem solved. It took 12 seconds for all maps to process on my crapy laptop. Another thing is same thing as in Sigil1. Every map is single-player map + DM arena. As I'm not interested in multiplayer, optimization is very simple. Doom builder, little trimming here and there: here is bspinfo: BSPInfo Version 1.3 (c) 1995-2004 Marc Rousseau Analyzing: out.wad Max Avg Depth Depth FOM Balance Splits Diagonals Nodes Segs E6M1: 37 20.2 0.557 0.569 941 - 18.9% 2019 - 81.6% 2474 5928 E6M2: 36 20.2 0.501 0.049 511 - 19.4% 911 - 74.9% 1217 3141 E6M3: 46 20.3 0.529 0.137 785 - 22.9% 1433 - 80.7% 1776 4217 E6M4: 36 20.7 0.555 0.006 1136 - 19.5% 2496 - 86.3% 2893 6964 E6M5: 38 18.5 0.628 0.060 1198 - 16.1% 2031 - 64.7% 3140 8652 E6M6: 38 17.9 0.648 0.764 985 - 15.4% 2267 - 74.3% 3050 7397 E6M7: 36 19.3 0.604 0.081 1155 - 14.9% 1857 - 57.8% 3215 8890 E6M8: 45 20.1 0.567 0.242 999 - 19.4% 2256 - 85.6% 2635 6159 E6M9: 35 18.8 0.559 0.557 378 - 10.1% 897 - 59.4% 1510 4128 BSP tree isn't so complex as I first thought. Yep, little more than Doom2 campaign but not by far leap. And I guess there is still lot of place for optimization. To sum it up, 26800 cycles (aka i80486-DX2/4 equivalent) in DOSBox is just enough for little stroll without monsters (-nomonster switch). Anything little more must be "sweet spot". Let's say Pentium equivalent. Won't reach full 35fps frame-rate but I guess it should be playable. And nice idea with FIREBLU cracks as secret triggers for secret caves. A novel idea. In OpenGL and 4K resolution it must be hard to find. Unfortunately not so much in VGA resolution: It bleeds out of picture (sometimes literally as FIREBLU is slime-trailing in entire column). Low-detail mode is best helper. Such a shame as low-det mode isn't dynamically implemented in MBF204. ;-)

@Bedingungsl.Grundeinkommen : Although with old legacy ports in mind I believe. So far, there is not one thing blocking progress in old ports. Just out of curiosity, I've tested Sigil2 in GZDooom along Torr's soundtrack. Do not take me wrong, I don't want to sound ungrateful or anything (is good soundtrack), but my opinion is it doesn't fit. Midi soundtrack is just good and much better fitting. MP3 soundtrack should have been used for Quake or something. Next thing is something stronger in arsenal. At the beginning of E6M3 Super shotgun (or similarly powerful weapon) would be just handy. In MBF is possible to use -ssg switch and SSG.WAD. But to acquire SSG, one must cheat. And last question is if anyone knows what are original sky-boxes used in SIGIL2. I would love to fit in and maybe dither a little. Would be nice touch for DOS.

Thank you very much. This time, I've decided to buy WAD right away. As I'm not expecting "another Daikatana". Play-tested first level and it seems to work pretty fine. Only bug I've noticed is weird tiled Skybox. Only disappointment is, maps are even less optimized for DOS than last time. My usual setting of custom prepared DOSBox and fixed 26800 cycles and 486 CPU won't cut it. Is pure slideshow. Are there recommended settings to play this WAD? At what CPU speed (cpu cycles) are you playing? I don't need full 35fps experience, on the other side <10fps slide-by-slide isn't much amusing either. Or should I try to optimize BSP tree before playing? Anyway, Merry Christmas everyone.

Do not try me Dragofly. I've said I'm not doing it, not "it's not possible".

Great. I'm not porting this thing to DOS. No way. I'm simply NOT…

Oh, so it is. It make sense. Well, if there is a reason to praise John Carmack, here is one. All engines he ever wrote are long time open-source (as far as possible, I guess). It would be really nice to have native 64-bit binaries compiled for release:

Guys what? Unreal engine hasn't been open-sourced? I've seen somewhere (years back) shared binaries for UT99 with all debugging symbols embedded in so I lived in illusion, Unreal engine had to be open-source. And I was wrong all along?

Thanks a lot. Actually, motivated by this accomplishment I wondered, would be still possible to build a little newer version of EE in DOS? So a little more recent version (3.37.00 'Sekhmet' -- 01/01/10): So of course, it crashes on linker and tons of unresolved/undefined references. But dir djobj/*.o is full of DOS-executable object files. Shame the DJGPP version has been abandoned in course of development. I believe it would work just perfectly fine.

@viti95 Well, as I see it, it is intentional. Red and Green bits are the most important colors. So my wild guess is first bitplane (Plane 0) is more important than the second bitplane. Make update as 2-pass write function. In first pass update "Plane 0" bitplane and then "Plane 1" and only even-numbered scanlines, return from ATI640_DrawBackbuffer(), let routine R_RenderView() update backbuffer and then the same thing for odd-numbered scanlines. If lucky you'll be able to catch CRT ray as is updating CRT screen and color artifacting won't be crazy. Happy computing, COMMODORE ;-)