NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/4835

Internet Message Format | 1996-08-05 | 10.0 KB

Path: informatik.tu-muenchen.de!fischerj
From: [e-mail] (Juergen "Rally" Fischer)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Amiga doesn`t need Pl
Date: 5 Mar 1996 16:34:16 GMT
Organization: Technische Universitaet Muenchen, Germany
Distribution: world
Message-ID: <4hhqe8$[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: hphalle6g.informatik.tu-muenchen.de
Originator: [e-mail]


In article <[e-mail]>, [e-mail] (John Hendrikx) writes:
|> In a message of 25 Feb 96 Juergen "rally" Fischer wrote to All:
|>
|>  JrF> todays 1230 or 1240 should be able to do same (wasn't doom busy waiting
|>  JrF> for vblank bit? I think so!)
|>
|> As DOOM was tripple-buffered I don't see why, unless it would run faster than
|> the display update rate.

maybe I missed new features of new wad players ?
I remember having heard of vblank polling.

I guess you refer to DOS-DOOM talking about tripple buffering
(coz you need vbl int).

|>
|>  >>  JrF> You rely on _programming crap_ in combination with low cpu. No, a
|>  >> game which is unplayable because it uses a fuzzy 2x2 160x120 display (or
|>  >> less!) and jerks like hell is CRAP.
|>  JrF> fuzzy 2x2 due to low cpu, jerk due to low cpu. not AGA.
|>
|> So speed would remain the same if AGA had been Chunky?  Maybe it makes little

Yes, you got it! doom speed with AGA chunky would be same as AGA planar.

|> difference on mega-big-CPU (as long as you stick with LoRes that is) but it

no, it even makes no diffference on my 020-14 + fastmem, because blitter
got enough time to convert iff 020 is to render a doom scene.

why don't you agree ?

|> will make quite a difference here.
|>
|>  >>  Blitter assistance: Requires non-interleaved bitmaps, impossible to
|>  JrF> that's no problem.
|>
|> Not always, it depends on what 'other' stuff you want to do in your game.
ok...

|>
|>  >>                      C2P a smaller part of the whole screen
|>  JrF> that's no problem concering games like doom.
|>
|> Isn't it?
ok, if you make the window smallwer but want some background texture
around it, you got to think about using the sprites for that ;)
I see there is a disadvantage ;) but not speedwise!

|>
|>  >>                      on factors like CPU, fast-memory, etcetera...
|>
|>  JrF> The disadvantage is that you got to code more, right. no technical
|>  JrF> argument.
|>
|> Oh sure, just code a bit more, I guess that's why we see so many DOOM clones
|> which actually USE this kind of stuff, NOT.

I thought you were claiming technical planar problems ?
less frameratee and such ?

|>
|>  >>                      Try to get it to work on Intuition-screen and make
|>  >>                      your DOOM-clone support multiple window sizes.
|>  JrF> closescreen. openscreen.
|>
|> Shitty solution.  I suppose the overlayed text should also have to be shrunk
|> accordingly?  What about the status panel? Just open another screen you say?
|> Another 'special' routine as this can't be used on most gfx-cards.

mhm, vports are said to be supported also on gfx-cards.
what you argue about ?

|>
|>  >>       Chunky Copper: Crappy resolution, wastes lots of ChipRAM bandwidth
|>  JrF> demo only.
|>
|> Most of the stuff I've seen here is 'demo' only.  For example, using 64K for a
|> single texture and stuff like 256K loop-up tables are quite unrealistic for
|> real games.
256k is nothing on the doom-loved clones.

|>
|>  JrF> I already got 1pass. still got 2pass to write, ludde is said to have
|>  JrF> it done free.
|>
|> Don't forget to ask him what 'new' limitations this 'trick' will introduce.

it will at least give kind of square where kind of doom is in ;)
no demo cubes outside display window, I see ;)

|>
|>  >> and probably one which uses AKIKO, and of course for each of these
|>  >> routines a
|>  JrF> FORGET AKIKO.
|>
|> Oh, I bet there is some 'strange' config which could actually make AKIKO an
|> advantage (maybe AKIKO + BlitterAssistance or something stupid like that?)

yep, if chipmem was faster ;) I hope new chipsets will also have chunky ;)

|>
|>  >> version which does 2x1 displays, and versions for 16, 64 and 256 colors.
|>  >> Maybe also add ChunkyCopper and BlitterScreen C2P?  It looks like we've
|>  >> gone C2P
|>  JrF> FORGET COPPER.
|>
|> I did that years ago, when everybody kept begging me to add copper-screens to
|> TextDemo.

hehe, got me ;)
so now we have free c2p, why you won't add that ?

|>
|>  JrF> blitterscreen is only nessesary for fast clones, otherwise use 4pass.
|>
|> Why don't you make a huge IF THEN kind of list of C2P routines, like this:
|>
|>   IF AGA=TRUE AND GFXCARD=FALSE
|>      IF 040=TRUE
|>         IF 040=SLOW4000/040
|>             use CPU 3-pass 32-bit C2P + blitter assistance (or whatever)
|>         ELSE
|>             use CPU only C2P
|>         ENDIF
|>      ELSE IF 030=TRUE
|>         IF MHZ=>33
|>             use 3-pass 32-bit C2P + blitter assistance
|>         ELSE
|>             use 2-pass 32-bit C2P + blitter assistance
|>         ENDIF
|>      ELSE
|>         IF FASTRAM=PRESENT
|>             IF AKIKO=TRUE
|>                 use AKIKO + blitter assistance
|>             ELSE
|>                 use ...
|>             ENDIF
|>         ELSE
|>             IF AKIKO=TRUE
|>                 use ...
|>             ELSE
|>                 use ...
|>             ENDIF
|>         ENDIF
|>      ENDIF
|>   ELSE IF ECS=TRUE AND GFXCARD=FALSE
|>      IF ...
|>         ...
|>      ELSE
|>         ...
|>      ENDIF
|>   ELSE IF OCS=TRUE AND GFXCARD=FALSE
|>      IF ...
|>         ...
|>      ELSE
|>         ...
|>      ENDIF
|>   ELSE
|>      IF BUS=ZII
|>          IF SEGMENTED=FALSE
|>              IF PICASSO=TRUE
|>                  ...
|>              ELSE
|>                  ...
|>              ENDIF
|>          ENDIF
|>      ELSE
|>         ...
|>      ENDIF
|>   ENDIF
|>
|> and so on, and oh I forgot, the best C2P routine to use also depends on how
|> much rendering needs to be done (ie, what resolution and how big the screen is)
|> so take that into account too!

yes, that's it. now try to optimize the list for the important points.

2+2pass, 3+1pass, writepixelarray8.

lots of people would be much happier if you just added those 3 to TD.

|>
|> And some people claim here that having to take all the gfx-cards on the clones
|> into account is such a big problem...
|>
|>  >> There is no Amiga with the same power as the P133.  And my 'average' (and
|>  >> 2 year old $100) VLB Gfx card handles 15 MB/sec easily, more than enough
|>  >> to do 640x480 in 2 frames.
|>
|>  JrF> If 15mb/sec is more than enough to do 640x480 gfx, 6mb/sec surely are
|>  JrF> no problem doing 320x160 ;) you contradict yourself :)
|>
|> You claim things not having been done yet.  What was that 20-25 ms figure which
|> most 040 C2P routines get?

am I misinformed ?

|>
|>  JrF> ok, 10 planes would need a faster cpu. Maybe one of the faster PPCs
|>  JrF> could do c2-10p in 15mb/sec ? :) If so this would outrule non-paletted
|>  JrF> 16bit displays (smother shading) and 24bit displays in terms of shding
|>  JrF> speed (with 10 bit just use 4 for shading, doing shading with just
|>
|> 16 shading levels with just 64 colors?  No thanks.  I'll go for the 15/16-bit
|> screen with 65536 colors with on average 16 shading levels.  Or maybe I'll just
|> use some of the more fancy YCrCb modes were Y is the intensity level.

ok I agree, crominance + luminance is the way to get fast shading.

|>
|>  JrF> adding a register, no table-lookup -> more speed. Imagine descent real
|>  JrF> gouraudshaded :).
|>
|> Why imagine?  There are already games doing that.

but descent doesnt do that....

|>
|>  >> There is no (good) clone because it requires a 040 + fast Chunky
|>  >> gfx-card, period.  Caused of course by the fact that 040 + fast Chunky
|>  >> gfx-card is a rare combination found in the Amiga world.
|>
|>  JrF> "That's why there is no clone, the C2P problem...". What he wanted to
|>  JrF> say, is a technical argument. You give me a marketing argument, which I
|>  JrF> am not interested in now.
|>
|> Not yet.
|>
|>  JrF> So if something keeps us from having 16.6fps doom, it's either the cpu
|>  JrF> (how much could a 030-50 do when using same algo like doom ?) or the
|>
|> Without C2P 030-50 should be capable of max 12 FPS (that would mean it has to
|> be 50% faster than TextDemo running without C2P, if you think that is a
|> realistic goal), 320x240 1x1 exact DOOM engine.
|>
|>  >> That's TextDemo 5.7x (unreleased version) someone tested for me.  15-20
|>  >> FPS for a 68060/50 which is supposed to be 2-3 times as powerfull as a
|>  >> 486DX2/50 is quite depressing, considering that that 486 will do it at 30
|>  >> FPS.  Now just
|>
|>  JrF> running DOOM... are you sure doom does as complicated mapping... 2-3
|>
|> Yes, TD did no more than DOOM did (even though it may SEEM that way because of
|> some clever lightsourcing code).
|>
|>  JrF> times... IMHO in that range it depends much more on the mem interface.
|>  JrF> cache ? Reading textures is a quite mem intensive job, especially if
|>  JrF> you do a table lookup for reach pixel (which is hopefully in cache
|>  JrF> sometimes).
|>
|>  >> translate that to the slower Amiga's (ie, the ones only equipped with
|>  >> 030's and 040's).
|>  JrF> well, imho there is nothing against using the 11cycle mapper for
|>  JrF> floor, using coppershading. at least for 020/030.
|>
|> IF 020/030 THEN ... sigh...

well, coppershaded floor means 70% faster. add a wallshade fake
(trading mem, some cards got quite much mem) and it's even faster.

|>
|> Grtz John
|>
|> -----------------------------------------------------------------------
|>  [e-mail]   TextDemo/FastView/Etc... development
|> -----------------------------------------------------------------------
|> -- Via Xenolink 1.985B5, XenolinkUUCP 1.1
------------------------------------------------------------------------
   [e-mail] (Juergen "Rally" Fischer)   =:)