few questions about moviepack/texture creation and settings

[aeralure]

Apologies in advance if these are answered on the Wiki or somewhere here on the forums. I didnt see a result in search that got what I needed. I'm looking to make some textures and then post them here should anyone wish to have some more visual options, but trial and error is slowing me down on a couple things:

In the settings.cfg file I can set MOVIEPACK_FLOOR colors for RGB but usually I see decimal settings in there and not the values of 1-15 as I'd normally expect. I'm getting unpredictable (or no resulting change at all actually) results when I go in and try to change the floor color. How does the floor color settings work? I'm overlooking something obvious I think.

MOVIEPACK_WALL_STRETCH. If you make a rim wall 256x256, or a multiple of 2, I keep telling myself this shouldnt be needed, yet most settings.cfg files place a value of stretch in there. When I go replacing a rim wall png to test within some other moviepack without changing the settings.cfg, I sometimes get odd render reults even if the pngs were the same size. What variables cause the stretch to be needed?

I'm assuming if textured floor is chosen over the dual rendering option, then the upper sky becomes the floor texture also and if both skies are on, the lower sky could have some transparent areas so you see both?

Help appreciated, most especially on the floor color issue and its options. Trial and error on that is hasnt been efficient. lol.

Many thanks!

[Phytotron]

Yeah, these guys chose to have at least three different ways of handling colors in this game. Cycles are determined by the 1-15 values (more or less if you want to exploit the color overflow bug). Color strings in chat use that hex 0xff stuff. Floor colors go from 0-1, with all the decimals in between. Those decimals correspond with percentages, as decimals tend to do: 0.5 = 50%

Zero is no color, and 1 (100%) is full saturation of that color (equivalent to 15 in the cycle color scheme). So, you might have MOIVEPACK_FLOOR_R/G/B set to 1, 0.75, and 0.3, respectively. That means you have 100% saturation of red, 75% green, and 30% blue. (This particular combo would give you an orange-ish hue.)

---

I haven't messed with the stretching.

---

Yes on the sky stuff. The default sky texture has transparency, actually. Thing is, in my epxerience, the upper sky is soooooo high that you can't distinguish what it is. I tried a multicolored floor texture once that just blended into one color at that distance.

[aeralure]

Thanks for clearing that floor color issue up. I had just started putting in three values of .3, three values of .6, etc and saw the #333333 and #666666 parallels taking shape in greys. Good to know its not working in hexidecimal but color %s. Well, it may be actually, but color %s is an easier was to visualize a needed color.

[Lucifer]

Here's a slightly more technical explanation.

Some values, like the floor colors are passed to openGL unmodified, so the value you provide is what openGL expects, which is a rational number from 0 to 1.

Some values, like cycle color, are modified significantly before being passed to openGL, so we take them as integers from 0-15 instead. Then we do stuff, like maybe you've noticed you can't have a black cycle color? That's because black would be very difficult to see, so the game automatically corrects for it.

In the future, we're working on combining all these input methods into one color input that'll be the same everywhere. That'll be nice, but it's not here yet. We'd appreciate serious feedback on what you think, as a third-party extender , the system should look like. Not necessarily technical, but how would you expect to reasonably be able to input colors?

The texture sizes have to do with openGL. As mentioned in another thread (and on my todo list to see added to the wiki), textures really need to be powers of 2 in resolution. There's no hard restriction that I'm aware of anymore, but basically it works like this:

OpenGL works best if you pass them in that way. If you don't, some outdated openGL implementations will crash or something else really nasty. That's not really a problem anymore, but openGL will still run fastest if you pass them in that way. I seem to recall seeing actual code in armagetron that resizes textures automatically if they're not already sized that way. That means we're probably not using the best resizing algorithm for your texture, and you don't want that to happen, so the best thing for you to do is to resize it yourself or build it from scratch at the size you want. That way you can ensure the highest quality for the texture when it gets sent to openGL.

Finally, in a moviepack, there's a settings file for the moviepack. You should put your MOVIEPACK_* settings in it instead. Then when you zip it up for us to see, we'll have it. I have forgotten what it's called, but if you check the moviepack list on the wiki I'm sure you'll find one that contains this file (the classic moviepack has it, at least).

[aeralure]

Thanks! It makes perfect sense when you know a bit more about the backside operations. I'll give color input some thought as I am tinkering around and reply at least my thoughts about that.

I'm experiencing another round of oddness. This one appears to be file formatting and probably something fairly simple I'm overlooking about the way things actually end up getting rendered, but it isnt obvious to me yet which is affecting what.

I have at least narrowed it down now to file saving format. When I load someone's moviepack in and edit one of the pngs and save it back out (the rim_wall.png or one of the floor pngs) I start getting coloring or rendering variances, problems with the way things look. What's the preferred PNG file format and variables required, if any? That has to be where my problem is. PNG-8 alpha transparency 128 colors web adaptive worked for a dir_wall just fine, but it was actually transparent. Saving a rim_wall or a floor with those settings, even when it is solid, isnt working out right. Do those things actually have to be transparent?

I can better write out what I actually did and what I actually tested and the differing results I got if that would help any. Thanks again.

[Lucifer]

It might be a difference in perception. For textures that are attached with a player, they get modified internally based on the player's color. I don't recall exactly how the algorithm works, but it's something to do with the more whiteness in the texture, the more of the player's color gets put in. So if you put straight red on the texture, it won't come out red at all when blended with the player's color, unless the player's color is white, I think.

For other textures, it still depends. The grid floor is just stacked first one way, then another, tiled horizontally each time, which is what makes the grid shape. Same here, the whiter the color on the texture, the more of the floor color gets put in.

rim_wall doesn't get reinterpreted like this at all, afaik, but you have to deal with how its tiled. For smaller rim_wall textures, you'll get some pixellating when it's rendered on anything but relaly low resolution screen. If it's still acting crazy, you should post a screenshot and the texture you used to make the screenshot.

In fact, in general, if you want to post a screenshot and the texture so we can see it, we can probably help a lot more.

[Jonathan]

Some values, like cycle color, are modified significantly before being passed to openGL, so we take them as integers from 0-15 instead.

Actually they can be 0–65535. 0–15 is just what they were supposed to be.

We'd appreciate serious feedback on what you think, as a third-party extender , the system should look like. Not necessarily technical, but how would you expect to reasonably be able to input colors?

Probably 0–1 radiance.

OpenGL works best if you pass them in that way. If you don't, some outdated openGL implementations will crash or something else really nasty.

GLU does it, not OpenGL. From what I know, an implementation of any GLU version should do it.

That's not really a problem anymore, but openGL will still run fastest if you pass them in that way.

It will only affect loading time, not actual rendering, compared to passing an image that has been pre-scaled to the nearest power of two.

What's the preferred PNG file format and variables required, if any?

The smallest that is lossless/acceptable. For instance, my avatar has only 5 different grays (black, white, two gray levels at the sides and one in the corner) that don't match the grays of a low bit depth, and 8-bit precision is fine, so I made it 2^ceil(log2(log2(5)))=4-bit indexed. 8-bit gray might also work well depending on compression, but it's obvious that per-pixel RGB (PNG palette entries are always RGB, but it might still save space) or an alpha channel is a waste.

It might be a difference in perception. For textures that are attached with a player, they get modified internally based on the player's color. I don't recall exactly how the algorithm works, but it's something to do with the more whiteness in the texture, the more of the player's color gets put in. So if you put straight red on the texture, it won't come out red at all when blended with the player's color, unless the player's color is white, I think.

It just draws it on top of the cycle color, utilizing the alpha channel for transparency. How did you arrive at whiteness?

The grid floor is just stacked first one way, then another, tiled horizontally each time, which is what makes the grid shape. Same here, the whiter the color on the texture, the more of the floor color gets put in.

The dual texture floor is pretty unusual, but doesn't depend on 'whiteness'. Off the top of my head, it draws floor_a first with standard alpha blending (glColor alpha is 1-FLOOR_MIRROR_INT), then draws floor_b on top of it without multiplying the framebuffer with 1-alpha.

rim_wall doesn't get reinterpreted like this at all, …

Only the cycle textures are preprocessed. It might seem like the cycle walls are also preprocessed, but they're just multiplied with the color when they're drawn.

[Lucifer]

I arrived at my whiteness conclusion through experimentation. Naturally anybody who's actually looked at the code knows more about it than I do.

I saw the code that handles the cycle texture, but I didn't look at the rest, just extrapolated from there.

[aeralure]

Thanks everyone. I'm a graphic designer, not a programmer per se though I do some scripting for the web and Flash etc. I dig into coding only as far as I need to typically to figure out how I need to design for it. Have to admit I would like to dig a bit deeper in this case and play behind the scenes modifying what I can since its fun, but a programmer I most certainly am not. I really appreciate the info and help in this topic, as well as all around the forums here. You guys are great.

In making a quick set of screenshots to reply to Lucifer this am, I noted a file size discrepency between my saved PNG test file and the original (I was simply using the rim_wall.png as shipped as a test file). Turns out I was saving in PNG-8 format and it needs to be PNG-24. The dir_wall.png can be saved as a PNG-8 though, and that was the first file I tinkered with, hence my maybe getting stuck on that save setting.

So anyway, even though its now pointless, lol, here are the screenshots of what I chose as a default state for testing (I was using a mid range grey since I was testing colors earlier until I was pointed in the right direction there), what happened when I used the original PI texture and my saved PNG-8 textures for points of comparison.

[Tank Program]

You can remove the little cracks by disabling polygon antialising in the detail settings menu.

[aeralure]

Very nice. Thank you. Intuition told me that having it on was the better visual option, but it looks far nicer off. Much appreciated.