may I know what's the meaning of GEM_DEPRECATED and why it appears on most fields of GemState ? are those fields going to be removed in the future ? How far is that from now ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sun, 4 Apr 2010, Mathieu Bouchard wrote:
may I know what's the meaning of GEM_DEPRECATED and why it appears on most fields of GemState ? are those fields going to be removed in the future ? How far is that from now ?
nevermind, it's not just deprecated, it's not working anymore already.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Mon, 5 Apr 2010, Mathieu Bouchard wrote:
On Sun, 4 Apr 2010, Mathieu Bouchard wrote:
may I know what's the meaning of GEM_DEPRECATED and why it appears on most fields of GemState ? are those fields going to be removed in the future ? How far is that from now ?
nevermind, it's not just deprecated, it's not working anymore already.
or is it working ? i'm confused.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Mon, 5 Apr 2010, Mathieu Bouchard wrote:
or is it working ? i'm confused.
Had compiled with wrong headers. Ended up doing this :
struct GemState92 { int dirty, inDisplayList, lighting, smooth, texture; pixBlock *image; GemState92(); ~GemState92(); void reset(); }; struct GemState93 { bool dirty, inDisplayList, lighting, smooth; int texture; pixBlock *image; GemState93(); ~GemState93(); void reset(); virtual void your_mom() = 0; }; ... void render(void *state) { if (gem>=93) ((GemState93 *)state)->image = &m_pixBlock; else ((GemState92 *)state)->image = &m_pixBlock; } etc
therefore I can support both with a single build.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 2010-04-05 08:09, Mathieu Bouchard wrote:
On Mon, 5 Apr 2010, Mathieu Bouchard wrote:
or is it working ? i'm confused.
Had compiled with wrong headers. Ended up doing this :
struct GemState92 { int dirty, inDisplayList, lighting, smooth, texture; pixBlock *image; GemState92(); ~GemState92(); void reset(); }; struct GemState93 { bool dirty, inDisplayList, lighting, smooth; int texture; pixBlock *image; GemState93(); ~GemState93(); void reset(); virtual void your_mom() = 0; }; ... void render(void *state) { if (gem>=93) ((GemState93 *)state)->image = &m_pixBlock; else ((GemState92 *)state)->image = &m_pixBlock; } etc
therefore I can support both with a single build.
the idea is to drop all those public members and make them available via a get/set system, so new member variables can be introduced without breaking binary compatibility (and without having an ever-growing header file) it's not there yet.
hopefully it will be there for 0.93
gmadr IOhannes
-
IOhannes m zmoelnig -
Mathieu Bouchard