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

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

Path: informatik.tu-muenchen.de!fischerj
From: [e-mail] (Juergen "Rally" Fischer)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Demo/game to OS friendly part II
Date: 29 Jan 1996 18:59:10 GMT
Organization: Technische Universitaet Muenchen, Germany
Distribution: world
Message-ID: <4ej5du$[e-mail]>
References: <4e0jhq$[e-mail]> <4e114i$[e-mail]> <4e371l$[e-mail]> <4e3jld$[e-mail]> <4e5k20$[e-mail]> <4e64u7$[e-mail]> <4e9n67$[e-mail]> <4eb61a$[e-mail]>
NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
Originator: [e-mail]


In article <4eb61a$[e-mail]>, [e-mail] (Michael van Elst) writes:
|> [e-mail] (Juergen "Rally" Fischer) writes:
|>
|> >: Simple and easy: you shouldn't, you mustn't, you can't.
|>
|> >wait a minute, I can't ? So how vlt manages to download on hd
|> >while I run a editor ? :)
|>
|> You can't in your c0d3rware.

vlt is not my coderware. it was mentioned in news for beeing startable
from each dir (which my intro does, too ;)

|>
|> >The problem disappears if I also provide selection of the 100% os fallback!
|>
|> So far you don't and you mix c0d3r lore and the use of the system.

no, the version for gfx-cards is automatically the one for 100% OS.
the medium version, 4pass on planarscreens, will need a chipsetblitter.
the low version will need Amigachipset and a PAL monitor (and maybe V39 only,
if higher versions built the copperlists for a view/vport different).

|>
|> >mhm haven't you told me native = planar & in chipmem, and isn't chipmem
|> >something you can blitter around ?
|>
|> Native = planar & chipmem. Doesn't mean that you have a blitter or
|> even a compatible blitter. Of course up to now this _assumption_

well, how could I know, that the OS writers have different oppinion
about the term "chipmem".

|> is valid. But what would have been with AAA and an incompatible
|> blitter ? You would still have chip memory but your blitter code
|> would break.

Ah, so a card driver could tell you you're in chipmem, actually
running on gfx-card-vram with bitmap still planar interpreted.

so "chipmem" means here "mem where planar bitmap can be made visible" ?

so, could a driver tell a bitmap is "native", with bitmap located in
fastmem (and OS-functions doing the rest) ?

So I would say, "native" is planar & in the mem the OS-calls get the
data into screens/windows. No chipmem at all!


|>
|> To check for the blitter you have to check the flags in GfxBase.
|> You can see wether you have OCS blitter, ECS blitter or AGA blitter.

then, how to check if my native bitmap is blitterable by AGA or
compatible blitter ? I guess all the people who asked for the
"native" check will assume the mem is blitterable by $dff058.

shock, what about allocmem(chip) ?

|>
|> >why is this not your oppinion ? you mean 3 pass is not faster than 4
|> >pass ? you must be joking.
|>
|> I never said this.

but you say using the 3 pass version is wrong under any condition ?

|>
|> >So if user got no AGA or no PAL, he will be happy (?) selecting
|> >writepixelarray8().
|>
|> He would probably be happier if writepixelarray8 were faster.

Writepixellarray8 can only get as fast as my hack if

a) OS introduces interleaved planar viewports for AGA and previous chips.
b) let's me select how much passes are done by cpu or blitter (for each
   writeparr8() call).
c) the updated area got same width like screen

Would indeed be nice, 3 pass c2p on OS-screens.
but to c00l to happen to be done by a D3v3l00p3r.

I admit it won't work well for 640er res, no 1280res,
only 320res on dblmonitors and then chipmem bus gets
into traffic jam. So the new modus is to be opened only
when running PAL LORES (mhm, where to I know this
specifiaction from ;) hihi ;)

|> >You said "No", you don't believe
|> >that there is a case where "direct render can be faster".
|>
|> Rubbish. I believe that there are cases where direct render can be even
|> slower.
so what are we wrestling about ? :D you somehow don't like direct
render, did I read this right ?

|> >: valid is your other assumption about WaitTOF() to use busy-waiting.
|>
|> >I assume there exist drivers that do this.
|>
|> As most things you say are mere _assumptions_.
|>
|> >you told me.
|>
|> No, I didn't.
too laze to reread now, as everytime I do this I find the place
where you said it. Maybe this time it's not on newsserver yet.
|>
|> >you told me
|> >not to use hi-pri waittof therefore.
|>
|> No, I didn't.
Maybe you did think something different writing a sentence that
would be interpreted by most people (I said people, not c0d3r)
like I did. well.

|>
|> >you flame about things you did
|> >tell.
|>
|> No, I didn't.
maybe. So what you tell, what you flame ?

|>
|> >: >struct display *getdisplay(320,256,8,MODE_DIRECT_RENDER|MODE_LORES);
|> >: Sorry, fails.
|>
|> >how you want to know ? you don't know what my function does.
|>
|> It should get you a display where you can poke the bitmap. And sorry,
|> this wouldn't work everywhere.

It would. You don't know the routine as I didn't write RKMs for it ;)
It just canceles direct render mode when not available on that
platform (Your A3000, SGI, etc.). But it will return a array you got
to render to, so no failing.

|>
|> >"fails." really useful answer...
|>
|> Sure. It tells you that "what a c00l c0d3r assumes to get from an
|> operating system" is not what he actually gets.

Well, a routine specified by Elit3 Dev3l00perz fails even if
there was a way to do the required thing. OS routines are to
do hardwarepokes.

|>
|> >yes, sure. and yes, there are cases wher it is slower.
|> >conclusion: you get most power is interface can handle both.
|>
|> Always _assuming_ that the programmer supports every possibility.
|> This is deadly wrong for c0d3rz and is still wrong for OS programmers.

programmer ? you mean the caller of my routine now ? He got to render
to the given array, and then call the updateroutines, that's all.

|>
|> >this proves my point that direct render sometimes is faster. TAIC.
|>
|> You didn't claim this. You claimed that it were always faster.

again too lazy to look up, quote me, I don't believe to have said
"always" in that context, this time you misunderstood.

|>
|> >: You said that you need direct rendering to vram _because_ that is
|> >: faster. And that's wrong.
|>
|> >I need this possibility as there are cases where it is faster.
|>
|> How would you know when it is faster ? Simply assuming that produces
|> many situations where your code is slower. Using the system might
yes.
|> not give the best speed in a particular setup but it gives the
|> best speed for all setups.

Maybe you'd need to specify more than a bool value to tell how
realtimish your effect is to give the interface a chance for right
decision.

|> I would make the driver API include those higher level functions.
|> The system could support texture mapping or rendering lots of polygons.

Why not. programmer can test if they're faster than his tricks
(they're maybe slower if no hardware present, see writeparr8(). )

|>
|> >how to direct render if OS doesn't support it ?
|>
|> You don't. The driver does. The driver is allowed to do this.

Direct render =
{
 {
 for example writing a line from 0,0 to 319,199 with cpu.
 beeing able to do any self-invented kind of rendering
 onto this buffer
 }

Then I display the buffer, i.e video-buffer shows the line next
frame without any copying.
}

You say the driver is to do this. The driver can't do direct
render, unless my rendering consists of 100% API calls,
but as soon as I intend to do some own effect without falling
back to putpixel, no direct render any more.

No direct render any more even if cpu writes are possible to
the ram where other rendering hw is located.

This is what I don't like. It's avoidable.


|> >I bet the cheaper ones, the ones only costing as much as 20 A1200,
|> >got no zoom hardware anyway.
|>
|> AFAIK they still have texture mapping hardware and geometry engines.
|> Not as fast and powerful as the big machines though.

mhm it looked like some sgis do map with software. and the gouraud
demo also was not as fast as you expect from hardware. maybe it's
the OSes fault, but then what do you need that hardware for...

|>
|> >: Poking hardware isn't efficient from a broader view.
|> >yep.
|>
|> Then why do you say the opposite all the time ?

I say all the time I want to ADD a poking routine that is
faster from a A1200s view, the machine which is the most
used Amiga. If I also provide a OS version, you can't
flame me for anything.

|>
|> >: If that produces junk, sure.
|>
|> >On a vanilla A1200 it doesn't ;)
|>
|> Sure it does.

Why always this short replys. You want to tell the "even vanilla A1200
aren't 100% compatible" story ? well, the PAL ones are a bit slower ;)

Or you want to tell that my copper overtake could crash. oki.
I bet still 99% of vanilla A1200 users will chose the 3pass
solution if it isn't too unstable. chosing something is beeing
more happy with it.
For doing downloads they can chose the 4pass version, or, if
not provided by me due to laziness, they can chose the OS-call
(and will soon rerun it in unsave 3 pass-mode, I bet).

|>
|> >Actually the only thing that can
|> >make my copper hack crash is - the OS!
|>
|> You are blind. Of course it is _your_ hack that crashes.

Imagine a code that works right on OS3.0, works right just
because the done assumtions (copjmp2 not needed in syscoplist)
are true for OS3.0. If the A1200+ still got AGA, and if the
code doesn't contain any other assumtions, the only way
to make it crash is having a different OS, which uses copjmp2
for some purpose. Is it clear now ?

|>
|> >If 4.0 will make it crash
|> >I will ask myself why I didn't overtake the copper with a 080 poke.
|>
|> Or ask yourself why you tried to hack the OS. If you use hacks you

The irony is that if the new OS needs copjmp2, there is no chance for
my "ucopl copjmp2 slight hack without acessing $dffxxx", but a copper
takeover routine still got a chance. quite weird!

|> break sooner or later. That's one of the most simple rules.

Not brake later, because you won't select 3 pass on the later
models.

You don't get it that a special select-3-pass version makes sense
on vanilla A1200, huh ? Game players will be less happy with your
oppinion, but not any game player will be less happy with mine.

And happy gamerz are the aim, not happy philosophes.

|>
|> --
|>                                 Michael van Elst
|>
|> Internet: [e-mail]
|>                                 "A potential Snark may lurk in every tree."
------------------------------------------------------------------------
   [e-mail] (Juergen "Rally" Fischer)   =:)