Copy piece of one image into another (tilemap)

[Roboscope]

Hi everybody, I'm trying to create a simple tilemap editor for practice. I went through the first three chapters of the beginner tutorial, but I can't find much info about using images. In SDL, you can copy a piece of one texture onto another. How do you do something like this in LiveCode? Or is it better to use a grid of images, or some other thing I'm unaware of? It would have to be something you can drag the mouse over and keep pasting continually. I'm not afraid of complexity and would rather have the 'right' solution than a beginner friendly one

[dunbarx]

Hi.

Is there something specific about images that you need, or is it just how to arrange and manage your tiling gizmo? In other words, there are fundamental LC things we can talk about, and then there are graphic/image/texture/shading/andSoAndSo things we can talk about.

So is it a geometry/object/layout question, or some graphic type of question you need help with? Write back if any of the above nonsense makes sense.

Craig Newman

[Roboscope]

I guess I'm asking which approach I should use, because I don't want to start down a dead end road

Can you copy a square from one image and paste it into another in LC and is it fast enough? Or is there a better way of doing the same thing? I'm going to need to handle 100,000+ tiles at once.

I don't mind work and study just so long as it's the right way and it pays off

[dunbarx]

Can you copy a square from one image and paste it into another in LC and is it fast enough?

Do you mean copy a portion of an image? In other words, does this do what you are asking? Make a stack with two cards. With a large image on card 1, put this in a button:

Code: Select all

on mouseUp
   choose the select tool
   drag from "100,100" to "200,200"
   copy 
   go cd 2
   paste
end mouseUp

Is this what you mean? If so, we can set the size of the selected image portion, as well as set the location of that portion onto the target card. Or am I missing it still?

Craig

[Roboscope]

Yes That is the kind of thing I want, though when I tried that it switched to card 2 and left it blank

[zaxos]

I'v already made a stack that takes an images, slice it into pieces(32px each for example) and then exports each image. Her's how i did it:
1) Import your images in your stack
2) Set the rect of your stack to the rect of your image(ex:800x600)
3) Create graphic rects along the stack(32px each,which is 25 horizontal and 19 vertical)
4) Export snapshots from each rect of the card
I'v automated the whole process so all i have to do is import the image and set the width and height of each tile.

[dunbarx]

Hi.

Surely check out what zaxos has presented.

But what do you mean "blank"? The image fragment should have appeared on card 2. Make a new stack with two cards. Import an image onto card 1. Make a button on card 1. Put that handler into its script. Make SURE you compile the script. (Hint?)

Craig

[Roboscope]

Okay, it sort of spontaneously started working, it seems that it uses the result of the last manual copy I did and as far as I can tell ignores the copy command in script
But I'm still impressed with the simplicity of the image manipulating

[FourthWorld]

I'm going to need to handle 100,000+ tiles at once.

How big is each tile?

The most common screen size is 1366x768, and with a relatively small tile size of 32px that's only about 1024 tiles. With an even smaller tile size of 24px you'd still only have 1824 tiles; 16px is only 4080 tiles.

The paint method is good, and depending on the variety of tiles and the program structure there may also be some benefit in making polygons for at least some of those. Polygon fill patterns tile automatically, and polygons can be discontiguous. So if you had, say, ten different textures for your tiles, you could conceivably have as few as 10 vector objects to render them.

Another benefit of polygons may be for hit testing, but again that depends on what these tiles are expected to do.

If the count were as low as the numbers I listed above you could use buttons for the tiles, and set each button's icon to the appropriate tile image. This is almost as memory-efficient as using polygon fill patterns, and button icons tend to render faster than having even the same image they use as their icon on screen (not sure why, but that's what I've seen).

[Roboscope]

Thanks for looking into it It's for editing maps that scroll around and are bigger than the screen, and with multiple layers the number climbs high quickly, but this is just an editor and the tiles don't have to do anything except be saved and loaded. I'm using sheets with possibly a few hundred tiles on them, so would polygons still be good?

[SparkOut]

I think polygons would be good, and it may be the best option to scale up to the numbers involved at the top end. I was coming to suggest buttons and set the icon of the button to the image id. This renders surprisingly well.
The advantage in buttons would be that it is a simple matter to address each tile without having to calculate the polygon points.

[FourthWorld]

I'm using sheets with possibly a few hundred tiles on them, so would polygons still be good?

This is an area I've only experimented in very briefly, and many versions ago. So the only advice I can offer for your circumstances is to build as modest a mockup of each as you can, and compare performance and functionality for your needs.

And please let us know what you discover. We haven't seen many side-scrollers in LC, but I know it's of interest and your experiments will be very interesting for those and many other projects besides.

[Roboscope]

Thanks for everyone's help