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

Internet Message Format | 1996-08-05 | 3.9 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: 22 Jan 1996 18:03:38 GMT
Organization: Technische Universitaet Muenchen, Germany
Distribution: world
Message-ID: <4e0jhq$[e-mail]>
References: <[e-mail]> <9PxXx*[e-mail]> <4des65$[e-mail]> <[e-mail]> <4djpni$[e-mail]> <4dm07g$[e-mail]> <4dmm79$[e-mail]>
NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
Originator: [e-mail]


In article <4dmm79$[e-mail]>, [e-mail] (Michael van Elst) writes:
|> [e-mail] (Juergen "Rally" Fischer) writes:
|>
|> >the more information you give, the less the junk/useful ratio.
|>
|> That's obviously not true. If I told them how to build the bomb

don't you think someone knowing about OS-coding, but beeing
a friendly, non-agressive fellow, couldn't achieve more ? ;)

|> >only if vram is a good pice slower than fastmem, depends on
|> >what you do.
|>
|> Right. It depends on lots of things, so at least a straight
|> copy can be optimized by the driver.

? how to optimize move.l (a0)+,(a1)+ ;)
well do we talk about the same...

I'd suggest the driver gives you a buffer you can render to,
maybe with you specifiyng you intend to write bytewise into it
(directly render a doom scene).

If the card can display multiple buffers and writing bytewise to it
is faster than writing bytewise to fastmem + copying the buffer,
the driver will give you an adress in vram. voila :)


|> >but then there's a mmu anyway if you intend to swap.

|> which isn't necessarily applicable if your graphics system
|> has DMA channels that bypass the MMU.

ok I see that a buffer in native chipmem has to be on physical
adress as you can use the blitter on it. but a swapping system
could include adjusting the dma pointers on a gfx-card.

|>
|> >|> would only grab the pointer, kill the OS and poke away, e) it
|> >So making the OS more sucking would keep them from doing it ?
|>
|> More sucking ? Do you want to talk or just insult me ?

Didn't you give as reason why the OS shouldn't give a pointer direct
to vram (which is a feature makinf the OS less sucking) something like:

>>>>
and the c0d3rz would have to learn about semaphores, d) they
would only grab the pointer, kill the OS and poke away, e) it
just works if you have a complete screen allocated to you.
<<<<

So making the OS more sucking would keep then from using
OS-functions to get fast animation ?
I really don't think so.

|>
|> >|> just works if you have a complete screen allocated to you.
|>
|> >well, games naturally want to have a screen they can render to.
|>
|> Do they ? I thought they wanted a hunk of chipmem to poke to and
|> a copper list.

any games showing fast gfx naturally want to have a screen (better
say screenbuffer) they can render to. also OS-coded ones will still
want "a complete screen allocated to you." because no game is fun
on half screens.

|>
|> >do you mean there is no possibility to make an interface that allows
|> >render to vram if hardware makes it possible ?
|>
|> Maybe there is, maybe there is not. I'd rather have well-optimized code
|> in the driver than half-guessed c0d3r-stuff.

you can keep game programmers from doing this in providing a powerful
interface that doesn't suck and so won't force them to do direct poking
something.

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