Tile Editor Scripts

[jake13jake]

I would like to know what people have seen for tile editor scripts and what they think is the best one they've seen. Reason for this is that I made one and I want to know how much I can brag.

The only problem I really had that I didn't try to overcome was the transparency thing in the pics1.png. I didn't know that more than just #000000 and #ffffff could be transparent (I tried a showpoly of #ffffff behind it) so I just figured it was functional enough since finding a solution to that would add a lot more bulk to the script than necessary.

I actually did script a small fix to the 1024th pixel bug, however. I had to institute it twice.

[Lance]

It's often better to let your script brag for itself then to post such a thead.

[jake13jake]

Lance, to be honest, I'd want to ask Master Storm (manager of classic) before I post my script. It's well rounded and I wouldn't know if he'd want to keep it for Classic or if he'd want everyone to see it.

It's mouse controlled.
You can move and resize the window that it's in.
You can scroll through the entire tileset.
The scroll and resize coords round to fit tiles.
You select multiple tiles by dragging the mouse.
The first tile you clicked on is always in your selection.
The tiles while laying are on layer 0.
The only thing it really lacks is bucketfill, copy and paste. and I'd rather have those in a different script anyway, maybe one that uses predefined objects.

If you come to Classic and get a chance to go to gctilechangerb.nw you would be able to see it.

So, Lance, do you care to discuss the transparency issue or was your entire goal...? Anyways, thanks for the posting advice *cough* gotta get to school now!

[Admins]

Sounds interesting, I will check it
You shouldn't use pics1.png though, Graal only reads its pixels into a buffer but doesn't use the alpha or transparency values, it's not creating a texture for it either. So it would be better to use several separated tiles images may be, although for v3.1 I also plan to add a command for drawing tiles (including the addtiledef things) into a drawing panel.

[EikeSiewertsen]

Originally Posted by Stefan

I also plan to add a command for drawing tiles (including the addtiledef things) into a drawing panel.

Ah, yes, that'd be great, please also add a function that allows setting the RGB values of a picture or rectangle.

[jake13jake]

Originally Posted by Stefan

You shouldn't use pics1.png though, Graal only reads its pixels into a buffer but doesn't use the alpha or transparency values, it's not creating a texture for it either. So it would be better to use several separated tiles images may be, although for v3.1 I also plan to add a command for drawing tiles (including the addtiledef things) into a drawing panel.

You're probably right about pics1.png. It would probably do to make a brand new window script that shows images that contains an array in it's initialization that define x and y values (arrived at from scrolling) of any image and the specific image. Also, maybe inner width and height. Scroll rounding wouldn't be something I would put into a typical window script, but it works for a tile editor script.

Let me tell you that it's quite a bit easier to use one image, but just not as dynamic.

Now that I think about it, you could probably use the tile selector concepts from me in the default editor. Graal's tile selector can be at zero width or height or both. I wanted to evade that, so I just made it so that there's always at least one square selected, which would be the square first clicked on. I had to change the initial mousex,mousey saved values to do that though which scared me a little bit, but worked. In any other situation I'd probably make new values.

[Alexander]

Originally Posted by jake13jake

Lance, to be honest, I'd want to ask Master Storm (manager of classic) before I post my script. It's well rounded and I wouldn't know if he'd want to keep it for Classic or if he'd want everyone to see it.

It's mouse controlled.
You can move and resize the window that it's in.
You can scroll through the entire tileset.
The scroll and resize coords round to fit tiles.
You select multiple tiles by dragging the mouse.
The first tile you clicked on is always in your selection.
The tiles while laying are on layer 0.
The only thing it really lacks is bucketfill, copy and paste. and I'd rather have those in a different script anyway, maybe one that uses predefined objects.

If you come to Classic and get a chance to go to gctilechangerb.nw you would be able to see it.

So, Lance, do you care to discuss the transparency issue or was your entire goal...? Anyways, thanks for the posting advice *cough* gotta get to school now!

I win mine copied and pasted too =p

[Projectshifter]

Originally Posted by Lance

It's often better to let your script brag for itself then to post such a thead.

::nods::

[Admins]

Originally Posted by jake13jake

You're probably right about pics1.png. It would probably do to make a brand new window script that shows images that contains an array in it's initialization that define x and y values (arrived at from scrolling) of any image and the specific image. Also, maybe inner width and height. Scroll rounding wouldn't be something I would put into a typical window script, but it works for a tile editor script.

Let me tell you that it's quite a bit easier to use one image, but just not as dynamic.

Now that I think about it, you could probably use the tile selector concepts from me in the default editor. Graal's tile selector can be at zero width or height or both. I wanted to evade that, so I just made it so that there's always at least one square selected, which would be the square first clicked on. I had to change the initial mousex,mousey saved values to do that though which scared me a little bit, but worked. In any other situation I'd probably make new values.

What I wanted to say is that you can't use one single image, many gfx cards don't allow it and in v3.1 it is not possible to make textures bigger than 1024x1024 anyway.

[-Ramirez-]

This is a bit off-topic, but oh well, it's Massokre's thread, so it's fine.

Originally Posted by Stefan

Graal only reads its pixels into a buffer but doesn't use the alpha or transparency values, it's not creating a texture for it either.

You mean you don't even create a surface for the tileset? In that case, to draw them on screen, you have to manually copy over the bytes onto the "back buffer" surface, right? Why would you do it that way? "curiosity killed the cat"...

[jake13jake]

Originally Posted by Alexander

I win mine copied and pasted too =p

Copy and Paste is easy, but I would rather put it in a different script because in my opinion it would be better/easier/less confusing to separate the two abilities. I'd try to make something that would allow for predefined objects if I did that as well. All you really have to do for that is to save all of the tile code things in an array. Bucket fill would be a little more difficult, but possible. It's kindof a maze to make. The hard part would be checking for tiles that are the same and connected. Call a for loop checking each coordinate on the four borders of the tile and then checking that tiles four borders and the next tiles four borders. Maybe if I did a function that called itself... I just hope it wouldn't eat up all the memory, and doing that probably would so what might be an efficient way? Replacing the tiles wouldn't exactly be the hard part. Just using modulus from the initial coords could handle that. It would also give more control over how you want the tiles to be laid. The default editor, on the other hand, decides for itself.

Originally Posted by Stefan

What I wanted to say is that you can't use one single image, many gfx cards don't allow it and in v3.1 it is not possible to make textures bigger than 1024x1024 anyway.

It won't be difficult to modify the script so that it takes 2 images in place of pics1.png. It can almost do that the way it is now. It would just need a check if it's over 1024 that would change which image and post that image at the same coordinates but with 1024 subtracted from an x value. So I guess I'll do that.

Originally Posted by -Ramirez-

This is a bit off-topic, but oh well, it's Massokre's thread, so it's fine.

Thank you for your profound respect for others.

[Alexander]

Originally Posted by jake13jake

Copy and Paste is easy, but I would rather put it in a different script because in my opinion it would be better/easier/less confusing to separate the two abilities. I'd try to make something that would allow for predefined objects if I did that as well. All you really have to do for that is to save all of the tile code things in an array. Bucket fill would be a little more difficult, but possible. It's kindof a maze to make. The hard part would be checking for tiles that are the same and connected. Call a for loop checking each coordinate on the four borders of the tile and then checking that tiles four borders and the next tiles four borders. Maybe if I did a function that called itself... I just hope it wouldn't eat up all the memory, and doing that probably would so what might be an efficient way? Replacing the tiles wouldn't exactly be the hard part. Just using modulus from the initial coords could handle that. It would also give more control over how you want the tiles to be laid. The default editor, on the other hand, decides for itself.

You just explained pathfinding, it's also what I did for bucket fill, I removed it out of my script because people started editing all at once, and it just got confusing

[Admins]

Originally Posted by -Ramirez-

This is a bit off-topic, but oh well, it's Massokre's thread, so it's fine.

You mean you don't even create a surface for the tileset? In that case, to draw them on screen, you have to manually copy over the bytes onto the "back buffer" surface, right? Why would you do it that way? "curiosity killed the cat"...

Because its faster (and needed for 3d terrain anyway)? In OpenGL there is no function for copying one texture into another texture, so for drawing it into the tiles buffer(s) we copy the pixels, line by line.

[-Ramirez-]

Originally Posted by Stefan

In OpenGL there is no function for copying one texture into another texture, so for drawing it into the tiles buffer(s) we copy the pixels, line by line.

Oh, I had completely forgotten about OpenGL... not to mention 3D terrain. :P