About Monkey 2 › Forums › Monkey 2 Programming Help › PixMap->Image bug
This topic contains 9 replies, has 5 voices, and was last updated by
Mark Sibly
2 years, 9 months ago.
-
AuthorPosts
-
July 4, 2016 at 4:51 pm #1697
I’ve been trying to work with a PixMap then load it as an image to display on the screen. After trying everything with my current project, I decided to make something very simple to see what is going on:
Monkey123456789101112131415161718192021222324252627282930313233Namespace myapp#Import "<std>"#Import "<mojo>"Using std..Using mojo..Class MyWindow Extends WindowMethod OnRender( canvas:Canvas ) Overrideglobal i:IntLocal pm:=New Pixmap(640, 480, PixelFormat.RGB24)pm.Clear(New Color(Rnd(0,255),Rnd(0,255),Rnd(0,255),1))Local img:=New Image(pm,TextureFlags.Dynamic)canvas.DrawImage(img,0,0)App.RequestRender()EndEndFunction Main()New AppInstanceNew MyWindowApp.Run()EndThis will bomb out with an error
Invalidate PixelFormat
{{!DEBUG!}}July 4, 2016 at 6:24 pm #1726Same error here to.
Your clear color part. Is it not so that monkey has colors between 0.0 and 1.0? I changed that and it did not work either.
edit:
If you remove the textureflags.dynamic part then it does work.
July 4, 2016 at 6:34 pm #1727Good point – I actually didn’t know that that the Color class worked in 0.0 to 1.0 for the R G B aspects, the documentation wasn’t clear. But looking at color.monkey2 I can see you’re right. Either way, there seems to be a problem converting from pixmap colorspace to Image colorspace somewhere in the mojo code
July 5, 2016 at 4:01 pm #1757I modified the code a bit and it slows the computer down a lot. Maybe a memory leak?
In release mode it slows to a crawl.
Monkey1234567891011121314151617181920212223242526272829303132333435#Import "<std>"#Import "<mojo>"Using std..Using mojo..Class MyWindow Extends WindowMethod OnRender( canvas:Canvas ) OverrideIf Keyboard.KeyReleased(Key.Escape) Then App.Terminate()App.RequestRender()' create a pixmapLocal pixmap:=New Pixmap(640, 480)' clear the pixmappixmap.Clear(New Color(Rnd(0,1),Rnd(0,1),Rnd(0,1),1))'create a image with from the pixmapLocal img:=New Image(pixmap)' draw the imagecanvas.DrawImage(img,0,0)canvas.Color = Color.Blackcanvas.DrawRect(0,0,320,20)canvas.Color = Color.Whitecanvas.DrawText("FPS:"+App.FPS,0,0)End MethodEnd ClassFunction Main()New AppInstanceNew MyWindowApp.Run()End FunctionHow do you paste code?
July 5, 2016 at 4:09 pm #1758How do you paste code?
Click on the “<>” above the posting box. Just enter the code don’t click on anything and press Add.
July 5, 2016 at 6:01 pm #1760Thanks. I put the code in the codebox.
July 5, 2016 at 6:08 pm #1761I don’t think it’s a good idea to create a pixmap and an image from the pixmap every frame specially of that size. Creating the pixmap, clearing it, and converting it to an image are very intense operations.
July 5, 2016 at 7:26 pm #1765I don’t think it’s a good idea to create a pixmap and an image from the pixmap every frame specially of that size
Agreed, if all you want to do is draw to a texture, try using an Image Canvas. There’s an example in the Bananas folder.
https://github.com/blitz-research/monkey2/blob/master/bananas/rendertoimage/rendertoimage.monkey2
Also, make sure you use the TextureFlags.Dynamic flag on that texture when drawing to an image canvas that is updated every frame.
July 5, 2016 at 8:21 pm #1767It is just a test. Should locals not be freed automatically when the function is exited?
i thought i did something similar with monkey 1 and that worked without slowing down.
the texture flag gave a compile error as was in the first post here.
July 5, 2016 at 9:06 pm #1768>Should locals not be freed automatically when the function is exited?
You need to image.Discard() images when you’ve finished with them.
This will be partially automated in future so you’ll be able to discard ‘groups’ of resources with one call, but for now images should be discarded manually.
Some people think GC should deal with this, but I disagree. VRAM is precious and I don’t think it’s a good idea to trust the release of VRAM to the vaguaries of the GC system. In fact, this is a pretty good example of why – the app wont actually be consuming that much system ram, so it may well have alloced a LOT of VRAM by the time it gets around to GC-ing – by which time it may be too late.
-
AuthorPosts
You must be logged in to reply to this topic.