In article <fgg1nf$rj7$1@[EMAIL PROTECTED]
>, Serve Lau <aser@[EMAIL PROTECTED]
>
wrote:
>I know that, but I do think its possible to do it platform
>independant, just the display code will have to be different over
>platforms. Why cant you ask for a get_next_frame() and get a void *
>or char * back with the size information etc that you can use to
>display the frame.
Sorry, but this sounds like you happen to have a solution that
worked for you, and think it'll apply to everyone. There's just too
much variety of hardware for this to be meaningful. Consider pixel
formats: some systems only push 8 bit color. Some are 16 bit, in 4444,
5550, 5551, or 5650. 24/32 bit have RGB vs BGR ordering issues. Then
there's alignment and other issues. You can try to sweep these
differences under the rug, and say it's up to the display code to
reformat the color information, but that's going to have severe
performance problems on slower systems, compared to doing that in the
middle of your decode. You're going to thrash your cache if you have
to flip BGR to RGB as a second pass on a decompression buffer.
To decompress things *well* and *efficiently*, you need to know how
the hardware (or graphics API) expects the data. And that's why C/C++
properly say just about zero when it comes to multimedia. The
implementation details are just so significant that they need to be
considered. And therefore, multimedia shouldn't be part of the
programming language, but code to make multimedia happen can be
written in that language.
Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A.
Heinlein
|
