Namco has lost the pacman source code ?
Alexis
I say that because I have played "Namco Museum" on N64 and the pattern
that play well on Pacman/MAME just doesn't work on Pacman/N64.
Damn !
Robert Morgan
>that play well on Pacman/MAME just doesn't work on Pacman/N64.
Namco Museum 64 isn't emulation, but simulation. It's a good facsimile, but
(obviously, in your case) it isn't going to run like the original. I've no
idea why they didn't emulate the games- the N64 seems plenty powerful enough to
emulate them.
--
SIG alert... looking for a cheap Pioneer LaserActive, and a working RDI
Halcyon.
Maintainer of View-Master InteractiveVision FAQ; e-mail for latest version
(2.0.1)
.
Andrew Davie
Back in the late '80s I was responsible for porting both Pacman Jr. and
Super Pacman to the C64 - and indirectly to the PC. All we were given was a
few screen shots and a videotape - and - get this - bus fare to go to the
arcade and watch the machine being played. We were also under quite
considerable time pressure to get it out.
Anyway, I wasn't a pacman fan - and had no idea they moved in defined
patterns - so my implementations basically had a reasonable seek-and-destroy
algorithm. It worked OK - but it wasn't the same as the originals. My
point being - even though these were OFFICIAL licensed products, the source
code and algorithms were simply not available to us as programmers.
It doesn't surprise me to see other versions which had the same problems :)
Software companies aren't that organised anyway... a recent visit to the
place I used to work for shows that they simply have NO copies of the games
they made through the '80s... now there's a challenge for the collector...
games by a particular company :)
Cheers
A
"Alexis" <alexis.p...@mail.dotcom.fr> wrote in message
news:3994DBF3...@mail.dotcom.fr...
> Is there a possibility that Namco has lost the pacman source code ?
>
> I say that because I have played "Namco Museum" on N64 and the pattern
> that play well on Pacman/MAME just doesn't work on Pacman/N64.
>
> Damn !
John in NH
>Well this rings a bell with me.
>Back in the late '80s I was responsible for porting both Pacman Jr. and
>Super Pacman to the C64 - and indirectly to the PC. All we were given was a
>few screen shots and a videotape - and - get this - bus fare to go to the
>arcade and watch the machine being played.
Heh. Didn't they at least give you a roll of quarters? ;)
Thanx for the input. Always cool to hear from those who were on the "front
line." MMM. . . now THERE'S a good game!
~~~
Offering quality Atari wares on eBay as:
http://members.ebay.com/aboutme/rush...@aol.com/
Proud member of VAPS:
http://www.vaps.org/members/nh/rush...@aol.com.html
Cameron Kaiser
>a recent visit to the
>place I used to work for shows that they simply have NO copies of the games
>they made through the '80s...
Activision actually had to get .d64 copies of their old C64 games and old
copies from Commodore used software dealers when they made the C64 15-Pack.
(The vendors who helped them reconstruct their connection are credited in
the CD's help file.) I was shocked they didn't archive at least a *couple*
disks. :-P
--
Cameron Kaiser * cka...@stockholm.ptloma.edu * posting with a Commodore 128
personal page: http://www.armory.com/~spectre/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/~spectre/cwi/ **
Glenn Saunders
<cka...@stockholm.ptloma.edu> wrote:
>(The vendors who helped them reconstruct their connection are credited in
>the CD's help file.) I was shocked they didn't archive at least a *couple*
>disks. :-P
Most game companies have very little interest in formally archiving
their work or documenting their history. It's always on to the next
milestone for the next product cycle.
However, INDIVIDUALS within the game industry often do take an
interest in preserving their work. Not always, but sometimes. That's
where these things get saved, often barely--when stuff is being thrown
out into dumpsters.
Robert L. Swackhamer
pure...@cs.comfrobozz (Robert Morgan) wrote:
> >I say that because I have played "Namco Museum" on N64 and the pattern
> >that play well on Pacman/MAME just doesn't work on Pacman/N64.
>
> Namco Museum 64 isn't emulation, but simulation. It's a good facsimile, but
> (obviously, in your case) it isn't going to run like the original. I've no
> idea why they didn't emulate the games- the N64 seems plenty powerful
enough to
> emulate them.
The PlayStation (and quite possibly Dreamcast) versions are the same way.
Also some of the later Midway classics sets use simulations instead of
emus (Roadblasters and Paperboy are two examples).
The other thing that always bothered me by the US versions of the Namco
Museums was no form of localization whatsoever. While the only games
really affected were Pole Position I & II, there was quite a bit of unique
memoribilia that should have been put in that was US released. Just some
of the US Pac-Man stuff alone could of had it's own hall in the game.
There's two possible reasons why Namco decided to use sims instead of
emus, 1) They had their game listing all planned out, and found that the
target platform (PSX at the time) could not reliably emulate later games
like Legend of Valkyrie, Assualt, and others. So simulations were used
instead, 2) laziness.
I may have to check out the DC version of Namco Museum later today. See
if it's sim or emu.
The Most Dangerous Reverend
Robert L. Swackhamer
Gaplus? They forgot motherf**king Gaplus!?!
Robert Morgan
>Museums was no form of localization whatsoever.
Then again, it *is* interesting to see the Japanese side of things. We have
(relatively) easy access to US stuff, but much of the memoribilia in the
Museums was brand new to me.
>1) They had their game listing all planned out, and found that the
>target platform (PSX at the time) could not reliably emulate later games
>like Legend of Valkyrie, Assualt, and others. So simulations were used
>instead
> 2) laziness.
There's a one good reason to not use emus- it keeps people from having the
legal right to have MAME roms of the games. A simulated version would nullify
the excuse of a MAME rom being a "back-up".
Plus, to be honest, even an emulation- due to timing issues and everything-
isn't going to be exactly like the original arcade game. I've heard people say
that some arcade patterns won't work on their emulated counterparts. By
skipping the emulation process, too, the programmers can make slightly
non-optimal games work on a given system that wouldn't be powerful enough to
directly emulate the code.
Robert L. Swackhamer
pure...@cs.comfrobozz (Robert Morgan) wrote:
> >The other thing that always bothered me by the US versions of the Namco
> >Museums was no form of localization whatsoever.
>
> Then again, it *is* interesting to see the Japanese side of things. We have
> (relatively) easy access to US stuff, but much of the memoribilia in the
> Museums was brand new to me.
On the flip side of that argument, we had stuff they (Namco Japan) might
not have thought of (AFAWK). I mean, we had Pac-Man vitamins for Christ's
sake! VITAMINS! :)
> >1) They had their game listing all planned out, and found that the
> >target platform (PSX at the time) could not reliably emulate later games
> >like Legend of Valkyrie, Assualt, and others. So simulations were used
> >instead
> > 2) laziness.
>
> There's a one good reason to not use emus- it keeps people from having the
> legal right to have MAME roms of the games. A simulated version would nullify
> the excuse of a MAME rom being a "back-up".
I'm not sure how well that would hold up in court. If we were talking
about the official PC released emus (Microsoft Classic Arcade, Williams
Greatest Hits, etc.), then I could see it. But if it was PSX or DC
versions, because they are on such a radically different platform that PCs
than an argument of "cross-conversion" could be brought up. The rights of
backup may only be dependent to that particular platform. [1]
> Plus, to be honest, even an emulation- due to timing issues and everything-
> isn't going to be exactly like the original arcade game. I've heard
people say
> that some arcade patterns won't work on their emulated counterparts. By
> skipping the emulation process, too, the programmers can make slightly
> non-optimal games work on a given system that wouldn't be powerful enough to
> directly emulate the code.
I have noticed that emus are not always perfect (Ms. Pac-Man is one good
example). But I would rather have a not-quite perfect emulation of a game
than a even less-than perfect simulation.
The Most Dangerous Reverend
Robert L. Swackhamer
VITAMINS! :)
Bruce Tomlin
> I'm not sure how well that would hold up in court. If we were talking
> about the official PC released emus (Microsoft Classic Arcade, Williams
> Greatest Hits, etc.), then I could see it. But if it was PSX or DC
> versions, because they are on such a radically different platform that PCs
> than an argument of "cross-conversion" could be brought up. The rights of
> backup may only be dependent to that particular platform. [1]
So what if someone came up with a version of MAME which could read the
appropriate sector from the CD-ROM into memory, and then run that?
Robert L. Swackhamer
bruce+...@NOSPAMfanboy.net (Bruce Tomlin) wrote:
It could be done, but I don't think the time-value ratio would be worth
it. It's a lot easier to pick these ROMs up off the 'Net than people
think it is.
The Most Dangerous Reverend
Robert L. Swackhamer
[1] Forgot to put this in the other post, but I was going to say "If you
follow my line of in spite of my writing, then give yourself a cookie." :)
Alexis
> Most game companies have very little interest in formally archiving
> their work or documenting their history. It's always on to the next
if Namco still had /The Pacman Source Code/, could they use it to get
the port done ?
If it is C code, obviously yes, any N64 devkit would do.
If it is assembler, I don't know.
Still, once the port is done, will it play the same, or some subtle
technical stuff would modify the ghosts move (V.refresh, etc...) ?
in an unpredictable way ?
Snk2112
dc namco
n 84 namco
i know for a fact and have
genesis williams greatest (close but not good enough for me _)
williams arcade greatest hit 2
atari collection ( i knowe vector asteroids is impossible )
N E S donkey kong and classicc's has faults ...
hows excitbike 64's? i like it but didn't get into the original enough to
know if there was any changes
Danno
who'd rather win $5000 from BEN STEIN
Than $1000000 from Regis ,,,,,,,,,
don't worry ,, we're not alien spies sent to kidnap you or any thing ,,,,
"it's a HAND grenade "
Glenn Saunders
Swackhamer) wrote:
>The PlayStation (and quite possibly Dreamcast) versions are the same way.
>Also some of the later Midway classics sets use simulations instead of
>emus (Roadblasters and Paperboy are two examples).
Porting a game from the original source code is really as good as
emulation when done right, IMHO.
Glenn Saunders
<alexis.p...@mail.dotcom.fr> wrote:
>If it is assembler, I don't know.
Programming concepts transcend languages. and therefore can be
translated across languages and paltforms. That's not to say it's
easy, but it's doable.
>Still, once the port is done, will it play the same, or some subtle
>technical stuff would modify the ghosts move (V.refresh, etc...) ?
>in an unpredictable way ?
It all depends on the programmers. It can be done well. The idea is
that the game still runs the same because you have translated the code
into an analogous native format. How the code generates the graphics
and the sound may differ, but the overall game logic would remain
identical.
Robert Morgan
>the port done ?
>
>If it is C code, obviously yes, any N64 devkit would do.
I'd imagine that the original Pac-Man source was done in assembler; C, or any
interpreted language, wasn't really useful in creating fast action games on
such low-speed processors.
(I'm still perturbed by the use of C to make games today... is assembly/ML
really that difficult to do nowadays?)
Robert L. Swackhamer
I have say about this port...
<DENIS LEARY>
Fuck, is this game awful!
Here's a game by game:
Pole Position: don't bother. Looks like shit and plays about as well with
the DC analog stick. Go find an arcade that's got this game.
Dig Dug: music was way off (too damn high), and doesn't even show the
whole screen. Whoever thought to actually include a screen scroll option
should not be allowed to breed. Or program for that matter.
Ms. Pac-Man: music again was too damn high. And the graphics looked like
shit. Instead of turning corners at 90 degree angles like in the arcade,
she actually slides around corners! What the hell is up with that?!?
Pac-Man: See above
Galaga: About the only decent game in this mess, and that doesn't add up
to much. Very few of the patterns of the ships were in there. Graphics
were still bad.
Galaxian: didn't bother.
And guess what? No fucking museum!
Last word: don't spend $30+ on this piece of shit. Get MAME and play it
the way it was fucking meant to.
</DENIS LEARY>
Right now some of you are thinking "Jeez Robert, tell us how you really
feel." But this is how I feel about this game. Namco should be ashamed
to have allowed this garbage to get on store shelves. It's that bad. It
wasn't even programmed by Namco, but a company called Mass Media (danger
Will Robinson! Danger!). What Namco was thinking I'll never know.
Two interesting tidbits: there is a saveable mini-game for the VMUs.
Don't know what it was since the batteries in my VMU are dead. The other
thing is the opening music to the disc. It has the Pac-Man start tune
along with a dance drum rythmn. The funny thing is that it sounds exactly
like the Pac-Man sample bit from the Bloodhound Gang song "Mope" (the one
that has a pitchshifted Pac-Man smoking crack). Drum loop and
everything. I was expecting the first lines of the chorus to come in
after that!
But do not buy this game. If you want a good console version of the
classics, pick up the Namco Museums for the PSX. Much better job done on
that conversion, and there is historical items to view also.
The Most Dangerous Reverend
Robert L. Swackhamer
Deader than the parents on the Party of Five!
Bruce Tomlin
> In article <bruce+usenet2-1...@atuin.bruce>,
> bruce+...@NOSPAMfanboy.net (Bruce Tomlin) wrote:
>
> > In article <reverendhammer-...@c679365-c.wtrlo1.ia.home.com>,
> > reveren...@home.com (Robert L. Swackhamer) wrote:
> >
> > > I'm not sure how well that would hold up in court. If we were talking
> > > about the official PC released emus (Microsoft Classic Arcade, Williams
> > > Greatest Hits, etc.), then I could see it. But if it was PSX or DC
> > > versions, because they are on such a radically different platform that PCs
> > > than an argument of "cross-conversion" could be brought up. The rights of
> > > backup may only be dependent to that particular platform. [1]
> >
> > So what if someone came up with a version of MAME which could read the
> > appropriate sector from the CD-ROM into memory, and then run that?
>
> It could be done, but I don't think the time-value ratio would be worth
> it. It's a lot easier to pick these ROMs up off the 'Net than people
> think it is.
I'm not talking about ease. I'm talking about a way in which nobody could
bitch about MAME being "only for piracy" and running illegal copies of
ROMs.
Brien King
write, however, if you need to make a lot of changes it becomes more
difficult than say C. With today's compilers (Watcom comes to mind) and
today's processors, its become less necessary to use assembly as the
compilers can generate better assembly than the average programmer. C/C++
also makes the games more portable. Doom is a perfect example of this. 99%
of it was C. Only two routines where written in Assembler and thats because
speed was critical.
Remember they didn't have really cool tools like we do today either.
Debuggers? Non-existent.
--
Brien King
Arcade Game Collector, Phoenix, AZ
bk...@arcaderestoration.com
===============================================================
Arcade Restoration Workshop @ http://www.arcaderestoration.com
Dedicated to the restoration and preservation of video games.
===============================================================
"jt august" <star...@worldnet.att.net> wrote in message
news:starsaber-130...@187.st-louis-113-114rs.mo.dial-access.att.ne
t...
> In article <20000813041949...@ng-fd1.news.cs.com>,
> pure...@cs.comfrobozz (Robert Morgan) wrote:
>
> > I'd imagine that the original Pac-Man source was done in assembler; C,
or any
> > interpreted language, wasn't really useful in creating fast action games
on
> > such low-speed processors.
> > (I'm still perturbed by the use of C to make games today... is
assembly/ML
> > really that difficult to do nowadays?)
>
> Yup. I've not delved into it, but I am told that PPC doing on Macs is
> virually impractical for almost all programming projects, so I imagine it
> is similarly tedius for Pentiums and their compatibles, and the current
> generation consoles.
>
> --
> The Starsabre is a British blade. Please reverse the r and e
> to reply to me directly.
jt august
Davie" <ada...@taswegian.com> wrote:
> a recent visit to the
> place I used to work for shows that they simply have NO copies of the games
> they made through the '80s... now there's a challenge for the collector...
> games by a particular company
Actually, it is a plus for the emulators community. Without having
records proving they produced the games in the first place, including not
even having copies, how could they possibly consider emulators a threat to
their marketing. The emulation community is predominantly interested in
preserving these games that they didn't even keep one copy of?
So, do Activition, Sierra and other still surviving companies still have
copies and sources to their classic products? If not, how would they
respond to people copying these things today?
jt august
<alexis.p...@mail.dotcom.fr> wrote:
> if Namco still had /The Pacman Source Code/, could they use it to get
> the port done ?
>
> If it is C code, obviously yes, any N64 devkit would do.
>
> If it is assembler, I don't know.
C did not exist back in 79. It was assembler, most assuredly.
jt august
pure...@cs.comfrobozz (Robert Morgan) wrote:
> I'd imagine that the original Pac-Man source was done in assembler; C, or any
> interpreted language, wasn't really useful in creating fast action games on
> such low-speed processors.
> (I'm still perturbed by the use of C to make games today... is assembly/ML
> really that difficult to do nowadays?)
Yup. I've not delved into it, but I am told that PPC doing on Macs is
virually impractical for almost all programming projects, so I imagine it
is similarly tedius for Pentiums and their compatibles, and the current
generation consoles.
--
Mike Mattox
<alexis.p...@mail.dotcom.fr> wrote:
>Is there a possibility that Namco has lost the pacman source code ?
>
>I say that because I have played "Namco Museum" on N64 and the pattern
>that play well on Pacman/MAME just doesn't work on Pacman/N64.
>
>Damn !
No. The namco museums are NOT emulating the original games. I picked
it up for my Dreamcast. The sound and animation for Ms. Pac-Man and
Pac-Man are WAY off. there is no full screen version like the PSX
versions had. Namco is slacking.
mneko
the Dreamcast... they're already burying it in turds like Mr.
Driller and the aforementioned Namco Museum. Thanks for the
heads-up... I can think of at least one Dreamcast game I WON'T
be buying now that I know what Namco's trying to pull. C'mon,
guys... either give us a home version of Pac-Man Arranged or
don't even bother with the series.
JR
-----------------------------------------------------------
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
Subatomic Brainfreeze
>the Dreamcast...
Not fair to say that. The differences between the PS version and the
originals are equally huge. [does the DC version have that cool
stat-tracking on it?]
Subatomic Brainfreeze
"You operate under the delusion that your insouciance protects you from my wrath.
It doesn't."
Vincent, Clerks comic book
genkai wa doko da
access.att.net>,
star...@worldnet.att.net (jt august) wrote:
> In article <39960539...@mail.dotcom.fr>, Alexis
> <alexis.p...@mail.dotcom.fr> wrote:
>
> > if Namco still had /The Pacman Source Code/, could they use it to
get
> > the port done ?
> >
> > If it is C code, obviously yes, any N64 devkit would do.
> >
> > If it is assembler, I don't know.
>
> C did not exist back in 79. It was assembler, most assuredly.
>
While it was in asm for sure, I'm curious how Unix was rewritten in C
in 1972 if C didn't exist yet? Also someone mentioned debuggers not
existing in '79 I'm not sure about C but I remember reading about
debuggers for DEC pdp-1 (vintage 1961) in the classic book 'Hackers'
(nice documentation of the first 'real' video game 'Space War'). I'd
find it hard to believe there weren't C debuggers by 1979 with crews at
Bell Labs and Berkeley working so deeply on Unix at this time.
gauze
--
------
www.rifug.org
Rhode Island Free Unix Group
Atari 26/52/7800/Jaguar/400/800/XE,Intellivision,
Sent via Deja.com http://www.deja.com/
Before you buy.
Otter
> In article <starsaber-130...@187.st-louis-113-114rs.mo.dial-
> access.att.net>,
> star...@worldnet.att.net (jt august) wrote:
> > In article <39960539...@mail.dotcom.fr>, Alexis
> > <alexis.p...@mail.dotcom.fr> wrote:
> >
> > > if Namco still had /The Pacman Source Code/, could they use it to
> get
> > > the port done ?
> > >
> > > If it is C code, obviously yes, any N64 devkit would do.
> > >
> > > If it is assembler, I don't know.
> >
> > C did not exist back in 79. It was assembler, most assuredly.
> >
>
If Namco were to do this port of Pac-Man, do you think Hasbro would try
to stop them? :)
-- Otter
(Or does Hasbro already own Namco?)
jt august
<ga...@my-deja.com> wrote:
> In article <starsaber-130...@187.st-louis-113-114rs.mo.dial-
> access.att.net>,
> star...@worldnet.att.net (jt august) wrote:
> > In article <39960539...@mail.dotcom.fr>, Alexis
> > <alexis.p...@mail.dotcom.fr> wrote:
> >
> > > if Namco still had /The Pacman Source Code/, could they use it to
> get
> > > the port done ?
> > >
> > > If it is C code, obviously yes, any N64 devkit would do.
> > >
> > > If it is assembler, I don't know.
> >
> > C did not exist back in 79. It was assembler, most assuredly.
> >
>
> While it was in asm for sure, I'm curious how Unix was rewritten in C
> in 1972 if C didn't exist yet? Also someone mentioned debuggers not
> existing in '79 I'm not sure about C but I remember reading about
> debuggers for DEC pdp-1 (vintage 1961) in the classic book 'Hackers'
> (nice documentation of the first 'real' video game 'Space War'). I'd
> find it hard to believe there weren't C debuggers by 1979 with crews at
> Bell Labs and Berkeley working so deeply on Unix at this time.
OK, I may have been wrong about C not existing, but it was definately not
common. I never heard of C until somewhere well into the 80's.
And on debuggers, there have been various implementations as far back as
Apple ][+ assemblers. Debuggers can vary on how they operate, but they
have existed at least back that far, and I'm sure main framers had it even
before that.
genkai wa doko da
<starsaber-170...@147.st-louis-108-109rs.mo.dial-access.att.net>,
star...@worldnet.att.net (jt august) wrote:
> OK, I may have been wrong about C not existing, but it was definately
not
> common. I never heard of C until somewhere well into the 80's.
depends on what you mean by common I suppose, it was pretty big in the
minicomputer world (pdp-7,11,VAX), but not in Mainframe and
Microcomputers (well, later on on micros).
>
> And on debuggers, there have been various implementations as far back
as
> Apple ][+ assemblers. Debuggers can vary on how they operate, but
they
> have existed at least back that far, and I'm sure main framers had it
even
> before that.
according to that book Hackers I mentioned before
the pdp-1 was a minicomputer (in 1961 terms) and DEC included a debugger
with it but the students at MIT wrote their own version, all of this
software was stored on paper tape and kept in a drawer next to the
machine for everyone to share and modify and improve, probably the first
case of Open Source Software, and the inspiration for GNU!
I wouldn't doubt if debuggers date from the mid-50s or earlier here is a
quote that would lead me to believe this:
As soon as we started programming, we found to our surprise that it
wasn't as easy to get programs right as we had thought. Debugging had
to be discovered. I can remember the exact instant when I realized
that a large part of my life from then on was going to be spent in
finding mistakes in my own programs.
-- Maurice Wilkes discovers debugging, 1949
ok so a bit off topic, but I like history :-)
gauze
--
------
www.rifug.org
Rhode Island Free Unix Group
Atari 26/52/7800/Jaguar/400/800/XE,Intellivision
Glenn Saunders
august) wrote:
>OK, I may have been wrong about C not existing, but it was definately not
>common. I never heard of C until somewhere well into the 80's.
C wan't common. Most home computer users were programming in Basic or
Assembly. C was harder to learn and I think took a much larger memory
footprint than Basic to compile, and not as popular as a simple
interpreter like Basic.
However, I'm sure it was being used in the mainframe and minicomputer
world.
But as for GAME development, nobody used high level languages for some
time on arcade games. I think one of the first was the aborted Ms.
Gorf which used a variant of Forth, and later on Atari Games used
another wacky language on games like APB.
Not only was memory constrained, but speed was as well. Assembly was
necessary to keep the final ROMs small and effecient.
Plus, ANSI C really isn't well suited for graphical programming on
highly proprietary hardware. It doesn't talk to hardware very
directly. It has standard libraries for disk I/O, printing lines, and
maybe VT100 curses. It's really more for computer programs, not
dedicated game machines. Once you get to the piont where you are
writing custom libraries to glue C to the hardware you might as well
have written it in assembly. It makes sense today because hardware is
so complicated that APIs and drivers simplify the task of talking to
the hardware. So C for the Playstation, for instance, makes sense.
But even today assembly is often used to speed things up. 33MHZ
R3000s aren't really that fast by today's standards.
sear...@my-deja.com
I guess that Namco losing the source code would explain a lot. Not just
the bad simulations, but the curious and apparent failure to put a
damper on the M.A.M.E. movement.
And they obviously figured that exact replica's of the classic games
were unnecessary because of the younger market they thought they were
aiming for.
When I decided to get back into competitive play(on Ms.Pacman first)
after a 14 year absence, I pondered picking up one of the various
systems as opposed to the actual arcade game so I could practice. I
learned that the copies were anything but perfect. So now I have a full
sized original in my apartment.
I see now that if I had programming knowledge, I could have created an
indistinguishable copy of the original game, based soley on what I've
learned from playing it. Nevertheless, I really would appreciate help
in conquering a problem(obsession), that has plaque me for a decade and
a half. Let me explain;
I'm one of only three people alive who have officially scored over
900,000 points(during official tournaments). We knew(and know) exactly
how all four monsters in the game behaved, which was dependant on their
individual habits, in combination with their relative positions and
directions to each other(and Ms.Pacman), which was also dependant on
their exact positions in which part of the four mazes you were playing,
and number of dots left(which influenced speeds as well as when the
fruit would come out). So several master players across the country
(including I) had figured out when and where to move in order to get
the monsters to do what we wanted while we cleared each maze. We knew
everything there was to know about the gameplay and had conquered
Ms.Pacman in every respect except one... We were baffled as to the
exact mechanisms involved in the "random factor". We leapfrogged each
other's world records for a while. After we were able to reach the
"end"(Kill-screen) of the game, the record holder was pretty much
chosen by the law of odds. In other words one's high score was
dependant on the amount of points the machine gave you via the "random"
fruit over the course of the game.
At the time, it was impossible for any of us to find(let alone talk to)
any of the game's original programmers. So if it true that Namco no
longer has the source code, then I'd appreciate any advice on where to
turn next.
By the way, for what it is worth, I've(for totally unrelated reasons)
decided to learn assembler.(I want to eventually develop my own
programming language).
Darren Harris (Sear...@mail.con2.com)
************************************************************************
In article <starsaber-130...@187.st-louis-113-114rs.mo.dial-
access.att.net>,
star...@worldnet.att.net (jt august) wrote:
> --
> The Starsabre is a British blade. Please reverse the r and e
> to reply to me directly.
>
Subatomic Brainfreeze
> The emulation community is predominantly interested in
>preserving these games that they didn't even keep one copy of?
That's where the split lies, however. Some emu people want
preservation, others want to move into warez. This doesn't affect
those who want preservation in any legitimate way. However, the ones
who want emulation as warez are in some cases also interested in
making cash off it. But.... they are never, ever the people targeted
by the tirades against the community that the IDSA used to embark on.
Rather, the previously mentioned image is used as a scapegoat.
Perhaps companies are keeping emulation quiet so they can sell it
later.... Sega did this with KGen, as I recall, paying its author to
write them an emu for a classics pack.
Erik Mooney
>And they obviously figured that exact replica's of the classic games
>were unnecessary because of the younger market they thought they were
>aiming for.
This is certainly true from a business standpoint at least - a perfect
replica would not generate enough additional sales to warrant the time
and expense of making it perfect.
>When I decided to get back into competitive play(on Ms.Pacman first)
>after a 14 year absence, I pondered picking up one of the various
>systems as opposed to the actual arcade game so I could practice. I
>learned that the copies were anything but perfect. So now I have a full
>sized original in my apartment.
MAME should be perfect, assuming your computer can run it at full speed,
you can tolerate the slight inaccuracies in sound reproduction, and
aren't bothered by using a controller other than an arcade joystick
>I'm one of only three people alive who have officially scored over
>900,000 points(during official tournaments). We knew(and know) exactly
>how all four monsters in the game behaved, which was dependant on their
>individual habits, in combination with their relative positions and
>directions to each other(and Ms.Pacman), which was also dependant on
>their exact positions in which part of the four mazes you were playing,
>and number of dots left(which influenced speeds as well as when the
>fruit would come out). So several master players across the country
>(including I) had figured out when and where to move in order to get
>the monsters to do what we wanted while we cleared each maze. We knew
>everything there was to know about the gameplay and had conquered
>Ms.Pacman in every respect except one... We were baffled as to the
>exact mechanisms involved in the "random factor". We leapfrogged each
It's almost certainly a pseudorandom number generator in the code, good
enough to not be predictable at all on a high level.
>other's world records for a while. After we were able to reach the
>"end"(Kill-screen) of the game, the record holder was pretty much
>chosen by the law of odds. In other words one's high score was
>dependant on the amount of points the machine gave you via the "random"
>fruit over the course of the game.
>
>At the time, it was impossible for any of us to find(let alone talk to)
>any of the game's original programmers. So if it true that Namco no
>longer has the source code, then I'd appreciate any advice on where to
>turn next.
If you've got an arcade machine, or MAME with the Ms Pac ROMs, you've
got the source code right there. The original game was surely written
in assembly to start with. Simply disassemble that, and you've got
something pretty darn close to the original source. It'd be missing the
names of variables and memory locations, and anything like macros in the
original source would be unrolled/expanded, but one could certainly code
a replica of Ms Pac (or almost any pre-1984 video game) by examining the
assembly code and precisely duplicating its workings.
Erik Mooney
<cybp...@earthlink.net> wrote:
>On Sun, 13 Aug 2000 02:02:56 GMT, Alexis
><alexis.p...@mail.dotcom.fr> wrote:
>>If it is assembler, I don't know.
>
>Programming concepts transcend languages. and therefore can be
>translated across languages and paltforms. That's not to say it's
>easy, but it's doable.
>
>>Still, once the port is done, will it play the same, or some subtle
>>technical stuff would modify the ghosts move (V.refresh, etc...) ?
>>in an unpredictable way ?
>
>It all depends on the programmers. It can be done well. The idea is
>that the game still runs the same because you have translated the code
>into an analogous native format. How the code generates the graphics
>and the sound may differ, but the overall game logic would remain
>identical.
For something like Pac-man patterns to remain intact over a porting like
that, one needs to take _extreme_ care to duplicate the original
_exactly_. Those patterns are dependent on every single ghost being at
exactly the same pixel location as the original in absolutely every
frame. And you have to make it respond _exactly_ the same to player
inputs as the original does. Even something as subtle as the PC having
an interrupt-driven input system as opposed to the original arcade's
polling input system can blow away any possibility of retaining the
patterns. It would've taken a _lot_ more effort than it would've been
worth on Namco's part, so they didn't bother.
Erik Mooney
>
>I talk to quite a few top players and record holders on various games,
>and the common consensus is that the M.A.M.E. games aren't exactly the
>same as the arcade games they emulate, but in most cases they are good
>enough and are usually indistinguishable from the original.
The gameplay would be perfectly identical. The only differences are in
the environment - most notably the user input device, as well as things
like a different screen resolution and less than perfect palette and
sound reproductions.
>So, assuming I learn assembly, I'll know how to go about disassembling
>the code?
Well, actually disassembling the ROM code is pretty easy... I'm not sure
what CPU Ms Pac uses (I think it's a Z80, as were most games of the
time), but pretty much any disassembler for that CPU's machine language
should be able to disassemble the ROM and show you the code.
>I assume that I won't have to worry about memory locations, and macros
>in the original source, but what do you mean by the names of variables?
Well, that was a bit misleading in the way I phrased it. In assembly
language, a memory location and a variable are one and the same. In the
original source, there would almost surely be something to the effect of
DEFINE GHOST1_X 80 , and any code in the program that references Ghost
1's X coordinate would use that define. An example would be to process
a ghost going through the tunnel and reappearing on the other side. In
the source code, it'd look something like IF [GHOST1_X] < 0 THEN
[GHOST1_X] = 160 . The assembler substitutes for all occurrences of
"GHOST1_X" (which the CPU wouldn't understand) for 80 (which the CPU
understands.) Then, once the code was disassembled, it'd read IF [80] <
0 THEN [80] = 160. (Yes, I know that's a BASIC statement, not assembly,
but it illustrates the point.) To fully decipher the code, you'd need
to go through it and figure out exactly what all of the memory locations
mean.
>Darren Harris (Sear...@mail.con2.com)
>
>P.S: Perhaps I should try getting in touch with the M.A.M.E.
>programmers?
Can't hurt to try, but remember that they already get tons of mail I'm
sure. And also remember that it's very possible to write an emulator
for a game without knowing exactly how the emulated program works; in
fact, that's rather the point of emulation. Whoever wrote the Ms Pac
driver for MAME doesn't necessarily know much of anything about how the
program works -- and may not remember much of what he did know four
years ago when it was actually written.
sear...@my-deja.com
I talk to quite a few top players and record holders on various games,
and the common consensus is that the M.A.M.E. games aren't exactly the
same as the arcade games they emulate, but in most cases they are good
enough and are usually indistinguishable from the original.
So, assuming I learn assembly, I'll know how to go about disassembling
the code?
I assume that I won't have to worry about memory locations, and macros
in the original source, but what do you mean by the names of variables?
Nevertheless the only important thing to me is finding out everything
about the "random factor". So far we suspect that a random number
generator controlled by the clock(which shifts the possibilities every
1/60th of a second), and the changes in direction(joystick) are all
factors which determine the outcome.
Darren Harris (Sear...@mail.con2.com)
P.S: Perhaps I should try getting in touch with the M.A.M.E.
programmers?
************************************************************************
In article <c4aspsg3lt5e39l76...@news.alt.net>,
Erik Mooney <emo...@SPAMFILTERattila.stevens-tech.edu> wrote:
> On Sat, 19 Aug 2000 01:30:36 GMT, sear...@my-deja.com wrote:
>
> >And they obviously figured that exact replica's of the classic games
> >were unnecessary because of the younger market they thought they were
> >aiming for.
>
> This is certainly true from a business standpoint at least - a perfect
> replica would not generate enough additional sales to warrant the time
> and expense of making it perfect.
>
> >When I decided to get back into competitive play(on Ms.Pacman first)
> >after a 14 year absence, I pondered picking up one of the various
> >systems as opposed to the actual arcade game so I could practice. I
> >learned that the copies were anything but perfect. So now I have a
full
> >sized original in my apartment.
>
> MAME should be perfect, assuming your computer can run it at full
speed,
> you can tolerate the slight inaccuracies in sound reproduction, and
> aren't bothered by using a controller other than an arcade joystick
>
> >I'm one of only three people alive who have officially scored over
> >900,000 points(during official tournaments). We knew(and know)
exactly
> >how all four monsters in the game behaved, which was dependant on
their
> >individual habits, in combination with their relative positions and
> >directions to each other(and Ms.Pacman), which was also dependant on
> >their exact positions in which part of the four mazes you were
playing,
> >and number of dots left(which influenced speeds as well as when the
> >fruit would come out). So several master players across the country
> >(including I) had figured out when and where to move in order to get
> >the monsters to do what we wanted while we cleared each maze. We knew
> >everything there was to know about the gameplay and had conquered
> >Ms.Pacman in every respect except one... We were baffled as to the
> >exact mechanisms involved in the "random factor". We leapfrogged each
>
> It's almost certainly a pseudorandom number generator in the code,
good
> enough to not be predictable at all on a high level.
>
> >other's world records for a while. After we were able to reach the
> >"end"(Kill-screen) of the game, the record holder was pretty much
> >chosen by the law of odds. In other words one's high score was
> >dependant on the amount of points the machine gave you via the
"random"
> >fruit over the course of the game.
> >
> >At the time, it was impossible for any of us to find(let alone talk
to)
> >any of the game's original programmers. So if it true that Namco no
> >longer has the source code, then I'd appreciate any advice on where
to
> >turn next.
>
> If you've got an arcade machine, or MAME with the Ms Pac ROMs, you've
> got the source code right there. The original game was surely written
> in assembly to start with. Simply disassemble that, and you've got
> something pretty darn close to the original source. It'd be missing
the
> names of variables and memory locations, and anything like macros in
the
> original source would be unrolled/expanded, but one could certainly
code
> a replica of Ms Pac (or almost any pre-1984 video game) by examining
the
> assembly code and precisely duplicating its workings.
>
sear...@my-deja.com
Thanks a lot.
Darren Harris (Sear...@mail.con2.com)
************************************************************************
In article <8qiups0dh4o0idgcv...@news.alt.net>,
Erik Mooney <emo...@SPAMFILTERattila.stevens-tech.edu> wrote:
> >Thanks a lot.
> >
> >I talk to quite a few top players and record holders on various
games,
> >and the common consensus is that the M.A.M.E. games aren't exactly
the
> >same as the arcade games they emulate, but in most cases they are
good
> >enough and are usually indistinguishable from the original.
>
> The gameplay would be perfectly identical. The only differences are
in
> the environment - most notably the user input device, as well as
things
> like a different screen resolution and less than perfect palette and
> sound reproductions.
>
> >So, assuming I learn assembly, I'll know how to go about
disassembling
> >the code?
>
> Well, actually disassembling the ROM code is pretty easy... I'm not
sure
> what CPU Ms Pac uses (I think it's a Z80, as were most games of the
> time), but pretty much any disassembler for that CPU's machine
language
> should be able to disassemble the ROM and show you the code.
>
> >I assume that I won't have to worry about memory locations, and
macros
> >in the original source, but what do you mean by the names of
variables?
>
> Well, that was a bit misleading in the way I phrased it. In assembly
> language, a memory location and a variable are one and the same. In
the
> original source, there would almost surely be something to the effect
of
> DEFINE GHOST1_X 80 , and any code in the program that references Ghost
> 1's X coordinate would use that define. An example would be to
process
> a ghost going through the tunnel and reappearing on the other side.
In
> the source code, it'd look something like IF [GHOST1_X] < 0 THEN
> [GHOST1_X] = 160 . The assembler substitutes for all occurrences of
> "GHOST1_X" (which the CPU wouldn't understand) for 80 (which the CPU
> understands.) Then, once the code was disassembled, it'd read IF
[80] <
> 0 THEN [80] = 160. (Yes, I know that's a BASIC statement, not
assembly,
> but it illustrates the point.) To fully decipher the code, you'd need
> to go through it and figure out exactly what all of the memory
locations
> mean.
>
> >Darren Harris (Sear...@mail.con2.com)
> >
> >P.S: Perhaps I should try getting in touch with the M.A.M.E.
> >programmers?
>
> Can't hurt to try, but remember that they already get tons of mail I'm
> sure. And also remember that it's very possible to write an emulator
> for a game without knowing exactly how the emulated program works; in
> fact, that's rather the point of emulation. Whoever wrote the Ms Pac
> driver for MAME doesn't necessarily know much of anything about how
the
> program works -- and may not remember much of what he did know four
> years ago when it was actually written.
>
jt august
<emo...@SPAMFILTERattila.stevens-tech.edu> wrote:
> >Thanks a lot.
> >
> >I talk to quite a few top players and record holders on various games,
> >and the common consensus is that the M.A.M.E. games aren't exactly the
> >same as the arcade games they emulate, but in most cases they are good
> >enough and are usually indistinguishable from the original.
>
> The gameplay would be perfectly identical. The only differences are in
> the environment - most notably the user input device, as well as things
> like a different screen resolution and less than perfect palette and
> sound reproductions.
Actually, not neccessarily. It has been noted that emu games (mame, namco
museums, etc) don't play right, and there is a scientific explaination.
Some games sync into video signals to make time based changes. But these
emus lead up to timing points along the speed of the processor's crystal.
If an arcade games cpu crystal is changed, damamged, aged or otherwise
changed to where its oscillation is altered even slightly, the relation of
the crystal timing to the video timing is changed such to effect game
play. To this end, the emulator is synthesizing the effect of the crystal
in playing the game, and if the timing is errant, the game play is
effected. In the case of MAME, it has to work on all compatible
computers, but each computer can have a different speed cpu, may or may
not be overclocked, can have any of a multitude of intervening background
processes, and is linked into a video display whose clock is also
drastically different, and prolly not the same the original arcade CRT.
Even if the game is not directly timed against the video, older graphics
systems usually had to interupt the cpu process because the ram could not
be accessed by the cpu and the video display processor at the same time.
This interuption also effects timing, and I do not know how MAME handles
this interuption effect.
And in the case of the commercial emus (Namco, AGH, etc), they just had to
get the rom to play effectively. They were not concerned with mimicking
the original hardware that precisely.
Steve Harvey
>Oh, good grief. Namco might as well be wiping their butts on
>the Dreamcast... they're already burying it in turds like Mr.
>Driller and the aforementioned Namco Museum.
Which is particularly a shame, since Namco's *first* Dreamcast release
- Soul Calibur - remains one of the most beautiful, enjoyable, and
best-designed Dreamcast games in existence. And while I've heard
Mr. Driller is good as far as block pushing puzzle games go, I expect
a little more out of a title for a 128-bit console.
Speaking of Dreamcast, any thoughts on the Midway Arcade compilation?
Might be nice having an arcade-perfect Joust to play head-to-head on a
console system. I'm also mildly curious how well Robotron and
Defender work with the DC controllers.
Robert L. Swackhamer
are a little ugly on the DC version for some reason (S-Video cable
possibly?). And Robotron is a hell of a lot more fun to play on a PSX
controller than a DC one.
The Most Dangerous Reverend
Robert L. Swackhamer
Who wants MAME DC for a better version of Ms. Pac-Man
In article <slrn8qanpo.e3...@itc001472.usitc.gov>,
steve...@geocities.com wrote:
--
Interested in trading games? Visit:
http://www.gametz.com/user/reverendhammer.html