[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xfree-render
Subject:    Re: [Render] Would there be any value in inviting input from 3D act
From:       raster () rasterman ! com
Date:       2000-08-04 3:09:59
[Download RAW message or body]

On  3 Aug, Jon Leech scribbled:
->  On Thu, Aug 03, 2000 at 08:31:41PM -0700, raster@rasterman.com wrote:
->  > not as far as i know - even if it is it still is a copy across the bus
->  > from system ram to the gfx card - this negates any of the absolutely
->  > blistering fill and alpha blend/scale speeds you can get on todays
->  > hardware (where the data has to be local to the card - ie in video ram
->  > - yes AGP memeory is there too - but it still means a copy each and
->  > every time form client memeory to server memeory every time - no
->  > ability to retain the data like sprite data as textures which you would
->  > do if you implimented it properly)
->  
->      If you want to use sprite data as textures, then use sprite data as
->  textures, for heaven's sake. Just because something wasn't designed with

ummmmmmm - that's what i said. if you want to use sprites and avoid it
traveling across the bus or from client memory to server memory then you
have to use textures. if you didn't you'd lose on performance - the
previous mail was in refernce to it being a game platform - thus i
think we can safely assume we're talking about pc's - what sgi
hardware does i don't think is relevant to game developers - thus i dont
think anything i said is incorrect.

->  Intel PeeCees in mind doesn't mean it was implemented "improperly". Or,

the fact that i cant send data to gl once as an image (NOT as a
texture) get back some ID for it (like a pixmap id) and then re-use it
just like i did before WITHOUT a pointer points to a much mroe hardware
specific design. if i was able to store this and get an Id back - then
it would have been better design (seeing tectures have limits such as
power of 2 sizes whihc arent very favorable for sprites where games may
have many many many small sprites that aren't powers of 2 thus lots of
memeory waste). As the design stands it assumes graphics accelerator
space and pointers in client space are the same memory space (or easily
mapped via hardware) - this may be true of sgi boxes - but it is not
true of many other architectures (I won't go into AGP memory here since
that's a kettle of fish on its own). The read/writepixels for gl were
designed with sgi hardware in mind more than generic applicability for
developing 2d rendering systems ontop of them. this is all fine and
good  and they do their job, but it limits the ability to accelerate
them.

->  if enough applications start using DrawPixels in display lists and
->  asking for it, the drivers will start optimizing that case pretty darned
->  fast.

chicken and egg. no one will use it if its slow, and it won't be
accelerated unless its used. i'm pointing out to get it done fast: use
textures & polys. this will be fast either way.

->      If people would stop mischaracterizing and attributing to bad
->  interface design what is actually poor driver implementation,

i dont think i mentioned anything about interface design of opengl. i
was talking about properly implimenting a game/sprite engine. i have a
feeling you have misread what i said. a badly implimented game engine
would choose to use routines tha are currently not well accelerated, and
due  to the nature of hardware at this current time for the target
platform (the home PC running X on linux most likely), in lieu of
routines that would provide better acceleration - that would IMHO not be
a good implimentation of a game engine.

->  discussions of OpenGL as a 2D API would be a lot more productive.

that's what i did - suggested using textures instead of glwritepixels
which would make for a fairly slow 2d api on the platform in question.

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com     raster@valinux.com
                                    raster@enlightenment.org raster@linux.com
				    raster@zip.com.au

_______________________________________________
Render mailing list
Render@XFree86.Org
http://XFree86.Org/mailman/listinfo/render

[prev in list] [next in list] [prev in thread] [next in thread]