🚀 go-pugleaf

>> Due to the fact that many people have emailed me saying "Where is the code?",
>> I'm reposting it again.  I posted it several days ago.  Maybe I'll have to
>> split the message into four parts or something. - Josh
> 
> Here's a programmer who is very professional.  Note that he chose to use
> Pascal to do the mundane tasks of opening files, parsing PCX format,
> and setting things up.  Then he lets it rip in 100% assembly.  Actually,
> there is about 100 lines too many of Pascal for my blood :)

I could've done it in C, but the inline assembly techniques of C on the 
IBM vary from compiler to compiler.  For instance, Borland C requires
semi-colons after each line.  Quick C doesn't.  Labels work differently
between these two compilers.

Besides, Mike, you're an Amiga programmer, right?  C on the Amiga is 
much more highly optimized than typical C compilers on the IBM.  The only
compilers that I've been told that do global optimizing (and have for
years) on the IBM is Watcom C and Zortech C...but I can't afford either.

Josh

In article <1992Aug1.122114.57757@cc.usu.edu> sl8nl@cc.usu.edu writes:
> >> Due to the fact that many people have emailed me saying "Where is the code?",
> >> I'm reposting it again.  I posted it several days ago.  Maybe I'll have to
> >> split the message into four parts or something. - Josh
> >
> > Here's a programmer who is very professional.  Note that he chose to use
> > Pascal to do the mundane tasks of opening files, parsing PCX format,
> > and setting things up.  Then he lets it rip in 100% assembly.  Actually,
> > there is about 100 lines too many of Pascal for my blood :)
>
> I could've done it in C, but the inline assembly techniques of C on the
> IBM vary from compiler to compiler.  For instance, Borland C requires
> semi-colons after each line.  Quick C doesn't.  Labels work differently
> between these two compilers.
>
> Besides, Mike, you're an Amiga programmer, right?  C on the Amiga is
> much more highly optimized than typical C compilers on the IBM.  The only
> compilers that I've been told that do global optimizing (and have for
> years) on the IBM is Watcom C and Zortech C...but I can't afford either.
>

Even though Amiga 'C' compilers claim to be good, I generate 5x better code
by hand in assembly!  :)

> Josh

--
Amiga programmer of: GRn, MailMinder, Budokan, Beyond Dark Castle, Dark Castle
Sega Genesis programmer of: Dick Tracy and Marble Madness.
Mike Schwartz  (ames!zorch!amiga0!mykes or mykes@amiga0.sf-bay.org)
1124 Fremont Ave.
Los Altos, CA 94024

>> Besides, Mike, you're an Amiga programmer, right?  C on the Amiga is
>> much more highly optimized than typical C compilers on the IBM.  The only
>> compilers that I've been told that do global optimizing (and have for
>> years) on the IBM is Watcom C and Zortech C...but I can't afford either.
>>
> 
> Even though Amiga 'C' compilers claim to be good, I generate 5x better code
> by hand in assembly!  :)

Well, of course.  That's why the mapper was written in assembly and not, gag,
Pascal or C.  That would be a major slowdown.

In article <1992Aug2.134310.57771@cc.usu.edu> sl8nl@cc.usu.edu writes:
> >> Besides, Mike, you're an Amiga programmer, right?  C on the Amiga is
> >> much more highly optimized than typical C compilers on the IBM.  The only
> >> compilers that I've been told that do global optimizing (and have for
> >> years) on the IBM is Watcom C and Zortech C...but I can't afford either.
> >>
> >
> > Even though Amiga 'C' compilers claim to be good, I generate 5x better code
> > by hand in assembly!  :)
>
> Well, of course.  That's why the mapper was written in assembly and not, gag,
> Pascal or C.  That would be a major slowdown.

Assembly language is going to make your 50MHz 486 go THAT much faster, too :)

--
Amiga programmer of: GRn, MailMinder, Budokan, Beyond Dark Castle, Dark Castle
Sega Genesis programmer of: Dick Tracy and Marble Madness.
Mike Schwartz  (ames!zorch!amiga0!mykes or mykes@amiga0.sf-bay.org)
1124 Fremont Ave.
Los Altos, CA 94024

>> > Even though Amiga 'C' compilers claim to be good, I generate 5x better code
>> > by hand in assembly!  :)
>>
>> Well, of course.  That's why the mapper was written in assembly and not, gag,
>> Pascal or C.  That would be a major slowdown.
> 
> Assembly language is going to make your 50MHz 486 go THAT much faster, too :)

That is, when I get one of those...

>Besides, Mike, you're an Amiga programmer, right?  C on the Amiga is 
>much more highly optimized than typical C compilers on the IBM.  The only
>compilers that I've been told that do global optimizing (and have for
>years) on the IBM is Watcom C and Zortech C...but I can't afford either.


Actually, Borland C++ version 3.1 does global optimizing, but I don't think
it does it well enough to do what you are talking about.  I've been working
on some perspective mapping stuff as well.  Assuming that the screen is
half filled with mapped images at any given moment, I started off with only
4 frames per second using nothing but pure C with all optimizations.  After
a little inline assembly, it's now up to 23 frames per second and still
rising.  I guess I'm somewhere between the extremes of those that don't
want to see the assembly code produced by the compiler and those that find
it a sin to not write everything in assembly, even if part of the code
doesn't even show up on a profile at all.

-Gary McTaggart

> Actually, Borland C++ version 3.1 does global optimizing, but I don't think
> it does it well enough to do what you are talking about.  I've been working

No, it doesn't :)   It probably would if Borland had been in the globally
optimizing business from the beginning.

> on some perspective mapping stuff as well.  Assuming that the screen is
> half filled with mapped images at any given moment, I started off with only
> 4 frames per second using nothing but pure C with all optimizations.  After

Try writing a Wolf3d with that :)

> a little inline assembly, it's now up to 23 frames per second and still
> rising.  I guess I'm somewhere between the extremes of those that don't
> want to see the assembly code produced by the compiler and those that find
> it a sin to not write everything in assembly, even if part of the code
> doesn't even show up on a profile at all.

So is part of your perspective mapper still in C...or not.  Hint:  in under
20k (at least with the way mine is written), you can store all of the scaling
structures for a 100x100 object to scale it from 0x0 to 200x200.  That way,
you eliminate Bresenham altogether.  Of course, your object would have to be
fixed, but that is the breaks.  I believe this is how Wolf3d did it.  You'll
notice that when you resize the display, it recalculates something.  I'm
guessing that it is recalculating similar tables.

Besides, as you could see by my source, I'm not an assembly language extremist.  
I did the bulk of the work in Pascal!!!  Hooray for high-level languages...
hey, even demos from Europe are no longer sheer assembly.  For instance,
Ultra Force's vector graphics demo...Pascal.

Take care,
Josh