I am using png files as a background image and I have them set to start at south,west and end on north,east. This makes it appear but it shrinks the whole image into one tile then just repeats that tile for the whole screen. I want the image to appear in its proper size. The image Im using is set to the size of the screen so the image itself shouldnt have any repeats.
var/obj/O = new/obj
O.icon = 'image.png'
src.client.screen += O
O.screen_loc = "SOUTH,WEST to NORTH,EAST"
image.png is sized for a 14x13 screen.
ID:158228
 Oct 4 2009, 7:17 pm
|
|
|
Oct 5 2009, 4:16 am
|
|
UmbrousSoul
 |
Are you importing it? What icon size are you trying to set it to. Other than that I can only think of those titlescreen splitter programs that can kind of make a map of a large image for you, but it will be one tile each to make up the whole image.
|
Dpheonix7 wrote:
I want the image to appear in its proper size. The image Im using is set to the size of the screen so the image itself shouldnt have any repeats. If you want something and tell the compiler to do otherwise, the result is likely the game to look like what you told the compiler and not what you had on your mind. O.screen_loc = "SOUTH,WEST to NORTH,EAST"
screen_loc: "A range of coordinates (the second format above) causes a square region to be filled with the object at each position." | |
That wont work as it will shrink it to 32x32 and tile it. I ended up putting it into a dmi file split and made a proc to place it back together using the numbers that DM names the states as (I wish it would do the x,y cords like the older versions did). Only I can not get it as a screen obj to work. I can make it an image. I only want the player to see it and not others. But not having it set to the screen, I cant keep it in place of the client view, as this brings me to an other issue.
| |
Dpheonix7 wrote:
That wont work as it will shrink it to 32x32 and tile it. Did you even read his post? At any case, you can't ever give any atom, including screen objects, an icon with a size different from the tile size (32x32). That's how it is. What you can do however is use multiple objects to represent a bigger graphic, or use pixel-offset overlays on one (or multiple) object to expand its visual graphic, something that would work well for using screen objects. | |
Its created at runtime. I dont mind if it gets split up, right now I just want it to attack properaly to the client screen. I have 2 procs now to put tiles together into bigger images.
| |
No, you can't, despite what you may think. When you do that you're really laying down many turfs, rather than one: it's simply a feature of the map editor that conveniently splits the big graphic into multiple atom instances and automatically lays down all the different parts at once. Each 32x32 chunk of the image is still a separate turf, all on its own.
An atom's native icon can't be bigger than the tile size, neither can multiple turfs exist on the same tile (seeing as tile == turf anyway) for that matter, which another map editor feature gives the illusion of. | |
I read the post, and I have tried what he said and I got the whole image scaled down to 32x32 and tiled over the whole screen. Offsets wont work since Im doing the whole screen so each tile has to be set by location instead.
| |
The point of this is not making the image in Dream Maker, but making it appear during runtime with a size of approx 448x404
| |
Well I do have the image appearing its true size on the screen, now Im moving this issue over to code problems because its not attaching to the client screen.
| |
Dpheonix7 wrote:
I read the post, and I have tried what he said and I got the whole image scaled down to 32x32 and tiled over the whole screen. Uh, and again you completely prove you've failed to actually properly read her post... she never actually suggested you to try something. The code in that post was your own... What the post explained is exactly that doing what you tried won't work to do what you want as that is used for different behavior, which is documented, as was quoted. As for your last sentence, I'm not so sure on what exactly you're planning to do or why you think using pixel-offset overlays won't work, but they should, so you should go ahead and give it a try. | |
They wont work because the image is bigger then the offset limit. The entire size is 14x13 tiles, the size of the screen setting Im using.
| |
Dpheonix7 wrote:
They wont work because the image is bigger then the offset limit. The entire size is 14x13 tiles, the size of the screen setting Im using. I can't check at the moment to make sure, but it's not pixel_x or pixel_y you want to be playing with, but rather icon_state. When you work with a png file it gets split up into 32x32 tiles, and one 32x32 scaled icon. the scaled down icon has the icon_state of "" while the others all have icon_state's based on their coordinate (I believe starting at 0,0. So you have a 64x64 png of the following: CD AB "0,0" would be A, "0,1" would be C, "1,0" would be B, "1,1" would be D. | |
Dpheonix7 wrote:
They wont work because the image is bigger then the offset limit. That's no problem, as I said you can also use multiple screen objects to build the larger image. And you can mix the 2 methods, meaning you could have e.g. 4 screen objects, each with pixel-offset overlays on it, that make up the whole huge image. | |
http://www.youtube.com/watch?v=zbXBPEfuZIs
This thread keeps going on and I long ago got something that works. A few comments helped me find the direction I needed along with a past thread. | |