Re: memory reading and writing

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 07/19/04 

Date: Mon, 19 Jul 2004 06:13:27 GMT

f0dder wrote:
> Beth wrote:
> *lots of snipping :)*

[ Of course; I always recommend snipping my posts because
quoting the whole thing every time will get very silly very fast
;) ]

> >Then with Atari ST and Amiga machines, they typically came
with
> >512KB in their basic "home user" models and the disk drives
were
> >the same kind of 3.5 inch floppies, having more disk capacity
> >than there was RAM...so, the floppy disk was kind of used a
bit
> >like a "hard drive"...and software - especially games - would
> >commonly be written in "chunks" (say, loading each level one
at
> >a time from the disk when you completed each level :)...
>
> 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" ;)...

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!
;)...

I was actually talking to someone about this kind of thing
before...in many 3D games, you walk along and then reach a door
or some invisible "boundary" and then "LOADING..." appears in
the middle of the screen...and I thought a possible away around
this would be to divide up a game map into "rooms" (of course,
doesn't literally have to be a "room" in the real-world sense
but more a "compartment of cubic space" ;)...then have a "room
cache"...each "room" lists which other rooms connect to it
(calculated when the game map is "compiled" :)...

Then, simply, when the player is standing in "room #1", the
listed of connected rooms is parsed and all its neighbours (the
linked rooms) are loaded into this "room cache" too...then, as
the player walks into "room #2", it'll load in the neighbours of
"room #2" into the "room cache" also (and with clever design,
you ensure that it simply always takes longer to walk or run
across the room than it takes to load up all the rooms into the
"room cache" in the background so you can't ever "catch up" with
it and that the "loading..." appears in the middle of the screen
:)...the "room cache" works like most caches: It just fills up
with "rooms" and then the "least recently visited" rooms are the
first candidates to be overwritten in the "room cache" when new
rooms need to be loaded...for something like a "teleport pad"
then there's "room links" between the two rooms (so it loads the
destination of the "teleport", even though it might be on the
other side of the map :), as there's nothing necessarily about
the "room links" to mean that they have to be
spatially-orientated neighbours...

In this way, you should be able to create a massive, massive
sprawling 3D "world" but never encounter any "loading..." pauses
whilst wandering around it...it always "prefetches" the rooms
you can move to from the current "room"...and this should work
well for most games because, in reality, you actually have to
_walk_ (or run) from one room to the other and can only go to
your _spatial_ neighbours ("telepods" excepted but they are
easily worked into the scheme, anyway ;)...this buys you
sufficient time to simply load a bunch of "rooms" (again, you
_design_ the "room size" versus the time it takes to load so
that it always completes in time :) in the background using the
asynchronous loading functions...

Well, it's an idea, anyway...and, yes, because of "Microsoft
crap coding(tm)", this wouldn't really be possible with the
floppy disk or if you needed to spin the CD up and down, as
these typically bring the entire system to a halt temporarily
while they happen...it's not really the hardware that's at fault
here but the way these things are written without taking these
considerations into mind...

Kind of appropriate in light of the "polling" discussion
because, indeed, someone using "polling" when they could be
using interrupts and DMA and blocking and other such
alternatives techniques, is exactly the kind of "who cares about
the rest of the system so long as my code works?"
old-skool-single-tasking-DOS thinking that often leads to this
kind of problem...and when _the OS_ does it, then it leads to
some very useful and clever techniques being rendered
_impossible_ (while MS's floppy drivers still operate this way,
you can't reasonably do "background loading" like that)...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"...

> >So, you have to take things with a pinch of salt...because,
> >indeed, these programmable parts on the new video cards
actually
> >use a kind of "assembly language"...and as they are "graphics
> >dedicated" then the _general-purpose_ HLLs don't make sense
for
> >this type of application...so assembly language has reclaimed
a
> >little ground there again (until they develop special
dedicated
> >graphics HLLs for the video card GPUs only and the cycle
starts
> >all over again ;)...
>
> 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...

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...

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
(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?

I mean, you _CAN_ use asynchronous loading with the hard drive
and the "ReadFileEx" functions...so why do we not see any games
that take advantage of it and rather "Loading..." pauses
appearing every five seconds? It also needs to be _taken
advantage of_ by programs, as well as being available in the
hardware itself...

But, yeah...that's why it's funny to see the floppy drive grind
everything to a halt on a PC...and then see Microsoft make a big
fuss about finally being able to "multi-task" and use
"pre-emption"...all things spoken of in "this is brand new
technology" tones...while practically every single game written
for the C64 was using the scanline interrupt to perform all
manner of multi-tasking tricks...indeed, I still maintain that
the PC architecture is _wrong_ while the video lacks an IRQ
(and, as mentioned above, even when the hardware has it, the OS
has to allow _access_ to it)...programs get structured the wrong
way around because of it...what should happen is that the "main
thread" deals with the _game_ (AI, physics, moving players and
enemies, etc. :)...and the rendering of the graphics is "on
interrupt"...this gets increasingly more important as refresh
rates don't change much, while CPU speeds double and quadruple
(the "gap" between the two widens)...

And that's not only academic pedanticism - wanting to see all
the hardware operate in the same way - but really _CAN_ make a
difference to a game...it can change the "feel" entirely (that
elusive quality of how things respond under your fingertips to
what you experience on the screen and from the
speakers...quantifying it is difficult but the human senses
_ARE_ good enough to detect millisecond differences...you might
not visibly see this but you will "feel" it...one game "feels
right", the other "feels wrong"...you can't put your finger on
it but, somehow, one game feels "distant", the other
"intimate"...it's all in the milliseconds timing :)...

I've said it before: The priorities in a computer game should
actually be 1. Input 2. Sound 3. Graphics in that order...and
this might offend some people's nature intuition because video
is surely very important...but, nope, play Dragon's Lair and all
is revealed (great graphics but pathetic gameplay, slow
reactions on the original arcade videodisc when it took seconds
to switch from scene to scene that it was totally "stuttered",
surprisingly "empty" in the sound department...most gameplayer's
conclusion: Utter crap...amazing graphics but an utter crap game
to actually play :)...

The input is the most important because, in a sense, that's
where the real game actually exists...it has to "feel right" in
the player's hands...and, top priority, it must _react_
properly...you can have the best graphics and sound in the
universe but if when that grenade flies towards your "soldier"
and you really have pressed the "jump" button in time but you
die anyway...or you really have pressed the buttons in time to
make Lara Croft jump over the gap but, regardless, the game
makes her fall to her certain death...well, when that happens,
your game has approximately 15 seconds to redeem itself before a
tantrum ensues, joysticks are thrown across the room and the
player vows "I'll never play that pile of crap ever again!"...

Sound is next...surprised? Those who make movies won't
be...goodness knows what the psychological reason actually is
but sound is a more more "intimate" sense than vision...take
away the soundtrack of spooky string music in the background as
the detective slowly creeps up on the axe-wielding maniac and it
just instantly loses its tension...with many movies, it's NOT
actually the sight of the axe-wielding maniac that's making you
feel "on edge", it's the carefully selected "dischordant"
strings the composer has put to score it...and put on a good
rocking track on your hi-fi and you just can't help tapping your
feet, if you're not tempted to get up and boogie along with
it...as I say, quite _why_ sound and music has more of an effect
than vision like this, I don't know...but it just _does_...

There's actually one computer game that really grasps the
difference in the most obvious way I've seen...try playing
"Frankie Goes To Hollywood" on a C64 emulator (note, in fact,
that this game does have some problems running on some
emulators...and the reason why helps make an earlier point: It's
because the game uses _multi-tasking_ - it features multiple
games and these appear in small "windows" (you walk your
"Frankie" character into the windows to enter the "subgames"
:) - and it's programmed with some pretty precise timing to the
original C64: Which was fixed hardware so that you typically
never encountered this problem while playing it on a real
C64...but the "emulators" aren't always cycle-accurate on things
so you need an emulator that is or one of the "fixed" versions
of the game that's out there on the 'Net :)...

Basically, it plays a bassline from "Welcome to the
Pleasuredome" in the background while you play (as most people
who lived through the '80s probably know, Frankie Goes To
Hollywood were actually a pop band...yes, they weirdly made a
computer game about a pop band...and, yes, everything thought
"oh dear, it's going to be crap!"...but, in fact, it might just
be one of the most original computer games ever written for any
machine...it's highly weird - but, then, what "plotline"
naturally emerges when asked "make a computer game about a pop
band"? Exactly: None...but the bizarreness of the idea of a "pop
band computer game" seems to have inspired some of the most
original thinking for a computer game there's ever been - but
full of variety and different "subgames" to play...anyway, yes,
Frankie were a pop band so all the music in the game are
actually renditions of their hits...so that's how I know it's
the bassline of "Welcome to the Pleasuredome"...I have the
album! ;)...

But - and I actually think this was _accidental_ but the
programmers left it in because it actually provides amazing
"atmosphere" to the game - when you do certain "tasks", then a
little window appears to tell you how many "pleasure points" you
have and what "percentage of a real person" you are (yes, this
makes no sense until you play the game...actually, it still
makes no sense after you play the game but you'll at least
understand what I mean :)...and this is accompanied by a little
tune...

Now, the point is that this tune _stops_ the main bassline
soundtrack (as I say, this was probably originally an _accident_
but a happy one that it was left in the game :)...and it just
goes silent...stone cold silent...until you walk through a door
and - BANG! - it starts the soundtrack again with, well, a bit
of a bang, in fact...

This use of silence (even though I strongly suspect it was
accidental) gives the game an amazing "atmosphere"...I can
exactly see why - if it was an accident (it was meant to
immediately restart the background music but was programmed
incorrectly) - that they decided to keep it in the game "as is"
regardless...

Oh, also, Half-life is another example from the PC...it's
actually a slightly modified Quake I engine running that
game...but it won a whole raft of "game of the year" awards
because it features an amazingly large amount of _sound_...every
character comes up and talks to you...there's all these spooky
noises and music in the background...the game actually manages a
"plot" and it works because of the _sound_...it won all those
awards because of the _atmosphere_...and it's primarily coming
from two sources: A highly atmospheric soundtrack and lots of
recorded _speech_ so the characters talk to you throughout
(makes the player feel "engaged" in the game when the scientist
talks to you about what's going on...and the subtle little
touches that if you run around in front of him, he actually
turns his head to look at you...so easy to program something
like that but makes a big difference because then it really does
feel like the characters are talking to _YOU_...you're
"engaged", the game's atmosphere has grabbed you by the collar
;) and the "plot" then engages the player...the actual "engine"
running this was dated when it first appeared...it proves the
point: Graphics mean nothing when the rest isn't right...get the
rest right and you can actually have worse graphics and still
totally get away with it ;)...

The "attention to detail" is a little extreme...I got one of
those programs to be able to look at the files inside the big
"PAK" game file and there are something like _17_ different
"scientist screaming" sounds...practically every repetitive
sound has been recorded more than once so that it can randomly
choose one of them each time and there's _variety_ in what you
hear...and the sheer amount of pre-recorded speech is basically
the largest percentage of the game...oh, and for the electronic
voices (the voice of your protection suit and the computer voice
that comes over the speakers :), they've split up the speech
into individual words and then it plays then back in whatever
order you like...the range of possible sentences you can make
with this is gigantic...BUT the "attention to detail" means that
for any of the more "human" voices, they've recorded them as one
long sample and not split up the individual words...because the
humans need to _emote_ and _intonate_ to sound realistic...the
atmosphere is simply not compromised and they've clearly sat
down and thought very hard and very long about how to get the
_sound_ to work...they were following my "priority" system and
it got numerous awards and "game of the year" titles, with
everyone playing Counterstrike as the most popular on-line game
based from the Half-life engine...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...

So, the lack of a useable video IRQ isn't merely some academic
call for all the hardware to be much the same...it's just like
how many seem to think graphics are the most important
thing...or that "Loading..." pauses appearing every five minutes
(ruining the "atmosphere" completely, reminding you you're
playing a game frequently :) are "okay"...Microsoft not thinking
or bothering about asynchronous operations...this is one of
those small, subtle points that's easily overlooked but is that
"detail" which turns a game from "good" into
"spectacular"...haven't people heard the saying? Both God and
the devil are in the details, you know ;)...

When the video is "on interrupt" then the main thread deals
exclusively with actually playing the game...when a video
interrupt happens, it renders things as they currently
are...this makes a subtle but imporant difference to the "feel"
from a game where the video is the main focus and the input
might typically be grabbed "per frame" (the "backwards" way that
PC games tend to have because of the lack of a useable video
interrupt)...the difference is subtle...it's, indeed, a "feel"
thing rather than anything you'd consciously notice...but your
subconscious hears it loud and clear...how you "feel" about the
game will actually be subtly different...

"Geez Louise, she's bloody pedantic...who's going to notice a
few milliseconds and an imperceivable difference in how the
thing 'flows'? Off her rocker, ain't she?"

Indeed, that's the attitude that typically reigns...and that's
why the floppy disk halts practically everything...why you fall
asleep to the "Loading..." pause as you walk around the "3D
landscape" (and once it exceeds a certain point, your mind
wanders to thoughts of grabbing a snack and about maybe whether
you should phone a friend later on...and - BANG! - you've
remembered you're part of the real world, the escapism is lost,
the game has _FAILED_ its most important task: Games are part of
"show biz", not science...these things are deadly important in
"show biz"...the enterance must knock them dead, the every
utterance from the script said with perfect "actor" elocution,
the editing can't be out by more than a frame or two, the
_timing_ and _rhythm_ are all-important because what is poetry
but words in rhythm? A joke without comic timing falls flat on
its face...in "show biz", you _must_ be a bit of a perfectionist
to get anywhere...it's only a tribute to just how good actors
and directors typically are with this that you might not notice
just how much detail there really is in their little constructed
"worlds"...a background set is only used once for no more than
20 seconds of "on screen" time and yet the set builders will
construct it as perfectly and down to the very last detail as
they possibly can...which, in Hollywood, no doubt, they'd blow
it up just to get a very loud explosion for no particular reason
other than "it looks cool!" ;)...

Beth :)