Re: memory reading and writing

From: f0dder (f0dder_spicedham_at_flork.dk)
Date: 07/19/04 

Date: Mon, 19 Jul 2004 17:42:19 +0200

Beth wrote:
> f0dder wrote:
>> And there were wonderful games like silkworm (I think - it has
>> been quite some years) which used DMA to load the levels in the
>> background, transparently, while you were playing, so there
>> weren't any "loading time". Try this on PC hardware from a floppy,
>> you'll see how much PC hardware sucks, despite high MHz rate :)
>
> Indeed; And there's actually no particular hardware reason for
> this, in fact...it's just that Microsoft have always written
> crap code...even today, accessing the floppy or spinning up a CD
> and things like that still end up _halting the entire system_
> because they don't write asynchronous routines for these things
> (indeed, they are likely using "polling", no doubt...which shows
> _WHY_ this isn't recommended with multi-tasking systems: Literal
> "show-stoppers" ;)...
>
Hm, are you sure the PC floppy hardware is capable of the same kind
of background loading? I've always been under impression the floppy
hardware in PCs suck bigtime. Then again, OS/2 was better at, well
at least, *formatting* floppies and not clogging down the entire
system. So yup, seems like microsoft isn't handling the legacy floppy
drive as well as they could. I wonder if it could be done _a lot_
better, though.

As for spinning up the CD drive, it's only explorer that freezes.
And, at least on XP, only the explorer window that is accessing the
drive. But I sure do remember the perceived "full system lockup" on
2k, and it's very annoying. Foo, Microsoft!

> It's lazy programming, really...not an inability of hardware to
> do it...and that's not only Microsoft who're responsible because
> even when MS provide asynchronous versions of "ReadFile" and
> "WriteFile", does anyone much use them? Most of the time: Nope!
> ;)...
>
Well, I can't blame the application coders, the async routines are
slightly more complex to use. Their man use, anyway, is when you're
writing really high-performance stuff anyway, not much point in
using them everywhere. Just like you wouldn't use I/O completion
ports in a telnet client :p

Game loading stuff - have a look at Dungeon Siege (released under
the Microsoft brand :p), it has this transparent loading and it
works pretty well. You can still feel a small "hiccup" sometimes
when it's loading, but it works _very_ well in practice, and the
world is awfully huge. Such techniques work even better on
consoles, where you have tight control of the machine and aren't
running any other tasks.

There's one console game (can't remember which), that has a very
cute form of background loading... if you run too fast towards a
new area, and the game sees it can't load fast enough, your
character will stumble and trip, giving the engine that half or
whole second that lets it load :)

Dunno if this is feasible for all kinds of games, might be hard
to do if you have, say, huge outdoor areas. But it would be nice
if more PC developers at least _considered_ this kind of thing.

> that's why it's important to stress the "don't poll unless you're
> offered no choice in the matter on multi-tasking systems: It
> steals CPU time from other threads and, thus, can degrade the
> performance of the entire system"...
>
Amen!

>> Haven't they had this for a while? NVIDIA cG, DirectX HLSL?
>> I haven't looked at either, though. But a couple of links:
>
> Ah, but, again, the problem isn't the hardware
> necessarily...it's _Microsoft_...when you have to use DirectX or
> whatever to get access to the cards (as it prohibits "direct
> access" to hardware and supplying your own drivers that get
> around this is impractical when there's a lot of hardware that
> needs to be supported) then it doesn't really matter when the
> cards started including the functionality, it's when _Microsoft_
> added it to their OSes so that you're able to _access_ this
> stuff to take advantage of it...
>
*shrug* - I remember the days of incompatible 3D standards (glide,
PowerVR, etc) and I certainly don't want to go back to this.
You might argue that you could make a standard for how GPUs should
work, but I'm afraid this would hinder innovation. Especially if
it's a big consortium that has to agree on all those things, look
at how long it takes for OpenGL to standardize new features...
DirectX doesn't really seem that bad, while the first versions
sucked majorly, the more recent ones perform pretty well.

> And, again, as Microsoft have to go for "lowest common
> denominator" to make sure the support covers all the hardware
> and doesn't get too "specific" to how any one manufacturer does
> things, then you can also have difficulties from that too,
> potentially...
>
Humm, compare DX to GL and then talk ablout lowest common
denominator :)

> But, anyway, "lazy programming" then comes into it on top of
> that...after all, "bump mapping" has been in many cards for a
> while...but we're still waiting for DOOM III to actually be the
> first game to properly take advantage of it throughout the game
>
Have a look at Thief (3): Deadly Shadows (based on some Unreal
engine, I think). Now I could be very mistaken here, but it looks
as if they make good use of bumpmapping to make flat (polygon)
walls appear bricky. And without the "semen-covered" look that
some other games have had ;). But sure, doom3 and halflife2 will
probably be the first games that _really_ show off.

> (rather than just some small "demo" that uses it)...something
> like Counterstrike - one of the most popular on-line games -
> actually uses the _Quake I_ engine (slightly modified just to
> add in support for "hardware acceleration")...how old is that
> engine?
>
CounterStrike is based on halflife, I think halflife is a modified
Quake2 engine (hm, quake 1? I think it's 2 :-s). But yes, that is
still a very old engine. Good to see that iD is finally doing a
"little" innovation with the doom3 engine, because quake3 didn't
look like that much of an improvement from quake2. (More polys,
curved surfaces, prettier textures... big deal.)

> while practically every single game written for the C64 was using
> the scanline interrupt to perform all manner of multi-tasking
> tricks...
>
Or using the 1541-II floppy drive to do background computations :)
C=64 is amazing... not even 1MHz, and yet clever programmers have
managed things like bumpmapping. I think a demo at The Party even
showed what looked like a 16Mil color picture, by the use of some
_very_ clever programming and timing knowledge.

> I've said it before: The priorities in a computer game should
> actually be 1. Input 2. Sound 3. Graphics in that order...
>
Sounds reasonable. Of course depends on the kind of game, but in
something fast-paced you'll want to react to user input
immediately. Sound and graphics need to be synced well, and more
attention should be paid to sound, some programmers tend to
forget that there are latencies involved.

> and Half-life 2 is going to give even DOOM III a run for its
> money...I think DOOM III wins the "most anticipated game"
> award but not by that much...
>
DOOM3 looks very moody etc, sorta has a plot - but from what I can
see, still focuses more on the engine than gameplay and immersion.
HL2, valve-style, focuses a _lot_ on gameplay... and well, their
engine still kicks some serious ass, seems more interesting than
the doom3 one. I'm gonna buy both those games, but I'm definitely
looking most forward to HL2.

> Microsoft not thinking or bothering about asynchronous operations...
>
Humm, windows does do file operations async, but that doesn't help
much if the game uses BLOCKING I/O :) :) - not really MS's fault.
(game doesn't even need async I/O - it could use a lower-priority
background thread with blocking I/O).