WritePixels missing frame value

Monkey Forums/Monkey Bug Reports/WritePixels missing frame value

EdzUp(Posted 2016) [#1]
When creating a image you can use Image.CreateImage( width, height, frames) and GrabImage can grab x number of frames but writing to the image using WritePixels you cannot specify a frame to write to.

Is this a oversight or is there another way to get this working as I would like to write a animated image to a monkey internal frame image system but cannot as you can index the frames.


ImmutableOctet(SKNG)(Posted 2016) [#2]
From what I remember of Mojo 1's weird all-in-one system, they share a surface. So, theoretically, the image you write to is effectively an atlas anyway. If you wanted to write to the "sub-images", wouldn't you be able to do this before calling 'GrabImage'?

I'll be honest, what you're asking is pretty weird already. If it's just about writing to the set of images, then it's just a very long surface.

Basically, it's "width x frameCount" long, so each image starts every width pixels on the same surface. This means you can just call 'WritePixels' with the x argument at multiples of the frame-width you used to make the original image.

In other words, they share the same surface, and 'WritePixels' doesn't care. With that said, I'm actually not sure if the debug logic for 'WritePixels' is correct, so that may actually be a bug itself.

If you're using Mojo 2, then there's a few better ways to do this, but a lot of this particular method is the same deal.


EdzUp(Posted 2016) [#3]
What I'm wondering is loading the image can the frames be done later.


ImmutableOctet(SKNG)(Posted 2016) [#4]
I'm pretty sure it doesn't matter, but that might be target-specific. Just keep the shared surface in mind.

At this point, it sounds more like you just want to use an atlas for your graphics, which is the right answer to begin with. Honestly, you really shouldn't be making them on load-time unless you have to.

If you really want to make your own atlas system dynamically, you can still use 'CreateImage' with 'LoadImageData' from the OpenGL modules. You'll be limited to mostly OpenGL targets, though. There's also using the 'GraphicsDevice' stuff directly, but that may be locked down a bit too much. I'd suggest just using 'LoadImage' for static graphics, and 'CreateImage' for dynamic.

You can get the effect of a single shared surface by using a tool, though. Then you just need to use 'LoadImage' and 'GrabImage'. That's going to be the easiest route.

With that said, if you need to use 'WritePixels' dynamically, you should probably look into shaders. The easiest way to use them is with Mojo 2. I wrote a compatibility layer, but the CPU pixel-manipulation commands haven't been tested. I'd recommend porting to Mojo 2 properly, though.

If that doesn't cover your bases, then you need to be a bit more specific. It just sounds like you want to do what an external program should do, or what should be done while you're loading your game. Anything more than that is shader territory.


EdzUp(Posted 2016) [#5]
Basically what I want to do is load pixel rgba data into a frame of a image for example;
1) create a image with ten frames
2) fill all the frames with pixel rgba data
3) use frames as a animimage with drawimage

It seems I will have to look at another route with this as grab image has to be done in On render which is out of the question.

The only thing I can think of is create a image for each frame in a array :/


ImmutableOctet(SKNG)(Posted 2016) [#6]
Wait, what? 'GrabImage' doesn't need to be used in 'OnRender' at all. You're thinking of 'ReadPixels', which is awful compared to 'WritePixels'. If you need 'ReadPixels', then you should probably be using shaders, but if you think you have to, it's there. You can use 'WritePixels' and 'GrabImage' whenever you want on any target. 'ReadPixels' must be in 'OnRender' because it literally reads from the back or front buffer.

At any rate, there is a bug where I thought there was. You can create a set of images with 'CreateImage', but you can't write to all of them in debug mode. This is because there's no relationship between the generated images. There's two ways for Mark to fix this, one's dead simple, and the other may be intended.

Here's an example that tests my claim, and should help you with 'WritePixels'. (Raw file)

The 'WRITEPIXELS_DEMO_HACK' declaration at the top can be commented out to see what I mean (Build in debug mode, then in release). I'm not sure what Mark's intention with 'WritePixels' actually is. I'll make a bug report shortly.

EDIT: I made another topic regarding this particular issue.


EdzUp(Posted 2016) [#7]
Ah ok I will have a look what does grab image grab from?


ImmutableOctet(SKNG)(Posted 2016) [#8]
The image you're using it with. It's a method, not a function. It's what you're supposed to use to grab an area of an atlas (Big image made up of smaller images). If you've got unrelated or differently sized images, it's the best way to store animations. With 'GrabImage', you can just use a tool to pack the images and grab based on the named coordinates it outputs.

Look at a tool like Sprite Sheet Packer, which gives you a file in plain text. The file gives you the names of the files and where they are placed on the atlas. With this, you can pack a lot of files into one image, meaning you (Mojo in this case) only have to pack your resources into a few surfaces. Since surface (Texture) numbers are limited, even on today's hardware, they're very useful. They also speed up your game significantly, since the graphics card only has a few textures to work with.

In your case, if you intend to create animated images on the fly, you should pack them into an atlas (Large shared 'Image') if you have a lot of them.

As a side note, I made this topic for the bug I was referring to.


EdzUp(Posted 2016) [#9]
Ah thanks I thought grab image was like BlitzMax and had to grab from the back buffer as it uses a stored image for the atlas and to provide the uv coordinated for the frames I will use that for the system :)

Once again thanks for that it's a great help :)


ImmutableOctet(SKNG)(Posted 2016) [#10]
Just a heads up: I accidentally forgot to push the latest version, so 'WRITEPIXELS_DEMO_RELATIVE' actually works now. It's not relevant unless Mark makes 'WritePixels' image relative, so if you're not interested, don't bother getting the latest version of my demo.


EdzUp(Posted 2016) [#11]
ImmutableOctet:thanks for your help mate finally finished the packing system so instead of sixty files there's now five binary packs. The entire image system is loaded from these files and just takes about a second to load it all.

Now I have that done I can get everything else completed.

Once again thanks mate