delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/06/03/10:48:19

From: MORRIS JP <jpmorris AT csm DOT uwe DOT ac DOT uk>
Date: Tue, 3 Jun 1997 15:38:17 +0100
Message-Id: <199706031438.PAA24994@milly>
To: chambersb AT juno DOT com, opendos AT delorie DOT com
Subject: Re: 32 bit DOS - let's bury the hatchet. (offshoot)

> From chambersb AT juno DOT com Tue Jun  3 02:12:07 1997
> To: jpmorris AT csm DOT uwe DOT ac DOT uk
> Subject: Re: 32 bit DOS - let's bury the hatchet.
> X-Juno-Line-Breaks: 0-1,3-11,14-22,28-32,40,43,50,54-59,63-69,72-74,
> 	76-78,80-86,94-97,99-101
> From: chambersb AT juno DOT com (Benjamin D Chambers)
> Date: Mon, 02 Jun 1997 21:09:39 EDT
> 
> Just a few points I thought I'd mention...
> 

Fine, fine..

> On Mon, 2 Jun 1997 16:44:53 +0100 MORRIS JP <jpmorris AT csm DOT uwe DOT ac DOT uk>
> writes:
> >Mike Harris wrote:
> >> THEN THEY WONT USE THE 32bit DOS!  Likewise some people NEED more
> >> power than a 16 bit system can provide, AND *NEED* more than 64k
> >> at a time.  That is why there is something BETTER - 32bit flat
> >> memory DPMI.
> >
> >One of the things I have always considered is a lack of skill in 
> >programmers.
> However, think how much more a good programmer can do with flat mode than
> with segmented?  You aren't a poor craftsman for using a hammer instead
> of a stone.

Yes, but when they start relying on the hammer, they lose the ability to do
anything if the hammer gets lost.

I'm not sure anyone could write a game like Citadel on the BBC micro
anymore.  It had to fit in 12K, graphics, levels, code and all, _and_
share this much with the OS!  It didn't swap to disk at any time.

> >Why is DOOM-95 even slower than Quake?
> Beats me, my computer won't run either.

> 
> >Why is Quake so slow?  I have seen programs written long ago, which 
> >perform
> >most of the functions of the Quake engine on an XT, but without 
> >texturemapping.
> That's the kicker - you can get GOOD gouraud shading using only 5
> registers (Color, step, count, dest, work).  For texture mapping, you
> need 8 (And that's without light shading).  Of course, that's affine
> mapping - I haven't gotten around to doing a perspective correction
> engine, but I would guess it adds more registers.  The Intel CPU's
> (through Pentium) only give you 7.  Phong shading is even worse.

Well then, you do know more about 3D engines than me.  But Gourad shading is
one of the first things to go when they press the 'low detail' key..

Using code pointers, you could have different rendering engines that are
hooked into the game on-the-fly.  One for 286, one for 386, one for 486, etc.

I used a trick like this on the DPMI16 version of my scrolling engine.

> >Wolfenstein does texture mapping. Just add these together, and Quake 
> >for a 286
> >or at least a 386 doesn't seem so far-fetched.
> Yes it does.  How much do you really understand the engines behind the
> games?  I'm the first to admit, I don't know how the Quake engine works
> (except for using the FPU to do a perspective correction while the IU
> uses fixed point to compute the pixels between), but Wolfenstein used
> raycasting with WALLS ALIGNED ON A GRID.  The walls did not deviate from
> the grid lines in any way.  Such a situation is extremely easy to
> optimize the hell out of.  Unfortunately, it means you've got square
> walls.
> Doom used polygon rendering of sector walls, but was still really a 2d
> game.  However, it allowed light shading (in a limited manner) and walls
> in any direction.

The program I have in mind is also polygon-based, and it doesn't _really_
allow lighting.  I had a suspicion that wolfensteinian texture-mapping
uses shortcuts not available on 6dof engines.  

> _AS I UNDERSTAND IT_ (ie what I can deduce from having seen it 3 or 4
> times), Quake operates entirely on a polygon based system (still using
> sectors, though now it's much closer to being 3d by having the sectors
> overlaid on each other).  The objects are now full 3d models, unlike
> previous games which simply used a different picture for each angle you
> could be viewing from.  I haven't played it enough to tell more about the
> geometry of the sectors themselves.
> Now, if given the time, I might be able to optimize the hell out of Doom
> to make it run well on a 286.  However, Quake is to Wolf what SimCity is
> to Life.  Where Life ran a 200x200 grid at over 30fps on my system,
> SimCity updated the city about twice a second.

Notice, I said "or at least a 386".. the texturemapping routines from DOOM
should suffice, even though DOOM does not support 6dof.  And Descent does
support 6dof.  And strange things Quake doesn't.

> 
> >For all this time, I've been trying to optimise code to run on older 
> >machines.
> >That is my interest in 286PM, although they don't necessarily run 
> >well.
..on a 286, that is.  They're very fast on other machines.

> That's an excellent idea - I personally feel that most things written for
> a Pentium could have the same functionality on a 486 if they were
> programmed better, but I think anything less could be _really_ pushing it
> for most new programs.

Perhaps.

> 
> >I'm not saying that all tasks which have to use flat memory are 
> >badly-designed,
> >in a lot of cases this is the only way to get it done.  But is it 
> >_always_
> >strictly necessary?

> Definitely not.  However, it would be much easier if we could have the OS
> run native to PM.  Most programs could gain a huge boost in performance
> from this.

Quite a few, anyway.  The exact amount has never really been established, and
attempts to do so often result in long flame-wars in programming/architecure
newsgroups.

> 
> >> Ipaid $260 for BC4.0 and TASM 4.0.
> The only thing that stopped me from falling into that trap was the fact
> that I decided to look for a few more days... and then I found djgpp...

> >Now, RFM programs...
> You had me worried - for a minute I thought you meant "Read the F___ing
> Manual Programs".

No, that's RTFM.  But you knew that already :-)

> 
> > > > It wouldn't work with Real Flat programs, Ultima 7, and my demo
> > > >  collection.
> > > > When we get a 32-bit DOS, we'll also need an emergency backdoor 
> >into
> > > > REAL-MODE, so that V86-allergic programs can be run.

> I always wondered why Ultima 7 was such a pain in the arss on everyone's
> system but my own.  A bare 16bit kernel that provides minimal MS
> compatibility shouldn't take more than 512k (depending what drivers are
> with it {most would probably want a mouse, cd, edit, etc}, you could
> probably cut it to 80k though) and would be a good "safety net" for the
> system.  When the system boots, just hit F6 (or something) to kick into
> RM.  (True, a more elegant solution could be found, but for so few
> programs, why bother?
> (Don't kick me for that statement, please)

The F6 solution is worthwhile.  If no solution is adopted, you could still
use an OD/16 bootdisk, assuming it an still read the HDD.
_I'd_ definitely have a FAT16 partition anyway.

> 
> Sorry to go on like this, sometimes I just start typing and typing and
> typing...  Maybe I'm related to the Energizer Bunny? :)
> 
> ...Chambers
> 

Did you know, that one of the original design goals of NDOS/7 was to have
a magic hole into 386 protected mode, that programs could use if they knew how?
They came quite close. (DPMS,DPMI etc)

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019