Engoo

[leileilol]

My last AMIBIOS was my '94 486. The rest are Award Modular, if that makes any difference.

[taniwha]

leileilol: am I reading your source correctly in that it seems that you've ditched mgl for directx?

(yeah, I've git svn cloned your source , mostly just for ease of history browsing)

[edit] Well, sort of ditched. I now see that it's brought back as an alternative.

[leileilol]

MGL's still in there for the "95" target. MH's ddraw stuff doesn't work with Windows 95 very well.

At one point I wanted to make fog like this infamous game from the people that brought you modern warfare 2 (which used precalculated fogmaps that were 8kb lookup tables (256x32) that were just like colormaps, but faded to a fog color instead of black)

[mh]

If you're going to be pragmatic about this, the truth is that MGL doesn't work well on NT and the overwhelmingly vast majority of Windows users (take 99 and add 9s after the decimal point, in other words) use an NT-based OS these days. The time when you could say "Windows == DOS" is long over.

At the same time, the GDI version of that code I wrote was fairly line-for-line ripped from Quake 2, so it should be a valid alternative even for non-NT versions of Windows should you feel the need to support an OS that almost nobody uses anymore.

[taniwha]

MH: it's taken me a while, but I've finally begun to understand what's going on in the actual setup code.

As for windows 95: it was old even when the quake source came out. iirc, it was fading rapidly in favor of 98 and XP (or was XP a little later?).

[leileilol]

Some prefer 95 because we HATE 98's shell (all slow and "web integrated"), and using 95's shell over 98 isn't stable.

"Nobody" is a strong word.

[taniwha]

There are probably a few people still doing things in 16-bit dos. I know there are some doing 32-bit dos via djgpp.

[mh]

"Nobody" is a strong word.

But "almost nobody" ain't - if you have 1.25 billion Windows users in the world (http://winsupersite.com/windows-8/windo ... ew-numbers) then even if you can rustle up a few 10s or even 100s of thousands of folks still on 9x you're still in "almost nobody" territory on a global scale, or talking about very specialist communities on a local scale. Unless you're specifically catering for one of those very specialist communities ... well, you can guess the rest.

[Spike]

windows 95(b) rocked.
except for its bluescreens and resulting file corruption, anyway.
beats win98 - at least win95's faults were predictable rather than random.
still got a machine with win95 on it. not sure when it was last booted. think its got lots of stuff piled on top of it. and its so so smegging slow now (yay 60mhz pentium with 16mb ram - it got upgraded from its original . it could definitely benefit from more ram.
I remember running win95 on some 800mhz machine. bios to desktop in 3 seconds... totally pwned win2k in boot speed! Its a shame it stopped booting after upgrading the ram... turns out win95 doesn't like a gig of ram.

but yeah... file corruption. yay.

[mh]

My favourite blue-screen case was if you tried to eject a CD while reading off it. I don't think that was ever fixed in the 9x line.

I remember installing Windows 95 on one of these once - never mind BIOS to desktop, the entire friggin' install took 3 seconds. Something about needing to access an old NetWare server using the old NetWare client. No, I can't remember how I got it to work, but work it did.

By the time of 98 it was obvious that MS were just artificially extending the lifespan of the old DOS-based Windows line while waiting for NT5 to be finished/come out. Even back then I preferred using NT4 over anything in the 9x line; no nostalgia for it here. Times are better now.

[revelator]

os2 for dos allways rather scary how good os2 was in that regard kinda sad that ibm newer got over ms ditching them they had a far superior product.

[frag.machine]

RE: OS/2, I used it for a long time, including to play Quake by modem (DOS Quake, DOS sessions under OS/2 had embedded XMS/EMS management and TCP/IP stack, no need to load a ton of drivers via CONFIG.SYS).
Starting with Windows 2000 Microsoft got a decent desktop OS. NT4 was a nightmare for games, but fairy stable (at least compared to Windows 95/98, eeeww).
When I jumped to XP it was already on SP2, SP3 made it rock solid. Migrated to Windows 7 about 1 year and a half ago, I'll pass Windows 8 and its MS Bob-like interface, thanks.

[leileilol]

it could definitely benefit from more ram.

And maybe a cache module. A Pentium isn't a Pentium without one. I had a nicely cached Pentium 100 that ran Win98SE decently.

Anyway, the reason why i'm keeping the 9x target, is that well, software mode for machines that can't run darkplaces105 or mhquake6. A GL equivelant would be one of those (but slightly dolled up for sound pitch and bobbing stuff). In fact if I ever revive the currently broken GL target i'd slowly backport features from MHQuake6 because that's faster for the slow machines I have. Vertex lighting, especially, for all the single-TMU hardware I have.

[taniwha]

Getting back to something resembling the topic, I've got engoo's vid_win.c sort of working with QF's sw renderers (gl will take a "little" more work).

I have to say the video code of quake has got the be the worst mess in existence.

[leileilol]

I'm experimenting with unrolling with the surface mip block. I couldn't get the whole value clamping any faster. The "if (trans[0] < 0) trans[0] = 0" stuff seems to be the fastest route for me, and i've tried all sorts of clamping methods out there, even a lookup table method (which made the code look a lot neater, but still took a performance dive)


Also, out of curiosity, I tried unrolling the preceding loop. BAD IDEA - and slower!


And finally I was able to put the dithered (not kernel filtered - "dither" in engoo means the color lookup) spans on a duff device. It's a bit much more tolerable at 1920x1080 in play now, however the filtered spans is still slower, and the dither+filter spans runs about the same as filtered.


What I really need to do is learn assembly and hack up that surf8.s into surf8rgb.s X_X

Can this possibly get any faster? (the smallest mip function is shown here for size reasons)

Code: Select all

void R_DrawSurfaceBlock8RGBXD_mip3 ()
{
   int            v, i;
   int lightstep[3],light[3];
   int lightdelta[3], lightdeltastep[3];
   int      r;
   unsigned char   pix, *psource;
   unsigned short *prowdest;
 
   unsigned char *pix24;
      int trans[3];
   psource = pbasesource;
   
   prowdest = (unsigned short *)prowdestbase;

   for (v=0 ; v<r_numvblocks ; v++)
   {
      lightlefta[0] = r_lightptr[0];
      lightrighta[0] = r_lightptr[3];
      lightlefta[1] = r_lightptr[0+1];
      lightrighta[1] = r_lightptr[3+1];
      lightlefta[2] = r_lightptr[0+2];
      lightrighta[2] = r_lightptr[3+2];

      lightdelta[0] = (lightlefta[0] - lightrighta[0])  >> 1;
      lightdelta[1] = (lightlefta[1] - lightrighta[1])  >> 1; 
      lightdelta[2] = (lightlefta[2] - lightrighta[2])  >> 1;


      r_lightptr += r_lightwidth * 3;

      lightleftstepa[0] = (r_lightptr[0] - lightlefta[0]) >> 1;
      lightrightstepa[0] = (r_lightptr[3] - lightrighta[0]) >> 1;

      lightleftstepa[1] = (r_lightptr[0+1] - lightlefta[1]) >> 1;
      lightrightstepa[1] = (r_lightptr[3+1] - lightrighta[1]) >> 1;

      lightleftstepa[2] = (r_lightptr[0+2] - lightlefta[2]) >> 1;
      lightrightstepa[2] = (r_lightptr[3+2] - lightrighta[2]) >> 1;

      lightdeltastep[0] = (lightleftstepa[0] - lightrightstepa[0]) >> 1;
      lightdeltastep[1] = (lightleftstepa[1] - lightrightstepa[1]) >> 1;
      lightdeltastep[2] = (lightleftstepa[2] - lightrightstepa[2]) >> 1;

      for (i=0 ; i<2 ; i++)
      {
         light[0] = lightrighta[0];   light[1] = lightrighta[1];   light[2] = lightrighta[2];

            if (psource[1] < host_fullbrights) {  pix = psource[1]; pix24 = (unsigned char *)&d_8to24table[pix]; trans[0] = ((int)pix24[0] * light[0]) >> 18; trans[1] = ((int)pix24[1] * light[1]) >> 18;      trans[2] = ((int)pix24[2] * light[2]) >> 18; if (trans[0] < 0) trans[0] = 0; if (trans[1] < 0) trans[1] = 0; if (trans[2] < 0) trans[2] = 0;  if (trans[0] > 31) trans[0] = 31;   if (trans[1] > 31) trans[1] = 31;   if (trans[2] > 31) trans[2] = 31; prowdest[1] = (trans[0] << 10) | (trans[1] << 5) | trans[2];            }else{
            pix = psource[1]; pix24 = (unsigned char *)&d_8to24table[pix]; trans[0] = ((int)pix24[0]) >> 3; trans[1] = ((int)pix24[1]) >> 3; trans[2] = ((int)pix24[2]) >> 3; prowdest[1] =  (trans[0] << 10) | (trans[1] << 5) | trans[2];    }   light[0] += lightdelta[0];   light[1] += lightdelta[1];   light[2] += lightdelta[2];

            if (psource[0] < host_fullbrights) {  pix = psource[0]; pix24 = (unsigned char *)&d_8to24table[pix]; trans[0] = ((int)pix24[0] * light[0]) >> 18; trans[1] = ((int)pix24[1] * light[1]) >> 18;      trans[2] = ((int)pix24[2] * light[2]) >> 18; if (trans[0] < 0) trans[0] = 0; if (trans[1] < 0) trans[1] = 0; if (trans[2] < 0) trans[2] = 0;  if (trans[0] > 31) trans[0] = 31;   if (trans[1] > 31) trans[1] = 31;   if (trans[2] > 31) trans[2] = 31; prowdest[0] = (trans[0] << 10) | (trans[1] << 5) | trans[2];            }else{
            pix = psource[0]; pix24 = (unsigned char *)&d_8to24table[pix]; trans[0] = ((int)pix24[0]) >> 3; trans[1] = ((int)pix24[1]) >> 3; trans[2] = ((int)pix24[2]) >> 3; prowdest[0] =  (trans[0] << 10) | (trans[1] << 5) | trans[2];    }    light[0] += lightdelta[0];   light[1] += lightdelta[1];   light[2] += lightdelta[2];
                  
         

         psource += sourcetstep;
         lightrighta[0] += lightrightstepa[0];lightlefta[0] += lightleftstepa[0];lightdelta[0] += lightdeltastep[0];
         lightrighta[1] += lightrightstepa[1];lightlefta[1] += lightleftstepa[1];lightdelta[1] += lightdeltastep[1];
         lightrighta[2] += lightrightstepa[2];lightlefta[2] += lightleftstepa[2];lightdelta[2] += lightdeltastep[2];

         prowdest += surfrowbytes;
      }

      if (psource >= r_sourcemax)
         psource -= r_stepback;
      
   }
}


model shadows makes a good surfaceblock stress test