| From: | Aaron Optimizer Digulla |
| Date: | 18 Sep 2000 at 10:00:16 |
| Subject: | Re: AMIOPEN: Dev Questions |
On Sat, Sep 16, 2000 at 11:35:49PM +0200, Rady Marusa wrote:
> JvdL> This is somewhat disturbing to me. Using the pixmap plot routines is just
> JvdL> way too slow to do anything fancy. Allocating a writing to a programmer
> JvdL> supplied image buffer is just such an often used operation in games, demos,
> JvdL> and anything else that needs to do a lot of changes from frame to frame.
> JvdL> Saying that one must use ave/ave/pix/plot to draw your image is just
> JvdL> stupid IMHO. How does Tao's port of Quake and Doom do it?
>
> I agree!
> Pixmap methods are great for applications and simple games,
> but really not for fast, hi-quality games.
>
> But we need direct access to videoram framebuffer, not to
> pixmap buffer.
"fast, hi-quality games" ?? Excuse me, but I know no game who renders directly
in the framebuffer anymore; they all need specific 3D hardware and thus,
direct access to the framebuffer seems to be futile, at least to me.
One of the more important points is that such "direct access" would also allow
nasty code to wreck havoc with your system so I'm not at all sure if such "hacks"
are a good idea at all (because for direct access to work, you must somehow
bypass the memory protection of the system).
And last but not least, I could not play such "fast, hi-quality games" on
my PDA or cell phone because they will run only on one kind of hardware.
Another point which is against the philosophy of the whole system.
IMHO, the only clean solution is this:
- A game must allocate a private pixmap in which it renders. All the
normal security will apply to this (ie. the game can only currupt its
own memory, etc).
- When a frame has been rendered, the game must ask the OS to copy this
pixmap to the framebuffer.
Since every hi-quality game must do double-buffering anyway, they must
already do it this way, so there is nothing new here. The problem is
of course the second step. It's not because "old, hacky" games don't
need to do it but they render into a hidden framebuffer and then
make that second framebuffer visible, so there is no real "copying"
of the data involved. To make the above concept viable, the new AmiOne
must provide a fast DMA-copy method so games will not have to wait
for the copying to be done.
On PDAs and similar systems, the amount of data to be copied is usually
pretty small (but alas is the available power to copy it). So we might
get away with a highly optimized routine to copy the data.