Right now as it stand pixel offset is done a 4x4 grid (128 pixels). While this works well for most games it does limit the option to do some things. Pixel offset does not need to be too large to were it will most likely be off the screen. 10x10 would probably be the max most coders would need to work with any system needed by pixel offset.
One area a high pixel offset would be helpful is with large icons. For example using the newer feature of icons larger then 32x32 are png files. While those created at compile time have no issues, those created game time via a process or whatever will have their edges cropped if they are larger then 128x128. From what I seen a lot of RPGs will have monsters that are above the 128x128 mark, but probably not larger 192x192.
Another area pixel offset was an issue for me (though I did a not as great work around) was using a system of a marker based on the mobs x,y vars and using pixel offset for a more exact screen setting.
ID:133015
 Jun 14 2009, 6:58 am
|
|
Why does everyone tell me to use the bigatom library. I dont want to use someone elses work. And it wont work for everything. Not using moving large icons. Just want byond to handle icon offsets better. I been using a simple icon placement system for years. It takes every tile that goes past 4 spaces and puts them in the 3rd space with the offset limit.
As for using bigatom is will not help when you want to move an icon around the screen without changing it's location (via using offset). It also from my understanding will not work with icon states larger then 128x128. | |
Because of the inherent limitations of pixel-offset overlays (one of them is that the object itself must be in near your direct view for you to actually see its overlays) they are not useful anyway to represent very large objects, whether you can pixel-offset by larger amounts or not. Whatever you're planning to do with larger pixel offsets, it can probably be done better with a different method anyway. Can you give good, specific other reasons why larger pixel offsets are needed?
| |
I hardely see how going from 4x4 to 5x5 or even 6x6 would put objects out of view.
One things I wanted to use a bigger offset for was doing something like an ingame map with a locator. the larger pixel offset field would allow to use pixel offset to set the location of the locator so it can be more accurate instead of placing it on the x,y cords that more likely wouldn't be the right location. | |
This would be a good deal of work for the staff resulting in minimal benefit and a higher memory usage. Right now, a signed char type variable (or something similar) is probably used to represent the pixel offsets; this is one byte of data. However, 10x10 would require a 2+ byte variable type, most likely an [edit: short] int, so the pixel offset system would then use twice as much memory. Not to mention the fact that the staff might have to mess with BYOND's networking to get it working properly, such as how increasing the object etc. limits to 16 million required this.
Besides, do you really need a one tile atom to be 10x10 tiles? | |
Lol, you don't want to use someone else's work. If you ever want to program in a more advanced language, like C++, you better learn how to use someone else's work!
| |
Im not working with moving mobs. Having more mobs on the screen too would mess stuff up.
In general it seems that since we can now use bigger icon states we should have a little more to work with for icon sizes. | |
Dpheonix7 wrote:
the larger pixel offset field would allow to use pixel offset to set the location of the locator so it can be more accurate instead of placing it on the x,y cords that more likely wouldn't be the right location. Like I thought, you have a very crappy, personalized reason. All you need to do there is modify the location in tiles to make it appear on the wanted, and then use a pixel offset to make it appear in the exact location. i.e. if something is supposed to be somewhere at position XxY in pixels, first you set its position using tiles, so at X/32 and Y/32 (rounded), and the remainder of each applied as offsets. Putting stuff on the screen isn't really any different from putting it on the map, etc. | |
You have 128 pixel offset in all directions. Meaning you can make an icon appear to be 288x288 pixels or 9x9 tiles. Seems to be much more than you're requesting, even the max you requested was only 10x10.
| |
For pixel-based movement-type pixel offsets, I don't need any more than 31 or 32 in any direction. Obviously, if you hit 32, you could just move the object over a tile and reset the pixel offset to 0.