Well, if you have locked mipmap level 0 and your color format is A8R8G8B8, then yes. But Get/SetPixel() methods works with any type of mipmap level and color format. You can see the source how they take into account all the parameters. But still you can do it yourself having "void*" and in native Irrlicht its the only way. I try to wrap things for C#, using of which doesn't require that much knowledge (i'm saying that C# is easier than C++).Its nothing more than:
First of all there is no Texture.Lock() in Lime, so:What do you think about IntPtr Texture.Lock(...)? IntPtr.Zero could perfectly signal of failure, its as close to original api as it gets and saves us creating a new object.
1) if you suggest to add one, then i disagree because TexturePainter is a tool exactly for this purpose - it wraps lock()/unlock() and all the routine with "void*". Also if i add Lock()/Unlock() to Texture class, then how do any TexturePainter class will track that its texture was locked? Currently the way its done is locking/unlocking can be made only through TexturePainter so it can track the state. The only thing right now is that i assume that user will create one TexturePainter for a Texture, because actually you don't need to call GetTexturePainter() every time you need to place a single pixel on the texture, you can do it once and work with painter until texture is not unloaded. This is not obvious maybe, but for this pupose i made method GetTexturePainter() (not a get-prop TexturePainter), because it creates new TexturePainter object. I guess i will change that a bit, so it will be more safe and consistent. Any way, my change will be only related to the fact that each Texture may has only one painter object in the program. So user will not have to store it to work with it further. Well, currently is ok to recreate painter even every frame -- that is no problem for app stability, but your painters must not co-exist in one time and be used simultaneously. I mean for now next code shows wrong usage and i treat it as bug and i will fix that:
Code: Select all
Texture t = driver.GetTexture("1.png");
TexturePainter p1 = t.GetTexturePainter();
TexturePainter p2 = t.GetTexturePainter();
p1.Lock();
// now: p1.Locked == true, but p2.Locked == false
// ------ after the fix code above will look like next -----------
Texture t = driver.GetTexture("1.png");
TexturePainter p1 = t.Painter;
TexturePainter p2 = t.Painter;
p1.Lock();
// now will be: p1.Locked == true, but p2.Locked == true, t.Painter.Locked == trueCode: Select all
if (painter.Lock() != IntPtr.Zero) { ... }
// instead of simply
if (painter.Lock()) { ... }Yes i can do it, but the problem with finalizers is that you cannot predict when and in what order they will be called by garbage collector. This may lead to things like sometimes your buggy code will work and sometimes - no. That is why we pay a price by explicit call to Drop() -- we call it and we forget about the pointer. If you're not sure when to call Drop(), there is a simple rule: if you called method starting with "Create" word OR you called Grab(), you must call Drop() after. That is why we have code like:And i have another question. Grab/Drop stuff made me wonder..
Code: Select all
SceneNodeAnimator anim = scene.CreateFlyCircleAnimator(new Vector3Df(0, 15, 0), 30.0f);
cam.AddAnimator(anim);
anim.Drop();