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 TRUE when
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 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 array, we
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.
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
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 / clean.
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
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 states, but
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
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 changes whn
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 applied
State management in D3D... is currently kind of a mess.
Stefan D. posted a message about this some time ago, but I can't find it
right now...
- some states are applied immediately (via Set* calls)
- some are applied at draw time (like shaders, textures, transforms, ...)
- some are recorded
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
13 matches
Mail list logo
