On 12/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Why wouldn't you be able to remove an entry from a list?
With the array, we can only truly remove a single element by moving all other
entries by one, reducing the total amount of entries and adjusting all values
that specify a list index.
Am Dienstag 12 September 2006 18:13 schrieb H. Verbeet:
> On 12/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > Yeah, but we still can't remove the entry. Or wait, set it to 0 and
> > implement state 0 as a nop-apply :-)
>
> Why wouldn't you be able to remove an entry from a list?
With the ar
On 12/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Yeah, but we still can't remove the entry. Or wait, set it to 0 and implement
state 0 as a nop-apply :-)
Why wouldn't you be able to remove an entry from a list?
Am Montag 11 September 2006 23:36 schrieb H. Verbeet:
> On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > Am Montag 11 September 2006 19:56 schrieb H. Verbeet:
> > > On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > > > That's what I'd use the state.changed field for. Set it to
On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Am Montag 11 September 2006 19:56 schrieb H. Verbeet:
> On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > That's what I'd use the state.changed field for. Set it to TRUE when the
> > state is first modified and to FALSE when it it
Am Montag 11 September 2006 19:56 schrieb H. Verbeet:
> On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > That's what I'd use the state.changed field for. Set it to TRUE when the
> > state is first modified and to FALSE when it it applied to gl. Do not add
> > the state to the list of cha
On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
That's what I'd use the state.changed field for. Set it to TRUE when the state
is first modified and to FALSE when it it applied to gl. Do not add the state
to the list of changes whn state.changed == TRUE
Well, sure, that's what the consta
Am Montag 11 September 2006 18:41 schrieb H. Verbeet:
> On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > * Keep a list of dirty states for each gl context in use: We don't need
> > something as fancy as trees for that, a little array can do the job, like
> > this(example for render state
On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
* Keep a list of dirty states for each gl context in use: We don't need
something as fancy as trees for that, a little array can do the job, like
this(example for render states, but can be used for all other stuff too):
You would at least n
Hi,
> Ok, so the main idea is to separate the applying of GL state from the
> tracking of D3D state. Looks like a good idea.
Fully agreed
> What I would like to
> add to that is something BBrox mentioned on IRC a while back...
> grouping related states together and marking that group dirty / clea
On 11/09/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
I guess that seems like a large undertaking, and those are all doomed to
failure.. but it doesn't have to be.
The key idea that I care about seems to be to move GL code from device.c
into the data structure object, and figure out a way to app
I guess that seems like a large undertaking, and those are all doomed to
failure.. but it doesn't have to be.
The key idea that I care about seems to be to move GL code from device.c
into the data structure object, and figure out a way to apply a set of
delayed states at draw time. We don't ha
12 matches
Mail list logo
