Pixmaps
Monkey Forums/Monkey Programming/Pixmaps
| ||
| Is there any equivalent? Or any kind of work-around for the lack of Pixmaps? I really need to be able to take one image and draw it onto another. |
| ||
| You have to elaborate a bit on what you are trying to do. There are no pixmaps or anything equivalent. |
| ||
| Well... I want to take one image... and draw it onto another image. I did this in Blitzmax by drawing stuff to the backbuffer then using GrabImage - but GrabImage does something entirely different in Monkey. I'd also like to be able to use ReadPixel and Writepixel to manipulate image data. |
| ||
| You will need to learn to do without. Either pre-bake your combinations or use more complex compositing in your render. |
| ||
| Nope... although I believe all the current targets do support it... (of course HTML5 would be dead slow) |
| ||
| ...but if GLBasic can do it, and as therevills says all the targets support it... why can't Monkey? |
| ||
| "HTML5 would be dead slow" Not really. Compositing is a part of the Canvas spec so implementations are free to optimise behind that spec as much as they wish. There's nothing that stops such operations being comparable in performance to Flash, for example. I'm using on the fly compositing to build UI components with dynamic text. I haven't done any extensive timings but I'm not seeing any obvious performance problems with the HTML5 build. Certainly as far as avoiding multiple renders of the text it's an enormous performance boost across all targets. |
| ||
| I'm using on the fly compositing to build UI components with dynamic text. How's that work - bearing in mind Android and iOS targets? |
| ||
| I do Android compositing via the Java API and it can possibly be done via OpenGL for some more recent devices. I don't have any iOS devices, so I haven't implemented anything for that yet but, AFAIK, the version of OpenGL ES on iOS devices supports render to texture. |
| ||
| I "really" wish we had GrabImage, and a backbuffer. :D |
| ||
| This is another example of why Monkey needs to have target-specific extensions, or at least a way for the community to use a common standard to create these module extensions. |
| ||
| ..but if GLBasic can do it, and as therevills says all the targets support it... why can't Monkey? Mmmmm... a simple case of the auld roll up your sleeves, get it grafting yourself, if its okay, they'll put it in the official code syndrome me thinks! :D Dabz |
| ||
| "get it grafting yourself" Although I did exactly this in order to implement off-screen rendering it's not really an answer. It would be a poor answer even if Monkey were a completely free and open-source project. When considering that Monkey is actually a paid-for product and the specific elements we're talking about (mojo graphics) aren't openly licensed it's even worse. From a customer perspective one of the main or even _the_ main feature that Monkey is sold on is the promise that cross-platform becomes easy. Turning around and then expecting that customer to just roll their own rendering code across every target is hardly in keeping with that promise. Not that I think you're speaking for Blitz, you understand, I'm just pointing out how odd it sounds as a response. |
   |