PIXMAP
Community Forums/Monkey2 Talk/PIXMAP
| ||
| Hi, PIXMAP'S! Any chance of these wonderful things being in MX2? Rock on, |
| ||
| This would be part of the scope of Mojo 2 rather than the language itself, but yes it would be something nice to have. |
| ||
| Well, we have arrays, buffers, surfaces, and soon canvases. I don't think we need much else. Maybe image encoding and decoding. I know it's not much, but I already made these two modules. Nothing special, but there's also 'LoadImageData' and 'WritePixels'. I think once Mojo 2 comes out, we'll be pretty much set. |
| ||
| ^Yup. I thought this was a good place for that request. But it would be cool to have it in MX2. It is one feature I miss in MX1/Mojo1 and hard to workaround in some cases. Mark tell me there are PIXMAP's in Mojo 2. :) |
| ||
| It would be cool if pix maps were in. It was useful for apps and certain non game related things to be able to manipulate images in RAM instead of on the GPU. |
| ||
| And to render to image: Local image:=New Image( 256,256 ) Local canvas:=New Canvas( image ) 'render to image! Would definitely be nice to have for low-level access, but wouldn't the above mostly take care of what you'd actually want to do with a pixmap? |
| ||
| You always want fast and easy access to data (Amiga/PS4). Textures related this could be create/load/save/encode/decode, read/write/copy access on an per pixel/chunk/colour basis and having access to the framebuffer. |
| ||
| And to render to image: Local image:=New Image( 256,256 ) Local canvas:=New Canvas( image ) 'render to image! The way I understood it, mojo2 does canvas rendering on GPU. This is really useful for sure but it's not the same as having access to images in RAM. I guess if we can set/get the pixels with a byte array/databuffer, that would be suitable! |
| ||
| It was useful for apps and certain non game related things Although generally true not all the time. For example I use PIXMAP's to display massive images as backgrounds in games. Having PIXMAP makes easy to dice up that large image into manageable chunks (ala. PixMapWindow() ). It also allows for easy customization as other large scale images can be loaded and quickly processed. Reading pixel data into arrays is a possibility bit requites a layer of management and is slow. In porting my Phoenix USC project I need to use really massive images so it's problem for me and working around it feels inefficient and kludge-ish. |
| ||
| Yes, now that we actually have pointers to memory, pixmaps of some type will be back! I could probably have this with int[]'s or something in monkey1 - and I may still do! LoadImageData in monkey1's opengl module is definitely moving in this direction, only it returns width/height in a hacky way. I think it is very useful to be able to store image data in a completely 'neutral' way that doesn't depend on textures/canvas etc. |
| ||
| pixmaps of some type will be back! OMG Thanks! Heart Heart. :) Very good news. |
| ||
| Mark, Any chance you could consider making the image loading routines modular. So for example maybe you register extensions to a particular function pointer or class instance. That in turn has code for loading the image data. This way we could write image loaders and plug them into the mojo pipeline. A good example of where this could be useful is if we wanted to say wrap freeimage and override mojo's image loading. We could also add support for new image formats as extended modules. Something like:
Class TGALoader implements MojoImageDataLoader
Method OnLoad:int[](path:string)
End
End
AddImageLoader("tga",new TGALoader)Something like that. |
| ||
| The idea of skn3 is cool! Something similar to bmax factory system :) |
   |