MTM2.com

Yes, absolutely that's what I meant. It is not really hard... just reading pixels from each images and placing them in the right positions of the final tile collection. I have to think more about it but I'm pretty sure of what I'm saying. The user will have some parameters to tweak so different kinds of transitions can be made (circular, squared, etc).

LOL, if it works, you're making it too easy. Sounds great.

Heh, thx, Phineus. I also think they will be useful tools. For now, I'll be working in the slicer/edger. The 1st beta version will be linked here as soon as I have it tested. A few days will be enough.

If somebody have any suggestions he should speak soon because I'm already coding, and I *hate* rebuilding projects... heh :p

A few thoughts occur to me.

Slice60 is near perfect for what it does. But it's command line. There was a gui made that set up the switches and together they do the job splendidly.

<center><img src="http://mtm2.com/~forum/images/turboSliceGui.gif" width="393"></center>

I'm not saying you need to copy that exactly. However, it should serve as a source of ideas.

==========

Also, there was a program called GreenGiant's Axe.

http://members.tripod.com/~GreenGiant83/Programs.html

<center><img src="http://mtm2.com/~forum/images/GreenGiantsAxeGui.gif" width="281"></center>

It, like traxx, has a preview window that shows lines where the slices will take place. There are two problems with the axe. First is that it does not handle the overlap (it was made for mtm1) and second it no longer runs on the new operating systems (the fate of many older programs). Still, it was handy.

==========

Then, of course, there is traxx.

<center><img src="http://cownap.com/~mtmg/traxx/images/cust08.gif" width="378"></center>

The main problems with traxx is that it does not do the 256x256 overlap properly, and it does not swap the outer edges (on any size), and you're constrained to 16x16 squares maximum. The good things about it are that you have the option to do the overlap or not, you can move the slice grid so an image doesn't need to be a perfect fit or you can slice a part of the image, and, of course, the preview.

==========

An option to prompt for file overwrites is sometimes handy. But low priority.

==========

Would it be possible to detect files that are exactly the same? How might they be flagged? When we're concerned about texture memory, removing every redundancy will help. Would that be built into the slicer, or would it be better as a stand alone that could analyze a directory's content?

==========

In sum, slicing 60 and 240 base textures are the primary goal.

Having thought about it, slicing 64 and 256 base textures without overlapping - just a straight out cut - might still be desirable (for instance, for models or ground boxes or mtm1).

Slice60's stretching feature (ie no overlap) has merit although I don't know how you'd work that with 240 textures.

==========

If anything else comes to mind, I'll holler ;-)

Thank you Phineus, you're saving me a lot of time. I'll try to make a tool with everything that the others are lefting.

So it'll be a tool to just slice 64 and 256 tiles, or slice/edge 60 and 240 ones. Blocks of tiles I mean, of course.

16x16=64. So only one block of 256ers can be used in a track. But, maybe the user wants to generate bigger collections. Ok, no problem to go over the 16x16 Traxx limit.

About not saving repeated tiles... how about let the user decide what tiles are to be saved and what are not? (marking them in ther preview map, for instance). Another tool to analyze a folder for redundant textures could be good too. Hmm right now I don't want to think of it, having enough work for now in process. It'll be another day.

That's certainly a possibility. My thought was there might be a mathematical way to compare, so there's no errors. But everything helps.

Hehe... we will have both... the user can discard tiles and the program will warn of repeated tiles

lol the darn Guest is me :)

Wow, what a quick developing thread! I refreshed the second page after reading it all to see if new posts were still coming in.

Your idea for a tool sounds great xoreax, I am looking forward to seeing it.

Since you asked for suggestions (although at the pace you are on you may be done by the time you read this), depending on how you decide to name the output files, any information the program could provide to help reassemble the tiles into a pattern might help. Just a .txt file with the file names listed in order would be cool, ( I wouldn't be bold enough to suggest an automatically generated .txp file )

Please tell me more about .txp files. I learn fast but there are lots of things I'm still missing, talking about mtm2 in general.

TXP = Traxx Pattern File

It's used to store rectangles of texture arrangments/patterns.

http://cownap.com/~mtmg/traxx/patterns.html

Format not known.

At least, the program will generate a log file containing all names and stuff everytime you slice.

Talking about Slice60...what sense does it make to turn it off the wrap internal edges feature? The edges of the final 64x64 tiles must be filled with something... what sense does it makes to leave them blank? When is this option used? What I'm missing?

I find more logical the external edges feature. By turning on the external edges the whole block can be tileable, seamless. Turning off the external edges will produce blocks that doesn't match the opposite edge (the external sides of the external tiles of the block will match the opposite edge of themselves).

I'm going to introduce the option of redoing the edges for 64 and 256. The initial goal was slice/edge 60/240 and JUST slice 64/256. 64 and 256 tiles are suposed to have the right edges for overlapping, but what if they are not, or you're not absolutely sure of your manual work, you just want to redo the edges to be sure they are right. The program will take the 60x60/240x240 core to overwrite the edges with it, if the users wants.

These are screenshots of the program. I can change anything you want so don't cry if you don't see what you want, just let me know.


First of all, the user goes to the menu and selects "Open Texture Block in Slice Editor":

<img src=http://personal.telefonica.terra.es/web/nanobot/scrprg01.jpg >


Then, the following dialog is launched:

<img src=http://personal.telefonica.terra.es/web/nanobot/scrprg02.jpg >


Once you have set the BMP file and the block dimensions, you hit "Open" button which will close this dialog and launch the Slice Editor (if the file passes all validations) as you can see below:

<img src=http://personal.telefonica.terra.es/web/nanobot/scrprg03.jpg >

Here you can mark, using right mouse button, the tiles for discarding. You set the prefix and desired options and hit "Slice" button to proceed. A log, or .TXP file, is generated while slicing.


My english is not very good... If something is not really english or it's misspelled just tell me.

> Talking about Slice60...what sense does it make to turn it off the wrap internal edges feature?

MTM 1 does not use the overlap, so for that game wrapping the edge would look bad. Also, if slicing textures for models, sometimes you don't want the overlap. A case like this might be for a backdrop. Oh, and the 256x256 ground box textures don't appear to use the overlap so you wouldn't want it there either.



> The edges of the final 64x64 tiles must be filled with something... what sense does it makes to leave them blank? When is this option used? What I'm missing?

You wouldn't leave them blank. You would duplicate the last one or two pixel border of the 60x60 texture and use it to fill to the edge of the 64x64 texture. This is what slice60 calls streaking the edge (instead of wrapping it).


But, and this is where slice60 is weak. If I was making textures for mtm1, I would make the base texture 64x64 so there would be a good edge. Slice60 doesn't do that. Traxx does, but not slice60. This is why it would be good to choose between 60/240 and 64/256.


> the external edges feature.

Currently I'm working on backdrop textures. In those cases, the internal overlap might be helpful to prevent visible seams. But I wouldn't want to swap the top and bottom edges. In that case, there would be transparency on the bottom and grass/mud/dirt in the sky. Not good.

It's not always about terrain textures.



============

> the preview

Looks good so far.

> Discard All Repetitions
> Save Unique Repetitions

I'm not sure, but that's not extra work. Wouldn't we either want to save all or keep just the unique repetitions? I can't think of an instance where we'd want to discard all repetitions entirely. So, if you use radio buttons, we might have this

> Discard Repeated Tiles (this assumes you keep the first one and throw away the extras)
> Keep Repeated Tiles (nothing is thrown away)

And then do away with the check box. Or, if you use a checkbox, it would toggle the two choices and you would need the radio buttons.

Just ideas ;-)

Yes, I was sure it is not always about terrain textures. What I really wanted to know is what slice60 does instead of wrapping... thx, Phineus, for telling me the concept of "streaking". I would have tested Slice60 by myself and check the results, but it's faster to ask here... hehe :p Ok, I'll change "Make Edges" by "Wrap Edges" in the GUI, so it'll be more clear and more similar to Slice60 terms. When unchecked I'll apply streaking. Well... I think I got it all, to code the slicing I mean. I didn't want to start it without knowing exactly what Slice60 and Traxx are doing.

Only one more thing. I think I'll keep the "Discard Repetitions" options as they are now. The "basic_curve.bmp" you can see in my screenshot has 7 pure green tiles. Consider those green tiles as "grass". Imagine you just build the curve block using your standard grass texture, why you would want to save it again? You already have that grass. I think the "Discard All Repetitions" option makes sense, even if rarely used.

> I'll change "Make Edges" by "Wrap Edges" in the GUI, so it'll be more clear and more similar to Slice60 terms.

I like the term "swap" edges because you are actually trading them from one side to the other. But in keeping with slice60 I guess "wrap" works too. I'm fine either way.

> Imagine you just build the curve block using your standard grass texture

Oh, okay. I see where that comes from. I don't work that way myself, but I see what you mean. So, yep, keep it in there.

Here you can see how tiles are manually discarded using the "Discard Tile" popup menu.

<img src=http://personal.telefonica.terra.es/web/nanobot/scrprg04.jpg>

Also, I gave priority to "Save Unique Repetitions" since you told me it will be more frecuent. It is the default action now for automatic discarding. And I've changed the "Make Edges" literals by "Swap Edges". Slice coding still in progress. Everything going ok.

Looks great. One question, tho. What will be the largest base graphic that can be sliced? Or will there be a limit?

In fact there is no limit, only your system resources, of course. I'm considering a max of 256 blocks, and 256x256 tiles per block. In the case of 256x256 pixel tiles... we are talking of 64K*64K*256 bytes size, which is 1 GB. Setting that limit we are dealing with the max amount of system resources available. You will get an "out of mem" error before getting close to that limit.

I want to change the word "streak" by "extend".

English is not my main language so I want to know your opinion.

I think "Swap/Extend" are more meaningful than "Wrap/Streak".

-When slicing 60/240 blocks, the user must choose between "swap/extend". One or the other will be used to fill the edges.

-When slicing 64/256 blocks the user must decide among "swap/extend/do nothing". To swap/extend the program takes the 60/240 core to overwrite the edges with it. Do nothing means... don't touch my edges!