Sign in with
Sign up | Sign in
Your question

Perl roguelike coming along

Last response: in Video Games
Share
Anonymous
August 25, 2005 12:28:00 AM

Archived from groups: rec.games.roguelike.development (More info?)

Hey, remember me? I'm building a roguelike in Perl. It might end up
being more of an Engine that's re-usable for all of my future ideas and
others', but not data-driven or even script-driven. Mainly I get some of
the tougher (and most fun) tasks out of the way that mostly every
roguelike uses.

Anyway, it's coming along. Rendering and scrolling works well (It's
curses-only right now, but I've modularized the interface system for any
ideas I may or may not get in the future.) and I'm working on map
generation. That's also coming along very nicely. I have this powerful
routine called connect that takes in a figure (room, hall, anything), an
ID of an existing room on an existing map, and the walls to match up,
and it connects it, doors and all. It mostly works and where it fails,
it's not that major. I'll probably work on generation a bit more and
then slowly add in items and monsters.

The main problem right now is speed, actually. Starting up on my AMD K6
500Mhz, 128MB RAM box (My only box.) takes anywhere from 12 to 20
seconds. After that, things are OK. Now games like crawl, nethack, tome,
angband, etc barely take a second. I know that they're compiled and I'm
using Perl and I understand that I need to identify bottlenecks and all
that. I will, in time. But are there any other magic tricks anybody
knows of to help?

Unfortunately my webhost has gone down for a while and I can't really
use dialup to host anything, not because of speed (or lack thereof), but
because I can't tie up the phone line. So there's no decent way to get
the code out there. I'm currently trying to find a place to stash a
tar.gz, so I'll have that out soonish. And maps are tough to convert
into a newsgroup-friendly format.

This isn't really on-topic with the topic or anything, but I brainstorm
a lot about making standard adventure games in a roguelike format.
Imagine playing the original Adventure or Zork (I think that's been
done, actually) with a roguelike rendering. Most of everything would
remain the same, there'd still be the breathtaking descriptions and
nethack-style extended commands (normal IF commands), but with a
roguelike rendering. It may seem like there's no point to it, but it was
just an idea. But what would be wrong with a typical adventure game with
some roguelike elements? Of course combat couldn't be the main thing. I
saw several topics here on this recently, but none really gave me any
good ideas. I'm just bringing up the fact that I'll try and keep my
roguelike engine away from being tied down to one combat style.

If anybody's really interested in this project, I'd love to hear ideas
and/or code. I'm not to comfortable with CVS and all the fancy software
management stuff, but I'd love to have a partner or something.

Though I've probably brought this up previously, are there other
downsides to using Perl besides speed? And the excuses that it isn't a
neat language aren't worthy of reply. Who can say this isn't beautiful?

$original->fill
(
from => [$data->{Ewall}[0]{Y1} + 1, $data->{Ewall}[0]{X}],
to => [$data->{Ewall}[0]{Y2} - 1,
$data->{Ewall}[0]{X} + 1],
with => "."
);
# You'd have to be totally sane to call this line noise. And nobody is
# that sane.

Bye.

P.S. If there's one thing I've learned so far, it's that design
documents aren't good till later. Brainstorms help all throughout a
project, but really, the best way (for me at least) is to just code,
then go back and think about better ways.

More about : perl roguelike coming

Anonymous
August 25, 2005 12:28:01 AM

Archived from groups: rec.games.roguelike.development (More info?)

Da-Breegster <dabreegster@gmail.com> writes:

> using Perl and I understand that I need to identify bottlenecks and all
> that. I will, in time. But are there any other magic tricks anybody
> knows of to help?

Devel::D Prof will help identify the bottlnecks.

> Though I've probably brought this up previously, are there other
> downsides to using Perl besides speed?

You can't really hide your source code; at most you can obfuscate it a bit.
That can make it hard to sell your game. Of course, if you're open sourcing
your game anyway, that's not a problem.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Anonymous
August 25, 2005 12:28:02 AM

Archived from groups: rec.games.roguelike.development (More info?)

Da-Breegster <dabreegster@gmail.com> writes:

> Hide source code!? Why would I want to do such a thing?

Who cares? The point was, *if* you wanted to do so, for whatever reason, it
would be difficult to hide Perl code.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Related resources
Anonymous
August 25, 2005 2:36:50 AM

Archived from groups: rec.games.roguelike.development (More info?)

On 2005-08-24, Sherm Pendley <sherm@dot-app.org> wrote:
> Da-Breegster <dabreegster@gmail.com> writes:
>
>> using Perl and I understand that I need to identify bottlenecks and all
>> that. I will, in time. But are there any other magic tricks anybody
>> knows of to help?
>
> Devel::D Prof will help identify the bottlnecks.
>
Yeah, I think that's one of the 'easy' ones.

>> Though I've probably brought this up previously, are there other
>> downsides to using Perl besides speed?
>
> You can't really hide your source code; at most you can obfuscate it a bit.
> That can make it hard to sell your game. Of course, if you're open sourcing
> your game anyway, that's not a problem.
>
> sherm--
>

Hide source code!? Why would I want to do such a thing? My project is
meant to be modified in any way anybody likes. And it's only as
obfuscated as it is naturally, which should be enough. Besides, the source
to games like crawl is available. It might not be easy to cheat by source
hacking, but it's do-able. I know Perl is much easier to modify on the spot.
But if somebody wants to cheat, that's their problem. And of course I'm
releasing it under the GPL. I don't plan on trying to make any money of
it.
Anonymous
August 25, 2005 3:02:36 AM

Archived from groups: rec.games.roguelike.development (More info?)

"Da-Breegster" <dabreegster@gmail.com> schrieb im Newsbeitrag
news:slrndgpmdo.44v.dabreegster@localhost.localdomain...
[snip]
> Though I've probably brought this up previously, are there other
> downsides to using Perl besides speed?

Games distributed as scripts that require a special runtime enviroment are a
nightmare from a players point-of-view.
Do you honestly expect players to install a language interpreter (+ your
favorite extension modules if you're really hardcore) just to test your RL?!
Use scripting languages the way they are supposed to be used. Writing
performance-critical engine parts in them is a bad idea. And the interpreter
should be compiled into your engine which avoids those nasty distribution
problems.

copx
Anonymous
August 25, 2005 3:02:37 AM

Archived from groups: rec.games.roguelike.development (More info?)

On 2005-08-24, copx <invalid@invalid.com> wrote:
>
> "Da-Breegster" <dabreegster@gmail.com> schrieb im Newsbeitrag
> news:slrndgpmdo.44v.dabreegster@localhost.localdomain...
> [snip]
>> Though I've probably brought this up previously, are there other
>> downsides to using Perl besides speed?
>
> Games distributed as scripts that require a special runtime enviroment are a
> nightmare from a players point-of-view.
> Do you honestly expect players to install a language interpreter (+ your
> favorite extension modules if you're really hardcore) just to test your RL?!
> Use scripting languages the way they are supposed to be used. Writing
> performance-critical engine parts in them is a bad idea. And the interpreter
> should be compiled into your engine which avoids those nasty distribution
> problems.
>
> copx
>
>

Distribution will be a problem, but not for now. This project is purely
for fun of course, so people who want to play might have to go a little
further. I'm not using many external modules at all so far. I dunno how
it'll work out on Windows, but on Unix, as long as the player has got
ncurses and perl going, it'll work fine. There are ways to bundle up the
interpreter and source into a binary, I think. It's an issue for later.
Anonymous
August 25, 2005 3:02:37 AM

Archived from groups: rec.games.roguelike.development (More info?)

"copx" <invalid@invalid.com> writes:

> Games distributed as scripts that require a special runtime enviroment are a
> nightmare from a players point-of-view.

That depends a *lot* on your target audience. If you're targeting *nix users,
it's fairly safe to assume Perl is already installed, although you'll need to
test your code thoroughly to ensure that it works against multiple versions.

Exe's can be rolled for Windows to create a standalone package that includes
the interpreter. ActiveState <http://activestate.com&gt; makes a utility for
creating such packages. Standalone Mac OS X apps can be created using Drop-
Script, or with CamelBones.

*You* may not know how to package and distribute a Perl app, but that doesn't
mean it can't be done. Not only is it possible to do, it doesn't take a lot of
effort to learn how.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Anonymous
August 25, 2005 3:02:37 AM

Archived from groups: rec.games.roguelike.development (More info?)

Da-Breegster <dabreegster@gmail.com> writes:

> I'm not using many external modules at all so far.

Curses is not a core module.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Anonymous
August 25, 2005 3:02:37 AM

Archived from groups: rec.games.roguelike.development (More info?)

"copx" <invalid@invalid.com> writes:

> I know that you can do that with almost every scripting language outthere.
> It's not rocket science you know.

Of course I know that. *You* said packaging was a problem, not me.

You're starting to sound a lot like Neo, bitching and moaning about everything
in sight. I'm not biting this time.

*PLONK*

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Anonymous
August 25, 2005 3:02:38 AM

Archived from groups: rec.games.roguelike.development (More info?)

Sherm Pendley wrote:
> "copx" <invalid@invalid.com> writes:
>
>
>>I know that you can do that with almost every scripting language outthere.
>>It's not rocket science you know.
>
>
> Of course I know that. *You* said packaging was a problem, not me.
>
> You're starting to sound a lot like Neo, bitching and moaning about everything
> in sight. I'm not biting this time.
>
> *PLONK*

Out of curiousity, anyone here know what happened to Neo? I haven't
seen any sign of him here for ages. It feels weird, to have a
newsgroup as peaceful as this one is now. ;-)


--
My projects are currently on hold, but I do have
some junk at the site below.

http://www.freewebs.com/timsrl/index.htm

--
Anonymous
August 25, 2005 5:27:44 AM

Archived from groups: rec.games.roguelike.development (More info?)

"Sherm Pendley" <sherm@dot-app.org> schrieb im Newsbeitrag
news:m2vf1v9d38.fsf@Sherm-Pendleys-Computer.local...
> *You* may not know how to package and distribute a Perl app, but that
> doesn't
> mean it can't be done. Not only is it possible to do, it doesn't take a
> lot of
> effort to learn how.

I know that you can do that with almost every scripting language outthere.
It's not rocket science you know.
However this doesn't solve any performance problems and most developers who
write their entire game in a scripting language can't seem to be bothered to
make binary stand-alone releases. So I assumed that he planned to toss a
bunch of scripts at us just like his colleagues.

copx
Anonymous
August 25, 2005 7:15:31 AM

Archived from groups: rec.games.roguelike.development (More info?)

Elethiomel <kkkk@lllllll.mmmm> writes:

> Sherm Pendley wrote:
>> Da-Breegster <dabreegster@gmail.com> writes:
>>
>>>I'm not using many external modules at all so far.
>> Curses is not a core module.
>
> Which is the distinction between "not using many external modules at
> all" and "not using any external modules at all".

The "m" that I failed to notice. :-)

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Anonymous
August 25, 2005 7:25:00 AM

Archived from groups: rec.games.roguelike.development (More info?)

"Timothy Pruett" <drakalor.tourist@gmail.com> schrieb im Newsbeitrag
news:D _8Pe.11680$1g2.6212@fe05.lga...
[snip]
> Out of curiousity, anyone here know what happened to Neo?

If you mention his name too often he might come back so please be quiet!
I think he married Volourn (
http://www.rpgcodex.com/phpBB/viewforum.php?f=17 ) and they moved to
Montana.

copx
Anonymous
August 25, 2005 7:25:01 AM

Archived from groups: rec.games.roguelike.development (More info?)

copx wrote:
> "Timothy Pruett" <drakalor.tourist@gmail.com> schrieb im Newsbeitrag
> news:D _8Pe.11680$1g2.6212@fe05.lga...
> [snip]
>
>>Out of curiousity, anyone here know what happened to Neo?
>
>
> If you mention his name too often he might come back so please be quiet!
> I think he married Volourn (
> http://www.rpgcodex.com/phpBB/viewforum.php?f=17 ) and they moved to
> Montana.

They must make a cute couple.


--
My projects are currently on hold, but I do have
some junk at the site below.

http://www.freewebs.com/timsrl/index.htm

--
Anonymous
August 25, 2005 12:41:54 PM

Archived from groups: rec.games.roguelike.development (More info?)

Sherm Pendley wrote:
> Da-Breegster <dabreegster@gmail.com> writes:
>
>
>>I'm not using many external modules at all so far.
>
>
> Curses is not a core module.

Which is the distinction between "not using many external modules at
all" and "not using any external modules at all". One can not *at all*
be said to be "many". Two might.
Anonymous
August 25, 2005 12:55:48 PM

Archived from groups: rec.games.roguelike.development (More info?)

At Wed, 24 Aug 2005 20:28:00 GMT,
Da-Breegster wrote:

> Though I've probably brought this up previously, are there other
> downsides to using Perl besides speed? And the excuses that it isn't a
> neat language aren't worthy of reply. Who can say this isn't beautiful?

I guess it's too late to back up out of this for you, so what good can
such a question bring besides a flame war?

> $original->fill
> (
> from => [$data->{Ewall}[0]{Y1} + 1, $data->{Ewall}[0]{X}],
> to => [$data->{Ewall}[0]{Y2} - 1,
> $data->{Ewall}[0]{X} + 1],
> with => "."
> );
> # You'd have to be totally sane to call this line noise. And nobody is
> # that sane.

I really don't like the way you use complicated data structures in Perl,
but that's probably fine for an awk replacement ;) 

--
Radomir `The Sheep' Dopieralski @**@_
(Xx) 3 ...
. . . ..v.vVvVVvVvv.v.. .
Anonymous
August 25, 2005 11:03:11 PM

Archived from groups: rec.games.roguelike.development (More info?)

"Filip Dreger" <fdreger@amiga.pl> writes:

> I would not be so sure, you seem to have forgotten that Perl is
> interpreted rather than compiled :-)

Sort of. It's compiled into bytecode, which is then run in a VM.

> "CreatureName" is a string

Not at runtime. Perl has real constants; their value is calculated at
compile time and used just like a literal value would be.

In other words, these two code snippets both compile down to the same
bytecode:

use constant CreatureName => 0;
my $name = $foo[CreatureName];

my $name = $foo[0];

> BTW: hash look-ups are not so costly, actually in many interpreted
> languages they are usually faster than any complex syntax that could
> be used to avoid them.

That's usually the case with Perl. You spend more cycles avoiding the
hash lookups that you would have by simply doing them.

In this particular instance though, based on the small bit of code I've
seen here, I don't think using an array and constant indexes would make
a substantial difference in syntax, just []s instead of {}s.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Anonymous
August 26, 2005 12:43:05 AM

Archived from groups: rec.games.roguelike.development (More info?)

On 2005-08-25, Radomir 'The Sheep' Dopieralski <thesheep@sheep.prv.pl> wrote:
> At Wed, 24 Aug 2005 20:28:00 GMT,
> Da-Breegster wrote:
>
>> Though I've probably brought this up previously, are there other
>> downsides to using Perl besides speed? And the excuses that it isn't a
>> neat language aren't worthy of reply. Who can say this isn't beautiful?
>
> I guess it's too late to back up out of this for you, so what good can
> such a question bring besides a flame war?
>
Absolutely none. Even if I hadn't written a line of code, I'd still end
up using Perl. It's my language of choice.
>> $original->fill
>> (
>> from => [$data->{Ewall}[0]{Y1} + 1, $data->{Ewall}[0]{X}],
>> to => [$data->{Ewall}[0]{Y2} - 1,
>> $data->{Ewall}[0]{X} + 1],
>> with => "."
>> );
>> # You'd have to be totally sane to call this line noise. And nobody is
>> # that sane.
>
> I really don't like the way you use complicated data structures in Perl,
> but that's probably fine for an awk replacement ;) 
>
Complex data structures? $data just contains info on a structure in a
cave, such as a hallway or room. Every wall's coordinates are stored.
I'm also going to have a {Wexit} key with the ID of the structure that
the western wall is connected to, if any. Smart pathfinding made easy.
Anonymous
August 26, 2005 1:51:40 AM

Archived from groups: rec.games.roguelike.development (More info?)

At Thu, 25 Aug 2005 20:43:05 GMT,
Da-Breegster wrote:

> On 2005-08-25, Radomir 'The Sheep' Dopieralski <thesheep@sheep.prv.pl> wrote:
>> At Wed, 24 Aug 2005 20:28:00 GMT,
>> Da-Breegster wrote:

>> I really don't like the way you use complicated data structures in Perl,
>> but that's probably fine for an awk replacement ;) 

> Complex data structures? $data just contains info on a structure in a
> cave, such as a hallway or room. Every wall's coordinates are stored.
> I'm also going to have a {Wexit} key with the ID of the structure that
> the western wall is connected to, if any. Smart pathfinding made easy.

They are complex in Perl.
Note also, that key lookup in hash tables is pretty slow -- you can
probably gain some speed by doing lookups outside the loops whenever
possible ans using local variables instead.
For the structures that need lookups often (like the map), you'd
probably get better results using arrays and constants for the field
names:

CreatureName = 1;
CreatureMaxHP = 2;
CreatureHitDice = 3;

creature[CreatureName]="kobold";

--
Radomir `The Sheep' Dopieralski @**@_
(--) 3 ..zzZZ
. . . ..v.vVvVVvVvv.v.. .
Anonymous
August 26, 2005 5:20:51 AM

Archived from groups: rec.games.roguelike.development (More info?)

Uzytkownik "Sherm Pendley" <sherm@dot-app.org> napisal w wiadomosci
news:m2slwxoc0g.fsf@Sherm-Pendleys-Computer.local...
> Not at runtime. Perl has real constants; their value is calculated
> at
> compile time and used just like a literal value would be.

So Perl surprises me again :) 
PHP and Python also have virtual machines and none of them (AFAIK) has
real constants, burned into bytecode at the time of its creation.

> In this particular instance though, based on the small bit of code
> I've
> seen here, I don't think using an array and constant indexes would
> make
> a substantial difference in syntax, just []s instead of {}s.

Right. It was more of a general remark.

--
regards,
Filip Dreger
Anonymous
August 26, 2005 6:28:51 AM

Archived from groups: rec.games.roguelike.development (More info?)

Filip Dreger wrote:

> Uzytkownik "Sherm Pendley" <sherm@dot-app.org> napisal w wiadomosci
> news:m2slwxoc0g.fsf@Sherm-Pendleys-Computer.local...
>> Not at runtime. Perl has real constants; their value is calculated
>> at
>> compile time and used just like a literal value would be.
>
> So Perl surprises me again :) 
> PHP and Python also have virtual machines and none of them (AFAIK) has
> real constants, burned into bytecode at the time of its creation.
>
>> In this particular instance though, based on the small bit of code
>> I've
>> seen here, I don't think using an array and constant indexes would
>> make
>> a substantial difference in syntax, just []s instead of {}s.
>
> Right. It was more of a general remark.
>

Python has exactly 1 builtin constant : None :) 

Appart from that, the C runtime does an optimisation on local variable usage
inside a function. A local variable in Python doesn't cost any lookup time
no matter how big the name is. That's why it's really worth it to store in
a local variable an often use value ( or function )
Anonymous
August 27, 2005 8:20:21 AM

Archived from groups: rec.games.roguelike.development (More info?)

On 2005-08-25, Radomir 'The Sheep' Dopieralski <thesheep@sheep.prv.pl> wrote:
> At Thu, 25 Aug 2005 20:43:05 GMT,
> Da-Breegster wrote:
>
>> On 2005-08-25, Radomir 'The Sheep' Dopieralski <thesheep@sheep.prv.pl> wrote:
>>> At Wed, 24 Aug 2005 20:28:00 GMT,
>>> Da-Breegster wrote:
>
>>> I really don't like the way you use complicated data structures in Perl,
>>> but that's probably fine for an awk replacement ;) 
>
>> Complex data structures? $data just contains info on a structure in a
>> cave, such as a hallway or room. Every wall's coordinates are stored.
>> I'm also going to have a {Wexit} key with the ID of the structure that
>> the western wall is connected to, if any. Smart pathfinding made easy.
>
> They are complex in Perl.
> Note also, that key lookup in hash tables is pretty slow -- you can
> probably gain some speed by doing lookups outside the loops whenever
> possible ans using local variables instead.
> For the structures that need lookups often (like the map), you'd
> probably get better results using arrays and constants for the field
> names:
>
> CreatureName = 1;
> CreatureMaxHP = 2;
> CreatureHitDice = 3;
>
> creature[CreatureName]="kobold";
>

Pseudohashes are not only deprecated, but more trouble than they're
worth. The only general slowdown right now is the way I handle colors
(I'll get to that in a minute) and dungeon generation. Generation I can
speed up somehow. With colors, I set the ncurses attribute to the
appropriate color only when the previous one is different from the
current color. But I'm still adding one character at a time. There a way
to put the color codes inside a string and addstr() an entire row?
Anonymous
August 28, 2005 3:42:47 AM

Archived from groups: rec.games.roguelike.development (More info?)

<edward@lore.net> writes:

> Da-Breegster <dabreegster@gmail.com> wrote:
>> current color. But I'm still adding one character at a time. There a way
>> to put the color codes inside a string and addstr() an entire row?
>
> How fast is your target platform, and are you sure this is actually
> slowing things down? It looks inefficient, but I'm sure it isn't a
> significant factor in my program's speed.

Is your program in Perl? If not, you're comparing apples and camels. Calling
"down" to a C function from Perl carries some overhead that calling the same
function directly from C does not.

> I'm unaware of any color-encoded string mechanisms in Curses. Surely if
> they existed, they would just do the same colour attron/attroff, but
> internally?

That would be exactly the point - it would call them internally. Instead of
making strlen calls across the Perl/C divide, you'd make one cross-language
call for the whole string, which would result in strlen C-to-C calls.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
August 28, 2005 5:25:16 AM

Archived from groups: rec.games.roguelike.development (More info?)

Da-Breegster <dabreegster@gmail.com> wrote:
> current color. But I'm still adding one character at a time. There a way
> to put the color codes inside a string and addstr() an entire row?

How fast is your target platform, and are you sure this is actually
slowing things down? It looks inefficient, but I'm sure it isn't a
significant factor in my program's speed.
I'm unaware of any color-encoded string mechanisms in Curses. Surely if
they existed, they would just do the same colour attron/attroff, but
internally?
--
jude hungerford.
Anonymous
August 28, 2005 4:00:06 PM

Archived from groups: rec.games.roguelike.development (More info?)

Da-Breegster <dabreegster@gmail.com> writes:
> But I'm still adding one character at a time. There a way
> to put the color codes inside a string and addstr() an entire row?

Term::ANSIColor might work, though I've never used it together with
addstr().

--
Chris
Anonymous
August 28, 2005 5:21:06 PM

Archived from groups: rec.games.roguelike.development (More info?)

"copx" <invalid@invalid.com> wrote in message
news:D eivpg$img$01$1@news.t-online.com...
>
> "Sherm Pendley" <sherm@dot-app.org> schrieb im Newsbeitrag
> news:m2vf1v9d38.fsf@Sherm-Pendleys-Computer.local...
>> *You* may not know how to package and distribute a Perl app, but that
>> doesn't
>> mean it can't be done. Not only is it possible to do, it doesn't take
>> a lot of
>> effort to learn how.
>
> I know that you can do that with almost every scripting language
> outthere. It's not rocket science you know.

So...why the whinging? Did you just forget?

> However this doesn't solve any performance problems

This is rubbish.

> and most developers who write their entire game in a scripting
> language can't seem to be bothered to make binary stand-alone
> releases.

More rubbish; many developers will release source code and binaries.
Just like with any other language.

> So I assumed that he planned to toss a bunch of scripts at us just
> like his colleagues.
>

What colleagues?

--
Glen
L:p yt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+
Anonymous
August 28, 2005 5:21:07 PM

Archived from groups: rec.games.roguelike.development (More info?)

"Glen Wheeler" <gew75@uow.edu.au> schrieb im Newsbeitrag
news:43112d9c$1@dnews.tpgi.com.au...
>
> "copx" <invalid@invalid.com> wrote in message
> news:D eivpg$img$01$1@news.t-online.com...
>>
>> "Sherm Pendley" <sherm@dot-app.org> schrieb im Newsbeitrag
>> news:m2vf1v9d38.fsf@Sherm-Pendleys-Computer.local...
>>> *You* may not know how to package and distribute a Perl app, but that
>>> doesn't
>>> mean it can't be done. Not only is it possible to do, it doesn't take a
>>> lot of
>>> effort to learn how.
>>
>> I know that you can do that with almost every scripting language
>> outthere. It's not rocket science you know.
>
> So...why the whinging? Did you just forget?

No, I've already said the issue is that RL developers who use scripting
languages usually don't use this possiblity but rather expect you to install
their favorite toy (+ extension modules)

>> However this doesn't solve any performance problems
>
> This is rubbish.

Why? Just binding it to the interpreter doesn't make it any faster.

>> and most developers who write their entire game in a scripting language
>> can't seem to be bothered to make binary stand-alone releases.
>
> More rubbish; many developers will release source code and binaries. Just
> like with any other language.

No, they usually won't. I can't remember a single RL developer who uses such
languages and who did release binaries himself. Only Sheep's 7DRL und Umbra
have binaries available contributed by OTHER people (actually I contributed
the Umbra binaries). The idea that a bunch of scripts makes an acceptable
release package is widespread around here.

>> So I assumed that he planned to toss a bunch of scripts at us just like
>> his colleagues.
>>
>
> What colleagues?

All RL devs who write their entire game in a scripting language.

copx
Anonymous
August 29, 2005 10:18:17 PM

Archived from groups: rec.games.roguelike.development (More info?)

At Sun, 28 Aug 2005 06:21:18 +0200,
copx wrote:

> No, they usually won't. I can't remember a single RL developer who uses such
> languages and who did release binaries himself. Only Sheep's 7DRL und Umbra
> have binaries available contributed by OTHER people (actually I contributed
> the Umbra binaries). The idea that a bunch of scripts makes an acceptable
> release package is widespread around here.

Personally, I woudn't install a binary release on my box unless it came
from a source I'm sure of.

--
Radomir `The Sheep' Dopieralski @**@_
(..) 3 Bee!
. . . ..v.vVvVVvVvv.v.. .
August 30, 2005 4:06:20 AM

Archived from groups: rec.games.roguelike.development (More info?)

> copx wrote:

>> the Umbra binaries). The idea that a bunch of scripts makes an acceptable
>> release package is widespread around here.

It's worth noting that many of those projects released as scripts are in
early development, so public accessibility is not a high priority. And
most *nix users have the language installed already, or sitting on
optical media within arm's reach.

Radomir 'The Sheep' Dopieralski <thesheep@ sheep.prv.pl> wrote:
> Personally, I woudn't install a binary release on my box unless it came
> from a source I'm sure of.

Very true.

Having said that, I think making a binary release is a very good thing.
One of my requirements when seeking a language this time last year for
my current rl project was that it have a good compiler.

--
--jude hungerford.
Anonymous
August 30, 2005 7:58:07 AM

Archived from groups: rec.games.roguelike.development (More info?)

"Radomir 'The Sheep' Dopieralski" <thesheep@ sheep.prv.pl> schrieb im
Newsbeitrag news:slrndh6kb2.32t.thesheep@atos.wmid.amu.edu.pl...
[snip]
> Personally, I woudn't install a binary release on my box unless it came
> from a source I'm sure of.

Why? Security? If that's the case I can only say: How irrational of you.
If you don't actually read and understand the entire source code of a
program before you run it (how realistic is that?) the chance that you might
run malware is just as high as with binary releases.

copx
Anonymous
August 30, 2005 7:58:08 AM

Archived from groups: rec.games.roguelike.development (More info?)

copx wrote:
> "Radomir 'The Sheep' Dopieralski" <thesheep@ sheep.prv.pl> schrieb im
> Newsbeitrag news:slrndh6kb2.32t.thesheep@atos.wmid.amu.edu.pl...
> [snip]
>
>>Personally, I woudn't install a binary release on my box unless it came
>>from a source I'm sure of.
>
>
> Why? Security? If that's the case I can only say: How irrational of you.
> If you don't actually read and understand the entire source code of a
> program before you run it (how realistic is that?) the chance that you might
> run malware is just as high as with binary releases.

That's exactly what I was thinking. It'd be so easy to hide some
malicious code in some obscure function, and the chances of catching
it are slim to none. Especially if the coder was smart, and gave all
malicious code phony variable names, that sound like legit ones.

I think security just comes down to good old-fashioned common sense.
If it seems like a legit program (like most any RL is probably going
to be), then install it, binary or not.

Anyways, I personally hate to install from source. There's this
ridiculous notion that most *nix coders have, that apparently binaries
aren't necessary. Which is, of course, complete BS. I *hate*
compiling programs I download, because 50% of the time, it doesn't
compile. Pain in the ass. Everyone should provide binaries with
their apps.


--
My projects are currently on hold, but I do have
some junk at the site below.

http://www.freewebs.com/timsrl/index.htm

--
Anonymous
August 30, 2005 7:58:09 AM

Archived from groups: rec.games.roguelike.development (More info?)

On Mon, 29 Aug 2005 22:06:20 -0500, Timothy Pruett wrote:

>Anyways, I personally hate to install from source. There's this
>ridiculous notion that most *nix coders have, that apparently binaries
>aren't necessary. Which is, of course, complete BS. I *hate*
>compiling programs I download, because 50% of the time, it doesn't
>compile. Pain in the ass. Everyone should provide binaries with
>their apps.

I often run non-Linux *nix - notably QNX. Most programs written for
Linux will run without modification under QNX *if you recompile on the
QNX machine*. (QNX can't run Linux binaries.) In that case, I *need*
sources - not many people provide binaries for QNX.
--
auric dot auric at gmail dot com
*****
If you think facing the thought of your own mortality is a scary thing,
then you don't even want to consider the consequences of that shiny new
7,200 RPM drive in your mailserver deciding to become a 0 RPM drive.
Anonymous
August 30, 2005 10:59:13 AM

Archived from groups: rec.games.roguelike.development (More info?)

At Mon, 29 Aug 2005 22:06:20 -0500,
Timothy Pruett wrote:

> copx wrote:
>> "Radomir 'The Sheep' Dopieralski" <thesheep@ sheep.prv.pl> schrieb im
>> Newsbeitrag news:slrndh6kb2.32t.thesheep@atos.wmid.amu.edu.pl...
>> [snip]
>>
>>>Personally, I woudn't install a binary release on my box unless it came
>>>from a source I'm sure of.
>>
>>
>> Why? Security? If that's the case I can only say: How irrational of you.
>> If you don't actually read and understand the entire source code of a
>> program before you run it (how realistic is that?) the chance that you might
>> run malware is just as high as with binary releases.
>
> That's exactly what I was thinking. It'd be so easy to hide some
> malicious code in some obscure function, and the chances of catching
> it are slim to none. Especially if the coder was smart, and gave all
> malicious code phony variable names, that sound like legit ones.

You can do it only once.
And nobody compiles and runs things as root.
On the other hand, most binary 'installers' need root priviledges.

> I think security just comes down to good old-fashioned common sense.
> If it seems like a legit program (like most any RL is probably going
> to be), then install it, binary or not.

Of course it depends on several things -- whether the box you run it on is
your personal, private box, whether you've got the time to fix things if
something goes broken, etc.

> Anyways, I personally hate to install from source. There's this
> ridiculous notion that most *nix coders have, that apparently binaries
> aren't necessary. Which is, of course, complete BS. I *hate*
> compiling programs I download, because 50% of the time, it doesn't
> compile. Pain in the ass. Everyone should provide binaries with
> their apps.

I personally hate to install binaries, they go int strange places and
act funny 50% of the time -- because they barely compiled.
Everyone should make sure their sources compile without problems.

--
Radomir `The Sheep' Dopieralski @**@_
(`') 3 Grrr!
. . . ..v.vVvVVvVvv.v.. .
Anonymous
August 30, 2005 1:07:09 PM

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett wrote:

> Anyways, I personally hate to install from source. There's this
> ridiculous notion that most *nix coders have, that apparently binaries
> aren't necessary. Which is, of course, complete BS. I *hate* compiling
> programs I download, because 50% of the time, it doesn't compile. Pain
> in the ass. Everyone should provide binaries with their apps.

I like source installation when possible.

My observation is that if I can *build* it, it almost always works
at least as well as it does on the author's system. Binaries can
run into strange bugs that can't be fixed when there are
library-version mismatches (ie, when it was linked during development
against a library which is not the same version as the one on my
system).

Lots of "desktop linux" systems don't take care to establish a good
build environment. Their library paths will be wrong or nonexistent
so the compiler doesn't know where to find its libraries, or they'll
include .so files for binaries to link against but not .h files for
source to compile with, or any of several problems. Most of these
can be fixed, and having fixed them you can build 90% to 95% of
everything and it will work as well on your system as it does on
the developer's machine.

The things you can't build usually are things that have makefiles
that do Bad Things; hardlinking paths, not using aliases different
targets or cases for building in the presence of different systems
and libraries, etc. This is an "installer bug" carried one level
higher into source.

The things you can't build, yeah, you can go get the binaries,
but IME the binaries are likely to use wrong library code versions,
and if not, they "rot" awfully fast as libraries and link targets
get updated. They're no good for a different CPU architectures,
and they get flaky, they break, and there's nothing you can do to
fix 'em.

Bear
Anonymous
August 30, 2005 4:25:46 PM

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett <drakalor.tourist@gmail.com> wrote:
>Everyone should provide binaries with their apps.

I suppose I could provide a i386-compatible .deb assembled against a
snapshot of Debian GNU/Linux testing. Not much use to man or beast six
months down the line when that gimboid Drepper has changed glibc's ABI
seventeen times. (And no, I'm not switching back to stable. stable gets
stale too fast.)

Also, people inform me that Dungeon Bash can be built on at least two
platforms for which I have no facilities to produce binaries, and one
for which I haven't got round to putting together facilities to produce
binaries.
--
Martin Read - my opinions are my own. share them if you wish.
\_\/_/ meteorites are outta sight but this one's place is in outer space
\ / if you wanna know i'll tell you why it's cause radiation makes you die
\/ -- Zombina and the Skeletones, "Meteorite"
Anonymous
August 31, 2005 4:34:50 AM

Archived from groups: rec.games.roguelike.development (More info?)

Sorry for not posting earlier, Hurricane Katrina put out the electricity
yesterday. My family and I were lucky, really.

Anyway, I wanted to know what y'all thought of my idea that I'm using:

Basically every tile on the map points back to a hash of data. The data
is grouped into structures (individual rooms, halls, etc). Each
structure has the coordinates of the each wall recorded, as well as
pointers to which structure connects where.

It's working well so far. Has this ever been used before? Any ideas on
possible improvement?
Anonymous
August 31, 2005 12:21:37 PM

Archived from groups: rec.games.roguelike.development (More info?)

Radomir 'The Sheep' Dopieralski wrote:
> At Mon, 29 Aug 2005 22:06:20 -0500,
> Timothy Pruett wrote:
>
> > copx wrote:
> >> "Radomir 'The Sheep' Dopieralski" <thesheep@ sheep.prv.pl> schrieb im
> >> Newsbeitrag news:slrndh6kb2.32t.thesheep@atos.wmid.amu.edu.pl...
> >> [snip]
> >>
> >>>Personally, I woudn't install a binary release on my box unless it came
> >>>from a source I'm sure of.
> >>
> >>
> >> Why? Security? If that's the case I can only say: How irrational of you.
> >> If you don't actually read and understand the entire source code of a
> >> program before you run it (how realistic is that?) the chance that you might
> >> run malware is just as high as with binary releases.
> >
> > That's exactly what I was thinking. It'd be so easy to hide some
> > malicious code in some obscure function, and the chances of catching
> > it are slim to none. Especially if the coder was smart, and gave all
> > malicious code phony variable names, that sound like legit ones.
>
> You can do it only once.
> And nobody compiles and runs things as root.
> On the other hand, most binary 'installers' need root priviledges.

I don't think there is any reason why a roguelike binary needs to be
installed as root. Or even installed at all.

A roguelike should be able to be unpacked to a user directory and run
directly from there with no actual setup required.

I'd like there to be more of a tendency to Linux binary distributions.
Maybe then the powers that be will become less cavalier about breaking
the binary compatibility. One thing Microsoft has got right is the
ability for a package built on one version to mostly run on all the
later versions.

> > Anyways, I personally hate to install from source. There's this
> > ridiculous notion that most *nix coders have, that apparently binaries
> > aren't necessary. Which is, of course, complete BS. I *hate*
> > compiling programs I download, because 50% of the time, it doesn't
> > compile. Pain in the ass. Everyone should provide binaries with
> > their apps.
>
> I personally hate to install binaries, they go int strange places and
> act funny 50% of the time -- because they barely compiled.
> Everyone should make sure their sources compile without problems.

A great way to make sure the source compiles is to actually compile it.
Having compiled it, why not distribute the binary as well?

This isn't an argument not to distribute source. Indeed, if you are
distributing source, I would recomend not giving the option of only
downloading the binary. Require all users to download the source as
well, that way in 15 years they'll still be able to rebuild it.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Anonymous
August 31, 2005 8:00:46 PM

Archived from groups: rec.games.roguelike.development (More info?)

Jeff Lait wrote:

> I don't think there is any reason why a roguelike binary needs to be
> installed as root. Or even installed at all.

Lots of roguelikes in the past have wanted to run SUID as root,
because they needed write access to a common score file that
no individual player was supposed to have write access to
via any other program.

These days, they usually run SUID as some bogus account like
"games" for the same reason.

Bear
Anonymous
August 31, 2005 9:20:34 PM

Archived from groups: rec.games.roguelike.development (More info?)

At 31 Aug 2005 08:21:37 -0700,
Jeff Lait wrote:

> Radomir 'The Sheep' Dopieralski wrote:
>> At Mon, 29 Aug 2005 22:06:20 -0500,
>> Timothy Pruett wrote:
>> > copx wrote:
>> >> "Radomir 'The Sheep' Dopieralski" <thesheep@ sheep.prv.pl> schrieb im
>> >> Newsbeitrag news:slrndh6kb2.32t.thesheep@atos.wmid.amu.edu.pl...
>> >> [snip]

>> And nobody compiles and runs things as root.
>> On the other hand, most binary 'installers' need root priviledges.
>
> I don't think there is any reason why a roguelike binary needs to be
> installed as root. Or even installed at all.
>
> A roguelike should be able to be unpacked to a user directory and run
> directly from there with no actual setup required.

It was discussed the last time this topic was brought up, that the
installer should also install any libraries required for the binary. ;) 

> I'd like there to be more of a tendency to Linux binary distributions.

Well, most of the time you've got some rpms or debs to download, but they
are likely to be prepared for a deifferent directory structure and have
differently named dependencies.

> Maybe then the powers that be will become less cavalier about breaking
> the binary compatibility. One thing Microsoft has got right is the
> ability for a package built on one version to mostly run on all the
> later versions.

They paid for the backward compatibility, and they paid a lot. Not only
in development time and unstability of their product.

>> > Anyways, I personally hate to install from source. There's this
>> > ridiculous notion that most *nix coders have, that apparently binaries
>> > aren't necessary. Which is, of course, complete BS. I *hate*
>> > compiling programs I download, because 50% of the time, it doesn't
>> > compile. Pain in the ass. Everyone should provide binaries with
>> > their apps.
>>
>> I personally hate to install binaries, they go int strange places and
>> act funny 50% of the time -- because they barely compiled.
>> Everyone should make sure their sources compile without problems.
>
> A great way to make sure the source compiles is to actually compile it.
> Having compiled it, why not distribute the binary as well?

You'll usually compile it for your own architecture -- cross-compiling
is usually a little (not much) more tricky.

And don't forget that we were originally talking about scripts, that don't
build into binary by default...

> This isn't an argument not to distribute source. Indeed, if you are
> distributing source, I would recomend not giving the option of only
> downloading the binary. Require all users to download the source as
> well, that way in 15 years they'll still be able to rebuild it.

I think it's the best option once you got to stage when you want to do
full-blown distribution for the masses.

--
Radomir `The Sheep' Dopieralski @**@_
(nn) 3 Grin
. . . ..v.vVvVVvVvv.v.. .
Anonymous
August 31, 2005 10:43:19 PM

Archived from groups: rec.games.roguelike.development (More info?)

Jeff Lait wrote:
> Radomir 'The Sheep' Dopieralski wrote:
>
>>At Mon, 29 Aug 2005 22:06:20 -0500,
>> Timothy Pruett wrote:
>>
>>
>>>copx wrote:
>>>
>>>>"Radomir 'The Sheep' Dopieralski" <thesheep@ sheep.prv.pl> schrieb im
>>>>Newsbeitrag news:slrndh6kb2.32t.thesheep@atos.wmid.amu.edu.pl...
>>>>[snip]
>>>>
>>>>
>>>>>Personally, I woudn't install a binary release on my box unless it came
>>>>
>>>>>from a source I'm sure of.
>>>>
>>>>
>>>>Why? Security? If that's the case I can only say: How irrational of you.
>>>>If you don't actually read and understand the entire source code of a
>>>>program before you run it (how realistic is that?) the chance that you might
>>>>run malware is just as high as with binary releases.
>>>
>>>That's exactly what I was thinking. It'd be so easy to hide some
>>>malicious code in some obscure function, and the chances of catching
>>>it are slim to none. Especially if the coder was smart, and gave all
>>>malicious code phony variable names, that sound like legit ones.
>>
>>You can do it only once.
>>And nobody compiles and runs things as root.
>>On the other hand, most binary 'installers' need root priviledges.
>
>
> I don't think there is any reason why a roguelike binary needs to be
> installed as root. Or even installed at all.

Well, if it needs to install libraries. Although, admittedly, most
RLs don't need to, since most RLs only depend on curses, which any
*nix distro is going to have. Mine will require more library
installation, though, since I need to install SDL, SDL_mixer, and Lua.

> A roguelike should be able to be unpacked to a user directory and run
> directly from there with no actual setup required.

Yes, ideally, it should be done this way, when possible. That's one
of the reasons I love ADoM; I can just unpack into my ADOM directory,
and I'm ready to go.

> I'd like there to be more of a tendency to Linux binary distributions.
> Maybe then the powers that be will become less cavalier about breaking
> the binary compatibility. One thing Microsoft has got right is the
> ability for a package built on one version to mostly run on all the
> later versions.

What? On my work computer, which runs Windows XP, I frequently browse
through "Home of the Underdogs", and other such sites, looking for
fun, time-killing games. I can easily go through a half dozen games,
however, before I get to one that works on a modern Windows machine.
So much for Microsoft's supposed "backwards compatibility". Apps
built for DOS, Windows 95, Windows 98, Windows ME, hell, even Windows
NT are not guaranteed to work at all on Windows XP. Even adjusting
the "compatibility" settings doesn't help most of the time.

>>>Anyways, I personally hate to install from source. There's this
>>>ridiculous notion that most *nix coders have, that apparently binaries
>>>aren't necessary. Which is, of course, complete BS. I *hate*
>>>compiling programs I download, because 50% of the time, it doesn't
>>>compile. Pain in the ass. Everyone should provide binaries with
>>>their apps.
>>
>>I personally hate to install binaries, they go int strange places and
>>act funny 50% of the time -- because they barely compiled.
>>Everyone should make sure their sources compile without problems.
>
>
> A great way to make sure the source compiles is to actually compile it.
> Having compiled it, why not distribute the binary as well?

Exactly. Distributing just the source will make some people unhappy.
Distributing the source *and* the binary will make everyone happy.
I can't think of any valid reason to not just go ahead and give both
options, especially since your users will appreciate it greatly.

> This isn't an argument not to distribute source. Indeed, if you are
> distributing source, I would recomend not giving the option of only
> downloading the binary. Require all users to download the source as
> well, that way in 15 years they'll still be able to rebuild it.

Yeah. That would, in my opinion, be the best possible solution to the
problem.


--
My projects are currently on hold, but I do have
some junk at the site below.

http://www.freewebs.com/timsrl/index.htm

--
Anonymous
September 1, 2005 5:36:10 AM

Archived from groups: rec.games.roguelike.development (More info?)

In article <idsRe.1673$3R1.66@fe06.lga>, Timothy Pruett <drakalor.tourist@gmail.com> wrote:
>fun, time-killing games. I can easily go through a half dozen games,
>however, before I get to one that works on a modern Windows machine.
>So much for Microsoft's supposed "backwards compatibility". Apps
>built for DOS, Windows 95, Windows 98, Windows ME, hell, even Windows
>NT are not guaranteed to work at all on Windows XP. Even adjusting
>the "compatibility" settings doesn't help most of the time.

That differs from my personal experience, where most old programs
work, apart from sound. ISA era sound was always a pain.

For those programs that don't work natively, there's always
http://dosbox.sourceforge.net/

Alan
Anonymous
September 1, 2005 5:36:11 AM

Archived from groups: rec.games.roguelike.development (More info?)

R. Alan Monroe wrote:
> In article <idsRe.1673$3R1.66@fe06.lga>, Timothy Pruett <drakalor.tourist@gmail.com> wrote:
>
>>fun, time-killing games. I can easily go through a half dozen games,
>>however, before I get to one that works on a modern Windows machine.
>>So much for Microsoft's supposed "backwards compatibility". Apps
>>built for DOS, Windows 95, Windows 98, Windows ME, hell, even Windows
>>NT are not guaranteed to work at all on Windows XP. Even adjusting
>>the "compatibility" settings doesn't help most of the time.
>
>
> That differs from my personal experience, where most old programs
> work, apart from sound. ISA era sound was always a pain.
>
> For those programs that don't work natively, there's always
> http://dosbox.sourceforge.net/

I love dosbox. DOS programs typically run better on Windows XP than
Windows 95/98 apps anyway, though. What I find to be rather funny,
however, is that most older Windows apps run better when emulated on
my linux box, than they do on an actual Windows machine.


--
My projects are currently on hold, but I do have
some junk at the site below.

http://www.freewebs.com/timsrl/index.htm

--
Anonymous
September 1, 2005 6:26:59 PM

Archived from groups: rec.games.roguelike.development (More info?)

In article <idsRe.1673$3R1.66@fe06.lga>, drakalor.tourist@gmail.com
says...
> Jeff Lait wrote:

> What? On my work computer, which runs Windows XP, I frequently browse
> through "Home of the Underdogs", and other such sites, looking for
> fun, time-killing games. I can easily go through a half dozen games,
> however, before I get to one that works on a modern Windows machine.
> So much for Microsoft's supposed "backwards compatibility". Apps
> built for DOS, Windows 95, Windows 98, Windows ME, hell, even Windows
> NT are not guaranteed to work at all on Windows XP. Even adjusting
> the "compatibility" settings doesn't help most of the time.

If apps built for Windows 3.1 onwards don't run, it's usually due to
bad programming.

DOS is different, because there were legitimate reasons for directly
accessing hardware etc.

- Gerry Quinn
Anonymous
September 1, 2005 7:39:19 PM

Archived from groups: rec.games.roguelike.development (More info?)

Gerry Quinn <gerryq@DELETETHISindigo.ie> writes:

> DOS is different, because there were legitimate reasons for directly
> accessing hardware etc.

It depends.

Very old apps that were made to run in real mode, in 640KB or less, often
run in a virtual "dos box" with no problems at all. Yes, they directly
access video and other memory, and trigger interrupts to access dos services,
but that's all virtualized and supported by the host OS.

Later apps that were made after DPMI was settled on as a way for dos apps
to switch to protected mode and talk to a memory manager also tend to run
pretty well.

The major problem apps are from the years in between. They don't use DPMI to
manage the shift from real to protected mode, and provide their own memory
manager. One (in)famous example of that is Ultima 7.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
September 2, 2005 5:44:21 PM

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett <drakalor.tourist@gmail.com> wrote:
> Windows 95/98 apps anyway, though. What I find to be rather funny,
> however, is that most older Windows apps run better when emulated on
> my linux box, than they do on an actual Windows machine.

It certainly says something about the quality of the two environments.

--
--jude hungerford.
September 2, 2005 5:52:43 PM

Archived from groups: rec.games.roguelike.development (More info?)

Sherm Pendley <sherm@dot-app.org> wrote:
> The major problem apps are from the years in between. They don't use DPMI to
> manage the shift from real to protected mode, and provide their own memory
> manager. One (in)famous example of that is Ultima 7.

Good old Voodoo. An appropriate name.
Praise Exult!
I remember having to set up a special boot mode on my DOS box to play
that game at the time... it still barely ran, and sometimes just
restarted the computer mid-game.

--
--jude hungerford.
!