-
Content count
154 -
Joined
-
Last visited
-
Ashes 2063 - GZDOOM Total Conversion
AnotherGrunt replied to Vostyok's topic in Total Conversions & Full Games
So I'm little past the Cordon and I have to address few issues: First off, voice acting — I belive it's a step in right direction. Many times, playing Afterglow slicing through the endless dialogues, I said to myself it feels like old days of DOS adventure games and it could use some voice acting. This time, my prayers have been answered. I'm fan of less (but all the more profound) Lore and more of shooting and playing, than reading. So thumbs up for this. BUT, problem with voice acting in Hard Reset have been already mentioned. Yes, whole enterprise isn't professional paid thing. I'm aware of that. Many times, I don't simply understand what the characters are saying. How were the voice files recorded? It consist a lot of mumbling and too quick and wrong pronunciation. I personally don't mind accent but it should fit the on screen character. Many times voices simply don't fit how character is depicted. Back in days when state of the art was Sound Blaster, rule was voice-file converted to 8-bit, 11025Hz (or 16kHz) played on speakers had had to be understandable. Please @Vostyok, if you own original non-compressed sound files, try to test them. Convert it, play it and let (for example) Google Speech-to-Text AI convert it back to text and you'll see right away which part requires improvements. Other than that, I don't have any complaints. Character depiction it's even better this time and when fixed, I wouldn't mind voice acting retrospectively in Afterglow. It is definitely good thing and should be kept in any further releases. Next thing is sound ambience. I belive it is good, but I wouldn't mind it even little enhanced. No part in maps (unless intended) should be pure silence. Again, back in days it was way how to compensate for the imperfect graphics. Add more ambiance. Wind howling, white noise, weird non-logical noises, steps, transformer buzzing, doors slamming, whatever comes to mind. All releases are compensated with five-star soundtrack, but try to play it without it and you'll see for yourself what I'm talking about. And lastly I would like to know, if there is a way how to convert some part of maps to vanilla BSP format. I would like to try how endless tunnels would look like with vanilla Light diminishing. As i get it, TC isn't optimized for anything other than OpenGL or Vulkan renderer. Is that so? -
DOOM screen resolution: When did it start supporting more than 320x200?
AnotherGrunt replied to Azafran's topic in Doom General Discussion
@Azafran: Ok, then as soon as Doom95 was available (November 1995). Of course if you had appropriate drivers for DirectX. You can boot it even today and have pretty much "time period exact" experience: -
DOOM screen resolution: When did it start supporting more than 320x200?
AnotherGrunt replied to Azafran's topic in Doom General Discussion
Azafran: And that is my whole point. It never became widespread. Not in 90s because: Ports with a resolution higher than 320x200 were not widely available. Even if a game port with resolution higher than 320x200 would be available, there was not much HW prepared for it. So if you want "Doom in a period accurate manner" enjoy your 320x200 pixels. So-called "purists" are right. I personally went through the entire DOOM-2 campaign in LOW DETAIL mode (160x160?). When higher resolution became more widespread, there were already GL accelerators and better games to play. My better game was Unreal in resolution 512x384. Edit: Oh, wow. Look at this topic. More graphical modes were planned but were taken out in alpha-stage. -
DOOM screen resolution: When did it start supporting more than 320x200?
AnotherGrunt replied to Azafran's topic in Doom General Discussion
Both WinDOOM and Doom95 are 32-bit windows applications. Error 21 simply means you're running 32-bit application on 16-bit OS. You need Win32s and WinG. Don't forget of course graphic card drivers. -
DOOM screen resolution: When did it start supporting more than 320x200?
AnotherGrunt replied to Azafran's topic in Doom General Discussion
I don't have i80386 with Win3.1 no more. But even from what I recollect, I always had higher resolution let's say with 16-colors. Or paleted-colors but extremely slow (some ISA graphic card). When higher resolution became standard, there were much better games to play (QuakeII, Unreal) than Doom. Even if Build Games were available with better resolution, I don't personally remember anyone switching default resolution. Simply because redrawing screen was very slow. -
DOOM screen resolution: When did it start supporting more than 320x200?
AnotherGrunt replied to Azafran's topic in Doom General Discussion
Never, I believe. Since Windoom and Doom95 with higher resolution are available only in windowed mode (tested right now). There were of course games with better resolution than 320x200. I namely remember Duke3D (aka any Build Engine game) and Shattered Steel (BioWare/Interplay) but it was more like curiosity since games at this resolution were unplayable. Graphical hardware used to be pretty unusable. -
DOOM screen resolution: When did it start supporting more than 320x200?
AnotherGrunt replied to Azafran's topic in Doom General Discussion
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, ®s, ®s); 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. -
Fuck you John Romero (RE: Sigil II) and thank you for the memories
AnotherGrunt replied to Brad_tilf's topic in Doom General Discussion
Hmm, OK: -
Do not install Windows 10 KB5034441 Update!
AnotherGrunt replied to Rudolph's topic in Everything Else
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.
-
Mod4Play: Lightweight replayer for IT/S3M/XM/MOD music in C
AnotherGrunt replied to dasho's topic in Source Ports
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.