Hi,
"Anton" <anton.txt@[EMAIL PROTECTED]
> wrote in message
news:Xns99DF9CED93704antontxtgmailcom@[EMAIL PROTECTED]
> Ron AF Greve
>
>> Well I said I simplified things. If the system really has nothing to
>> do it waits for a very small amount of time
>
> Oh, I did think of this little trick!
>
>> How the graphics subsystem currently works (but I am switching to 3D
>> so this is changing).
>
> Yeah, I can't understand one of operations (probably the most im****tant
> one
> :):
>
>> When nothing has changed return
>> else
>> Build a list of squares of new and old locations and make this in
>> a minimal list of non overlapping squares.
>> Sort the graphics back to front.
>> Go through the list of graphics objects (back to front)
>> If they intersect with the non overlapping squares call there draw
>> member with the intersection of the overlapping square and the square
>> the graphic currently occupies on the screen.
>>
>> When all is done the backbuffer contains the new screen images and
>> this is just bit blitted to the screen.
>
> You have old locations and new locations. If they do not coincide, the
> object has changed position, but they must intersect anyway, or the
motion
> won't look smooth...
Hmm, note that the graphic system itself isn't concerned with what gets
drawn on the screen. It just keeps track of changes then call the
graphic(s)
to redraw a part. Old and new positions are just two squares on the screen
that needs redrawn. Graphics occupying one of those squares have to redraw
a
part of them. As a result a animation would automatically disappear from
the
old location and appear in the new one.
>
> Then, what does "making them in minimal list of non overlapping squares"
> mean? What types of squares and what lists are there in your system? I
am
> really confused!
>
The squares are just simple rectangles left,top,right bottom or
x1,y1,x2,y2
whatever you prefer.
First of I don't want them to overlap because when I intersect this list
with all the graphics that occupy (part) of those squares and squares
overlap, some graphis will get intersected more than one time for the same
(changed) square and will be asked to redraw themselves more than one
time.
This would be of course a complete waste. So the squares in the list with
changes shouldn't overlap.
Minimal because when you have two overlapping squares you likely get 3
non-
overlapping in return. With a large list you might be able to join some
together into new ones. And yes with a lot of changes this really
outweighs
drawing stuff multiple times or not joining them together.
In the system.
A list of graphics having there old position and new position. They might
change positions due to scripting timing or anything else outside the
graphics system. So the square occupied before needs to be there when
redrawing the screen (it needs to be redrawn since the image that was
there
should disappear).
Any specific data like images/animations/procudurals are in the derived
objects from CGraphic.
In short:
So baiscally the graphics hold a list of graphics (which is for the most
part just an interface) however the graphics do contain two squares the
old
and new position.
During the rendering phase an aditional list with rectangles is created
holding the changed locations.
Graphis are intersected against that list back to front. If they intersect
they are called to redraw that intersection.
>
>> However with directx I am going to redraw the whole screen when there
>> is a change. Trying to keep track of changes it not going to
>> beneficial I am afraid.
>
> Well, it is definetly a must for 3d, but optional for isometric gfx.
Regards, Ron AF Greve
http://www.InformationSuperHighway.eu
|
