🚀 go-pugleaf

> What this discussion seems to come down to, to me, is a question of
> credibility.  Josh has made some pretty impressive claims, Dave has
> doubted those cliams.  Period.

Well, I called a truce...let's see what Dave does.

> 	Now, there are ways to settle this.  I, personally, know that
> Dave can both program and design complex systems.  I've played his
> games and used Game Workbench.  I know he's more technically competent
> than me, and -- given a known and an unknown -- I'd be more inclined
> to trust his judgement.  That doesn't mean that Josh is wrong, though.

I don't doubt it.  I haven't seen it, but...

> 	Could a complete (but not necessacarily TADS-like) adventure
> system be created in three weeks?  I suppose, depending on how much
> experience and code you had lying around to use.  I, personally, have
> spent over a year on mine, but if I were to start over I could re-
> produce what I have now in, say, a month of part-time work.  Given that,
> I'd be willing to believe that a system could be put together in three
> weeks.  In 18K?  I'd have to see it to believe it.  So, apparently,
> does Dave.

Thank you for believing that much.  I have lots and lots of code lieing
around, as I said.  Part of it was used.  The expression analyzer, for
instance, came from the C compiler I wrote (which took a lot longer than
3 weeks).

As for the 18k part.  Get ahold of ADVSYS by David Betz.  His is right in
that range.  The compiler is 20k, the interpreter (his uses an interpreter)
is about 18.5k.  Its public domain.  I've heard that source is available,
but I haven't found it...and no, the executables aren't compressed.

> 	I believe that a flat-surface texture mapping routine could
> be written with Bresenham.  Would it be fast enough to be real-time?
> I'd like to see it.  So, apparently, would Dave.

The code's posted...I'd like to hear your comments on it,too...

> 	And as for interest:  I'm incredibly interested.  An 18K
> adventure system could revolutionize what I'm doing.  I'm sure there
> are dozens of people here and in rec.arts.int-fiction that could
> really, really use something like that.  A real-time flat-surface
> texture mapper would generate equal excitement.

If the interest is there, I'll post the executables to the system.  The
original is written in Pascal...I'm doing a C conversion now so I can
port it between computers.

> 	I firmly believe that a 16-year-old can be a programming god.
Thank you, but I don't consider myself that.

> I also believe that nobody is going to believe him until he proves
> himself.  Which Josh can with one post.

Done yesterday...

Take care,
Josh

In article <greg.712516168@duke> greg@Quotron.COM (Greg "Maddog" Knauss) writes:
>What this discussion seems to come down to, to me, is a question of
>credibility.  Josh has made some pretty impressive claims, Dave has
>doubted those cliams.  Period.

I don't doubt Josh's claims.  His posts are certainly competant enough.
It is certainly nice of him to post his hard work to rec.games.programmers 
for professionals who would otherwise not have done it themselves.

>	I believe that a flat-surface texture mapping routine could
>be written with Bresenham.  Would it be fast enough to be real-time?
>I'd like to see it.  So, apparently, would Dave.

This is kind of funny.  I remember having a rather lengthy discussion with
Dave some time back and he insisted that he has NEVER ran a demo that didn't
crash on his stock ST.  Quite unfortunate, actually, because his whole 
attitude toward young self-taught programmers would be QUITE different.
There is one demo [ftp.uni-kl.de - pub/atari/demos/chaos*.msa] which has
some VERY nice real-time texturing and phong shading [w/point source
shading, of course] including a texture mapped rotating disk DURING 
disk loading.  There are some BRILLIANT texture-mapped flying ships.
This was coded and heavily optimized over a period of 6 months and runs
smoothly on a stock Atari ST [@8MHz].  Now look at PC Wolfenstein's
routines which require a '386 for smooth animation, VERY limited 
texture mapping, and the author claimed something like 5 years development
time!!!!  

If you want to see something fast, get Maggie issue #10 from ftp.uni-kl.de,
which has an intro that does VERY fast bitmap rotation coded by 
Karl/Delta Force.  [and, Dave, it even runs on a MegaSTe].  

>	I firmly believe that a 16-year-old can be a programming god.
>I also believe that nobody is going to believe him until he proves
>himself.  Which Josh can with one post.

The average age of demo coders is something like 18-years old. It's
been proven many times over!  I met, in person, two guys of the famous
European ST demo group, The Lost Boys, a couple days ago.  These guys
have kept me [and thousands of others] in awe for years and yet, are
amazingly humble in person.  Manikin is my age and he wrote the real-time
solid 3d fractal landscape code for their 'Oh Crikey!  What a scorcher!'
demo [@ftp.uni-kl.de and atari.archive.umich.edu] which operates at about
17 frames per second.  [remember, on an 8MHz 68000!]

>--
> ------------------------------------------------------------------------------
> Greg "Maddog" Knauss                      My boss doesn't know I'm doing this,
> greg@duke.quotron.com                           so I doubt he'd agree with me.
> ------------------------------------------------------------------------------


STratoHAKster/TPPi
Amiga/ST coder
psteffn@gnu.ai.mit.edu

I don't know if Josh mentioned this on his explanation of real-time
perspective mapping [scaling/rotation] but the way to get speed is
to store the image to be scaled in a format where each pixel
is a byte.  An 80x80 pixel bitmap is simply a 6400 byte 2 dimensional
array.  As your scanning algorithm scans the array and stores each pixel
it is stored as another table where you then convert back to interleaved
for screen memory.  I hear that PC VGA stores each pixel as a byte,
anyway, so this might be necessary only on Atari ST or Amiga [advantages
outweigh for the latter two].

I think I posted about texture mapping about a year ago in alt.sys.amiga.demos
or comp.sys.amiga.programmer.

STratoHAK/TPPi

> I don't know if Josh mentioned this on his explanation of real-time
> perspective mapping [scaling/rotation] but the way to get speed is
> to store the image to be scaled in a format where each pixel
> is a byte.  An 80x80 pixel bitmap is simply a 6400 byte 2 dimensional

I forgot to say that, but that is how the routine expects it.

> array.  As your scanning algorithm scans the array and stores each pixel
> it is stored as another table where you then convert back to interleaved
> for screen memory.  I hear that PC VGA stores each pixel as a byte,

Yeah, it does.  At least in the 256 color modes.

> anyway, so this might be necessary only on Atari ST or Amiga [advantages
> outweigh for the latter two].

True, this must be done as a linear byte-by-byte organization technique,
but a friend told me it was possible to have an image like that on the
Amiga.  I can't speak of the ST, though.

> I think I posted about texture mapping about a year ago in alt.sys.amiga.demos
> or comp.sys.amiga.programmer.


Same type of system?

Josh

To whomever thinks flat-surface texture mapping can't be done in real time:

It can.

I was playing with texture mapping a few weeks ago, and I wrote some stuff
in C and I was getting about 20 frames a second (single surface). This
was with all-integer calculations but not very optimized - I'm fairly
sure you could easily get 60 fps of multiple surfaces in assembly.

Toshi Morita

(an ex-Origin, ex-EA, ex-Taito, and currently LucasArts Games programmer)

>>       Could a complete (but not necessacarily TADS-like) adventure
>> system be created in three weeks?  I suppose, depending on how much
>> experience and code you had lying around to use.  I, personally, have
>> spent over a year on mine, but if I were to start over I could re-
>> produce what I have now in, say, a month of part-time work.  Given that,
>> I'd be willing to believe that a system could be put together in three
>> weeks.  In 18K?  I'd have to see it to believe it.  So, apparently,
>> does Dave.
>
>Thank you for believing that much.  I have lots and lots of code lieing
>around, as I said.  Part of it was used.  The expression analyzer, for
>instance, came from the C compiler I wrote (which took a lot longer than
>3 weeks).
>
>As for the 18k part.  Get ahold of ADVSYS by David Betz.  His is right in
>that range.  The compiler is 20k, the interpreter (his uses an interpreter)
>is about 18.5k.  Its public domain.  I've heard that source is available,
>but I haven't found it...and no, the executables aren't compressed.

I have the source to an earlier version of David Betz ADVSYS and have ported
it over to OS9. Very well written!! The only problem I have with the ADVSYS
is that there isn't enough examples of "adventure" source to know the proper
way to create a new "method", or how to add verbs, or how all the subsections
fit together (i.e. a "walk-through" of the sample adventure).

-- 
Thomas Kocourek                               : UUCP on an OS9 system,
UUCP: ...!{emory,gatech}!wa4mei!westgac3!tomk : Multitasking in 512K---
LD: (404) 834-4685                            : What a concept!

>>As for the 18k part.  Get ahold of ADVSYS by David Betz.  His is right in
>>that range.  The compiler is 20k, the interpreter (his uses an interpreter)
>>is about 18.5k.  Its public domain.  I've heard that source is available,
>>but I haven't found it...and no, the executables aren't compressed.

> is that there isn't enough examples of "adventure" source to know the proper
> way to create a new "method", or how to add verbs, or how all the subsections
> fit together (i.e. a "walk-through" of the sample adventure).

I'm writing a disassembler alongside the conversion to C of my compiler.  It
should take adventures already out there and decompile them into readable
source.  How about taking that Columbus adventure and seeing what it was
really made of???

Josh