ID:179188
 Feb 6 2002, 7:32 am
|
|
It appears that you can't really do anything with bitmaps unless you import them into a .dmi (which cuts down the resolution quite a bit). I'm guessing icon states would be out of the question, but I was wondering if there is any other way to make a bitmap tile rotate in DM (without creating 4 separate bitmap files).
| |
Tom wrote:
DS currently displays everything in 256 color, even if the image is originally 24-bit. So a bmp displayed on its own will be no different from a bmp imported into a dmi. We'll get rid of this restriction eventually, because it's mainly a historical one that will require some coding (and stability-threats) to workaround. For 32x32 tiles with only a single icon state, it shouldn't be that much of an issue, since there are only 1024 pixels involved and the system does a pretty good job dithering them. If stability is going to be a factor, doesn't it make sense to tackle this now? I know the release has been put off by a lot of issues, but remember, some of the toughest remaining bugs are display bugs anyway--there's a chance that in switching to better display code, you'll root them out. Besides, why introduce potential stability problems into a stable release when you can introduce them into an unstable beta? 24-bit DMIs, long at the top of many wish lists, can probably wait a tad, but 24-bit output is probably a good idea to get done now. Lummox JR | |
Lummox JR wrote:
If stability is going to be a factor, doesn't it make sense to tackle this now? I know the release has been put off by a lot of issues, but remember, some of the toughest remaining bugs are display bugs anyway--there's a chance that in switching to better display code, you'll root them out. Besides, why introduce potential stability problems into a stable release when you can introduce them into an unstable beta? It's not the display code. Obviously everything displays in 24-bit because each icon can have 256 colors. It's just the way we do things internally, transmitting data as DMIs, which are 8-bit. We could use an alternate 24-bit format at the sake of a bit more overhead. Just don't request anything and then you'll be surprised when good things happen. I think the current release is just peachy. | |
Tom wrote:
It's not the display code. Obviously everything displays in 24-bit because each icon can have 256 colors. It's just the way we do things internally, transmitting data as DMIs, which are 8-bit. We could use an alternate 24-bit format at the sake of a bit more overhead. Just don't request anything and then you'll be surprised when good things happen. I think the current release is just peachy. Ah, I see what you mean. I thought you meant that the drawing code used 8 bits, which would seem rather silly. Switching to a compressed 24-bit format would seem to eventually be the way to go, but yeah, if the only noticeable difference right now is to the way PNG and BMP files display, not a big deal. Lummox JR | |
ahh, you're right. I had mistakenly compared the bitmap to the enlarged image in the .dmi editor, and it looked like I had lost resolution, but when I compared them apples to apples they looked pretty much the same.
I'll just import the bitmaps into .dmi files. | |
Tom wrote:
To answer your original question, you might want to look at the turn() proc to rotate icons dynamically. I tried using turn(), but it's not working as I expected. I only had 1 icon, and I checked the box "Movement State". After that, I guessed what I needed to do is have 4 icon states (each rotated 90 deg. from each other), label the states "NORTH", "EAST", "SOUTH", and "WEST", and check the Movement State box for each. I set the tile's Icon_state to "NORTH" and dir to NORTH Then, in my tile.rotate() proc I have: dir = turn(dir, 90) However, this didn't work either. Could someone please explain how to get turn() to work? Thanks. | |
dramstud wrote:
I tried using turn(), but it's not working as I expected. I only had 1 icon, and I checked the box "Movement State". I think what you're trying to do is use directional icons, which you'd do by creating your icon as a movie. (If you want to rotate the icon itself, icon=turn(icon,angle) works.) Lummox JR | |
DS currently reduces each icon to 256 color, even if the associated image is originally 24-bit. So a bmp displayed on its own will be no different from a bmp imported into a dmi. We'll get rid of this restriction eventually, because it's mainly a historical one that will require some coding (and stability-threats) to workaround. For 32x32 tiles with only a single icon state, it shouldn't be that much of an issue, since there are only 1024 pixels involved and the system does a pretty good job dithering them. Note that while each icon is subject to this restriction, the display as a whole is not, so you can still have more than 256 colors on the screen at one time. When you realize that, it's not that limiting.
Currently the main reason to use a bmp (or better, a png) is to automatically create larger objects by letting the map editor split the tiles for you or doing it in code with the new icon_states() proc (see the beta release notes for more info on this). If you have a 32x32 bmp, you may as well just import it as a dmi.
To answer your original question, you might want to look at the turn() proc to rotate icons dynamically.
[edited for clarity]