MTM2.com

Is there any problem in using 256x256 textures in mtm2? I'm using a 3Ghz Pentium 4 with a fast video card (ATI Radeon 9600 TX) and I want to know if 256x256 textures slow down the frame rate on slow machines to unaceptable values, or if could be any other problem. I'm asking it because people tend to use 64x64 in all the tracks I've seen. I'm trying to build my 1st track... so a little patience with this newbie will be apreciated. Also, english is not my main lang...

This track was made using 256x256 textures.

http://cownap.com/~tracks/details.cgi?t=3883

The limits are programmed into the game, so once you get over a PII, hardware won't bring the gains we'd like. As far as what those limits are and what practical guidelines you should use, the above track is the only one to use 256x256ers so far - so anything you might do will certainly contribute to a better understanding of what can and can't/should or shouldn't be done. In short, the field is very much wide open when it comes to larger size textures.

Thank you Phineus, that's what I wanted to hear. 256 textures looks much better so I'll use them as much as I can. These are screenshot samples of 256 textures I'm working on:

http://personal.telefonica.terra.es/web ... enshot.jpg
http://personal.telefonica.terra.es/web ... nshot2.jpg

These are the textures, for anyone who want to test them and give some feedback:

http://personal.telefonica.terra.es/web ... ass001.raw
http://personal.telefonica.terra.es/web ... ound32.raw

Both use the metalcr2.act palette, everybody will have it but I link it here too:

http://personal.telefonica.terra.es/web ... TALCR2.ACT

By the way... is good to be new with ppl like Phineus around.

When using 256 textures I'll take care for the pod file size not to be very large. 256 texturs are 16 times bigger than 64 ones. I hope it won't be a problem. If it is then I'll mix 256 and 64 textures. Right?

Yes, you can certainly mix the sizes you use.

I'd recommend using as many 64x64 textures as possible, and just use 256x256 files when absolutely necessary. It does create less lag in the game.

But go ahead and experiment. As Phin said, "the door is wide open". That doesn't mean all will be ok. It means that we are not sure what the effect will be if you use massive numbers of 256'ers. The only way to find out is to give it a try. If the track BETA turns out to be too laggy, you could always redo it with smaller textures.

As a guideline, ZOON (a long-time excellent trackmaker) used many 256x256 textures in his first "zoon kitchen" track, but elected to use much less of the larger texture size in his second kitchen track, due to lag or some other good reason(s).

I made some of the models for Zoon Kitchen-2, and I had to use large texture files for the couch/chair models. They looked terrible using 64x64 RAWs. The couch was part of the racecourse, and would be seen up very closely, so extra detail was necessary.

Yes, it was lag the thing I was afraid of when I posted this. Is not easy to make my computer lag with mtm2, but I guess other ppl are used to it. The first time I saw mtm2 it was almost unplayable due to lag on that computer.

A simple testing of massive using of 256 textures is easy to do. SmokeAndMirors track is already testing it. I mean that just filling the whole map with 256 textures is enough as a first test, doesn't matter if it is only one texture or 100 different ones. What counts for lag is the number of 256 textures present in screen at same time. A lot of ground boxes must be added too to complete the test. I think the best I can do is make a track full of 256 and see what ppl with slow machines say. Or just tell me if you already know it so I can save the time.

On the other hand, 256 textures are the future (for this game I mean) since computers are faster and faster... soon nobody will lag with 1.000.000 ground boxes in scene... The game will deserve a little hacking to put it to work with true color textures, heh :p I bet somebody is working on it, isn't it?

As soon as you get something in the way of beta together let us know. I run with a pII 450 and a tnt 16mb vid card to render those 256'rs... I'll make a good low end lag rat

Previous discussions about this subject...

http://forum.mtm2.com/viewtopic.php?t=1380
http://forum.mtm2.com/viewtopic.php?t=2578

I just read a lot of interesting things in the links of above... like ususal on this forum
I'll try to assimilate it all before start spreading my newb opinions...

But there's one thing I want to ask now.
I've read about the need of a 256 slicer. I guess slice is not currently a problem with Traxx 1.4. But what about a 240x240 slicer and edger tool? I mean a tool which accepts blocks of 240x240 core textures, then slice them AND add the edges. Is there anything like this, for 256? This is quite easy to do. I can write that program if there is no equivalent around.

Is good to see Malibu. I love your work. I will upload my 1st track to beta as soon as I have something presentable, It'll be soon if I don't stuck in technical aspects and tests...

> I guess slice is not currently a problem with Traxx 1.4.

Slice60 is probably the better way to go since it will handle any factor of 60, whereas traxx tops out at 16x16 tiles. Also, traxx does the inner edges, but not the outer edges.

http://cownap.com/~mtmg/slice60/

> what about a 240x240 slicer and edger tool?

There isn't one. If this is something you could create, I know a few people around here who would be sure to use it.

Ok. The first thing that comes to my mind is about graph formats. This is what I think:

-The program will accept 8 bit BMPs or RAW/ACT files containing blocks and it will generate collections of single RAW/ACT pairs secuentialy named with a prefix given by the user.

-It will work with both 64 and 256 sizes. Is there any sense in let the program to be open to other sizes? like 32 or something like this?

Correct me if I'm wrong. I'll wait for some input before start coding.

Be aware of the severe limitiations on the number of 256 textures you can use. The MTM2 engine cannot handle more than 64 at any time, and furthermore it cannot swap 256 textures without noticeable lag.

This thread may interest you:
http://forum.mtm2.com/viewtopic.php?t=2578

> graph formats.
> The program will accept 8 bit BMPs files containing blocks and it will generate collections of single RAW/ACT pairs sequentialy named with a prefix given by the user.

Sounds good, however you won't need the raw/act files to begin with. Just uncompressed bmp or tga should do the trick. You'll want to check the file dimensions, and probably color depth, before processing to make sure they are indeed multiples of 60 or 240 in size.

Also, Slice60 gives the option to create the overlap vertically, horizontally or both (or neither), and it gives the option to do inner seams, outer edges or both. I've found that flexibility to be very handy.

> It will work with both 64 and 256 sizes. Is there any sense in let the program to be open to other sizes? like 32 or something like this?

Not in this game. 64 and 256 covers the terrain.

> Correct me if I'm wrong.

You're not.

> Be aware of the severe limitiations

I had a feeling rocketalces wouldn't be too far off ;-)

The way I look at it is this: Smoke & Mirrors shows that 256x256ers can be used successfully. But it was tough to build. If a texture set could be made so it rotates too, then there's plenty more to experiment with. However, the burden of slicing is a deterrent to more tests and possibly more worthy tracks. If we have a programmer on hand who is willing to give it all a try, then I can find no reason not to move forward with it. Even if 256x256ers have limited application, it'll certainly be worth having the tool for those instances where it's desirable.

Ok. Thanks to rocketalces for the 64 maximum. 256 textures are 64 KB long. 64KB x 64 = 4MB. It was normal to assume that limitation when the game engine was developed. Now, my video card has 128 MB of fast-like-hell memory, and my system mem is 512 GB of fast DDR RAM, and it's not the best PC machine you can find.

I'll follow your guides, Phineus. Please, tell me more about the rotation you mentioned. I think I know what you want but I prefer to know exactly what you want. You mean you want the program to be able to rotate the textures, so you'll be able to build a whole road circle based on a single quarter?

What I meant was that the template tutorial shows how to create a texture set that does not rotate. But since there are concerns about the number of 256x256ers that get used, the ability to rotate them would reduce the number required in quarter. Rotating textures is something both traxx and tracked2 allow.

That's all I meant.

As for a program, most programs that generate tiling textures work under the assumption that they do not need to be, nor will they be, rotated. Making them tile AND rotate would be some trick. More than I could do at the moment.

hmmm... I don't understand some things. You mean a tile which is always seamless no matter what sides are in touch? dern... I still don't understand lol

I understand what rotation is and I have played with it in Traxx, I understand that using rotated textures can reduce the amount of textures, because you need only a quarter to build a whole road circle, for example. What I don't understand is what the slicer program can do about it.

> What I don't understand is what the slicer program can do about it.

Directly and specifically, probably nothing. My response to rocketalces was that limits needn't hamper progress. Although there are most definitely limits, whether they ever needed to be put in place or not when the game was made being beside the point, that there are other factors, eg rotation, that can still be considered which will allow the use of 256x256 terrain textures.

I agree with you, now that I know what it is about. Even if the use of 256ers has severe limitations we still need a 256 slicer/edger. I already started coding it.

Next thing will be a tool to automate transitions, taking two 60x60 or 240x240 seamless textures and generating the whole set of transitions between them. It also can be done without working a lot and could be a useful tool too. Is there already a tool to automate transitions?

> Is there already a tool to automate transitions?

Nope, and that would be great if you could pull it off. But just to be clear, do you mean this sort of thing?

http://www.geocities.com/TimesSquare/Co ... es/e13.gif