Pixel Data without readpixel?
Monkey Forums/Monkey Programming/Pixel Data without readpixel?
| ||
| Is there anyway to get at the pixel data in array form without having to render the sprite first? I'm interested in preserving the alpha data and as I understand it rendering and then reading the pixels will lose the alpha data as any transparent areas will simply show whats under it, normally black or the color of some other sprite that's already been drawn? |
| ||
| I suspect that for complete accuracy you need to include a separate grayscale alpha-image. If you just want transparency on/off, of course you can encode it using a specific colour. |
| ||
| I'm just wondering if pixel perfect collisions might actually be viable if we cache the colliders in arrays and then do the collision checks based on those arrays.. |
| ||
| It depends on what criteria you want. It's possible to retrieve the alpha value via draw and read quite accurately. The problem occurs if you want to get an accurate colour value from an image that uses low alpha values as rounding in the transparency calculation means that precision is lost. The question is along similar lines to GfK's issues in the thread in the beginner's forum and the same responses apply. You can pre-process the images to create collision maps, draw and read the values to do the same or alter mojo for the platforms you care about to allow pixel data retrieval. That's pretty much just the beginning of the problem though as you then need to work out how to use the collision maps. There's nothing outrageously hard, but certainly an amount of work depending on things like whether you want to have rotating sprites. |
| ||
| nDrawExts2 can do it. http://www.monkey-x.com/Community/posts.php?topic=7702 Use PixelArray.Get(path, [width, height]) |
| ||
| You can pre-process the images to create collision maps, draw and read the values to do the same or alter mojo for the platforms you care about to allow pixel data retrieval. Yep, I've heard all these 'solutions' suggested but 1) I have no idea how to go about any of it, and 2) Nobody has given a working example which can be [easily] implemented in a real-world scenario. As far as altering mojo is concerned, there is no way in hell I'd want to go down that route as you then have the ball-ache of redoing it for every new update. This was always my biggest gripe with Blitzmax which was not "casual game compliant" unless certain modifications were made (and remade per update). Aside from the fact that if I knew how to do that kind of stuff, I wouldn't be looking at high-level stuff like Monkey in the first place. That's pretty much just the beginning of the problem though as you then need to work out how to use the collision maps. There's nothing outrageously hard, but certainly an amount of work depending on things like whether you want to have rotating sprites. Of course you'd want to have rotating sprites. If you can't rotate sprites then we're right back at Blitz Basic, where we were fifteen years ago.nDrawExts2 might help some, by the look of it. Though I must admit I'm very wary of 'middleware' as it almost always ends up abandoned and has caused me no end of problems in the past. I'd much rather this functionality was added officially. |
| ||
| I've been working on a pixel perfect collision detection library for Monkey for a while. The only thing left for me to write is a guide on how to use it, but as this topic keeps coming up, I guess it'd be better to release what I have and finish the guide later. The "Collision Mask Module" consists of: Two applications written in Qt (C++) that run on Windows/Linux/MacOS and allow you to create and view "collision masks" from the alpha data in PNG images. A Monkey module (a single file) that contains the scaling, rotation and collision detection code. Four example applications. An API reference and the custom mask file format specification. The Monkey module is written in 100% standard monkey code and does not require any changes to Mojo. In fact, apart from the Debug display feature, it doesn't even require Mojo. It works on all Monkey targets. Features include: * Synchronous and Asynchronous loading of mask files. * Rotation and scaling of masks. * Pre-allocation of empty masks for use as targets for rotation and scaling, avoiding allocation of memory in the main game loop. * Mask to mask collision detection. * Point to mask collision detection. * Rectangle to mask collision detection. * Circle to mask collision detection. * On-screen display of masks for debugging purposes. Give me a few days and I will put the files on my website and post the details in the relevant forum section. |
| ||
| Though I must admit I'm very wary of 'middleware' as it almost always ends up abandoned and has caused me no end of problems in the past. I'd much rather this functionality was added officially. This is the one massive reason that I dont usually use third party modules, the main one I do use is minib3d which is quite nice and gives good results. |
| ||
| I'd argue that all software will be abandoned by the original devs eventually. Monkey itself will be abandoned by Mark one day. If a library does what you want today and you've got the code then how are you in a worse position than if you'd written it yourself (barring silly hypotheticals about time to understand it over time to write it)? More relevantly to this thread and the one in the beginners forum: if that's your position then fine but you should recognise that requesting community help when your only acceptable response is Mark writing the thing under the official Monkey umbrella is an abuse of people's time and effort. This little saga has gone thus: Thread 1 * This is terrible! I can't work out how to do this thing! - Here's a way. * No no! That's awful. - Here's a way. * How terrible! - Here's a way. * No, that's not the way I want to do it at all. Thread 2 ~ Any way to do this stuff? - Yes, here are some methods, you'll need to do more work though. * Gah! Despite dismissing those things I'm now going to complain that I don't know how to do them and no-one offered further explanation. * Actually, sod the explanation. Where's a complete working example!? * Actually, even if you provide me with working code, I'm not accepting code from you lot! |
| ||
| Details of the Collision Mask Module are here: http://www.monkey-x.com/Community/posts.php?topic=8947 |
| ||
| Muddy shoes - if you can't accept other people's opinions, then stop goose-stepping into their threads and belittling them. Simples. Everybody is having a fair and rational discussion, except you. |
| ||
| GfK, If you don't want me responding to you then don't pull quotes from my post answering the question asked to use as a spring board for your entitled moaning. Goose-stepping indeed. Jesus. |
| ||
| if it makes you feel better GfK, the only 'fragile' part of nDrawExts2 comes from having to manually flush the "to draw" queue, I guess it would be. It's a single command which changed twice over the course of me having owned Monkney. I predict it won't change again until Mojo supports shaders or gles20. The rest of the program uses gles11 which is a module that comes with Monkey, so that part's unlikely to break. Also to note that it only works on GL targets, so no vanilla html5, flash, xna, or windows 8. |
| ||
| GfK, If you don't want me responding to you then don't pull quotes from my post answering the question asked to use as a spring board for your entitled moaning. Goose-stepping indeed. Jesus You can respond all you want - just change the manner in which you're doing it. Jesus, indeed. |
   |