ID:1950976
 
Which is better?:


32x32 Pondera with zoom:

(Can mimic 64x64 by zooming in, but isn't as spaced apart. Easier to edit icons due to no fading.)



64x64 Pondera with zoom:

(Higher Fidelity and Antialias; AA makes it harder to modify the icons due to opacity fading. Black Boxes are the Opacity/darkness for the light system and I would have to convert all of the opacity states to 64x64, not something I look forward to if I proceed)
For those who cannot see the gifvs:
32x32:
64x64:
And non-hotlink: http://imgur.com/a/gLa7R

Now, as for my opinion, 32x32 looks the best in this case, because it is more crisp. If you're not gonna build it for 64x64 from scratch (or use pixel art upscaling, not regular art upscaling), 64x64 isn't going to look good, to me, at least.

EDIT: Added non-hotlink, since hotlinking seems to be dead for me...
In response to Kamuna
Yeah, I agree. I converted the project back to 32 earlier.

I was just trying an image resize trick for the existing graphics. In every instance I tried, AA was added. There is possibly some way to disable that and I could also do it by hand; however, there are so many graphics for pondera (think building game + ORPG world graphics = lots of stuff) that rebuilding them all into 64x64 would be a huge undertaking.

Some of the quality issues in the image are from the gif compression. When I initially started doing this a day or two ago I was actually impressed with the AA'ed bigger graphics but eventually found that the work would be too much for too little of a gain. Resizing all of those lighting opacity frames just to correct those black squares would be a pain and that is only one icon out of many that all feature tons of states.
I think I like the 32x32 zoom much more. For 64x64 and for the current graphics you have, there is really no need to zoom in that much. Game looks interesting.
I actually prefer 64x64
In response to Ganite
Ganite wrote:
I actually prefer 64x64

I did too, at first. But after looking at the lighting opacity states (I think there are 64 of them) and being unable to auto-cut them out due to them being opacity states I kind of lost heart in the resize.
There are probably a thousand icon states to resize to 64x64. I was initially going to just do what was required for the testing area you see in the first screenshot but I didn't account for the lighting icons too. Basically, it would be a lot of work and it would only make Pondera take that much longer to release. If there was a solid way to scale the graphics up to 64x64 without all of the graphic work (where are the good programmers?!?), then I would be all for it and maybe even offer a 32 and 64 mode.

As it is now, unless there are people who wish to help in this endeavor, I will be putting it on the back burner...possibly never to proceed.

I need to get Pondera released, so remaking all of the graphics will have to come at some later date.
Can't BYOND scale icons to larger sizes without anti-aliasing? You could make a program in BYOND to do it for you. Either that, or run a program that does pixel art scaling through multiple png files. You just rename your .dmi files to .png files using the command line, run the program on the .png files, and then rename them back to .dmi, and hopefully the pixel art scaling program is smart enough not to mess with the .dmi formatting things. .dmi files are just glorified .png files, basically.
If you want anti-aliasing for some reason, scale it up, then scale it down, then scale it up again (or again, use pixel art scaling that has anti-aliasing).
In response to Kamuna
All of the resizing programs I tried, including one on byond (IconImport by Falacy) were unable to get precise 64x64 icons and they all added AA.

I know dmi's are png's, I've been editing them in photoshop.

I just searched up how to disable AA on transform for PS7:
"Edit > Preferences > General
Change image interpolation to Nearest Neighbor."
Thanks to kodde from another forum.

Even without the AA (which actually didn't look too bad to me but it does make it more complicated) it is still a lot of work and a difficult task to be accomplished. Maybe if I had a huge team of people to do it, it would be more feasible/practical.

Here are the opacity states I would have to cut and resize to 64(these are from Forum_Account's Dynamic Lighting Library, thanks to him):
Well, before I get into how to make the bounds 64x64, why don't you generate 64x64 icons instead of making 32x32 icons into 64x64 icons? Matter of fact, the Light Speed library on BYOND already has a 64x64 version of that. I suggest checking it out.
In response to AERProductions
Forum_account's lighting library (and consequently FIREking's) has an icon generator that will generate 64x64 shade icons.

Aside from that, you can scale icons up (or down) with DM:
var icon/i = icon('blah.dmi')
i.Scale(64, 64)
fcopy(i, "blah 64x64.dmi")
In response to Kaiochao
Yeah, I was trying to say that you could scale 'em in DM in my previous post before my last post. But I've never used Forum_account's library, so I wasn't sure if there was a generator or not. I knew that FIREking must have used at least the icon_states from it, though, once I saw the image.
+1 for the example. I'm running quite low on time, so I can't provide any of mine right now.
In response to Kaiochao
Thank you Kaio and Kamu, I will try these things out.
Guess I didn't notice the icon generator, but sure enough, there it is! :P Maybe hope isn't gone for this pursuit after all.

Aside from that, you can scale icons up (or down) with DM:
> var icon/i = icon('blah.dmi')
> i.Scale(64, 64)
> fcopy(i, "blah 64x64.dmi")
>

Is it better to use this as an individual scaling program that can save the icons or is it suitable for use in a live game? Some of the icons don't come out as 64x64 since there is opacity in the images; another reason I have to do a lot of the work by hand without a cutting program.
Always opt for before-runtime things if you can, especially when it comes to icon procs. Icon procs usually take up a lot of server CPU, so I wouldn't recommend them for a live game at all.

If you do opt for doing it during a live game, you'll need to cache them so it's only a one-time, world startup thing.

Also, what do you mean "opacity"? Do you mean transparency? Alpha? Because BYOND handles that, too.
In response to Kamuna
Yeah, you are absolutely correct.

Yes, Opacity is Alpha.

I'm wondering if I can manipulate Forum_Account's icon generating code for use with upsizing my icons:

proc
generate_icon()

var/icon/master = new()

var/total = states * states * states
var/count = 0

for(var/a = 1 to states)
for(var/b = 1 to states)
for(var/c = 1 to states)
for(var/d = 1 to states)
var/icon/I = generate_state(a, b, c, d)

master.Insert(I, "[a-1][b-1][c-1][d-1]")

count += 1
var/pct = round(100 * count / total)
world << "[pct]%"

sleep(world.tick_lag)

world << ftp(master, "lighting.dmi")

generate_state(a, b, c, d)

var/icon/I = icon('dynamic-lighting-library.dmi', "blank")
I.Scale(icon_width, icon_height)

var/a_val = value(a)
var/b_val = value(b)
var/c_val = value(c)
var/d_val = value(d)

for(var/x = 1 to icon_width)
for(var/y = 1 to icon_height)

// c -- b
// | |
// b -- a

var/i = (x - 1) / (icon_width - 1)
var/j = (y - 1) / (icon_height - 1)

var/a_wgt = ( i) * (1 - j)
var/b_wgt = (1 - i) * (1 - j)
var/c_wgt = (1 - i) * ( j)
var/d_wgt = ( i) * ( j)

var/alpha = round(a_val * a_wgt + b_val * b_wgt + c_val * c_wgt + d_val * d_wgt)

I.DrawBox(rgb(red, green, blue, alpha), x, y)

return I

value(state)
return darkest - (darkest - lightest) * ((state - 1) / (states - 1))
In response to AERProductions
All you have to do is change the variables at the top, where it says:
var
icon_width = 32
icon_height = 32

Change those 32s to 64s, include the icon-generator.dm file, Run from the library, and use the verb "Generate Icon".
In response to Kaiochao
That wasn't what I meant by my above post, I had already generated the icons after you mentioned the generator the first time (I am not that dense, sheesh kaio...).

What my above post was describing was changing this icon generator into an icon resizer for my icons.
Why? It's easier to make it from scratch. Place this in a verb, world/New(), whatever you want.
for(var/iconFile in flist("IconsToConvert/")) //Place all icons you wish to convert in this folder that is in the current directory.
var/icon/icon = icon("IconsToConvert/[iconFile]") //Load up the icon file into an icon datum.
icon.Scale(64, 64) //Scale the icon to 64x64.
fcopy(icon, "ConvertedIcons/[iconFile]") //All icons should come out as 64x64 in this folder. Filenames stay the same in this case.
In response to Kamuna
Thank you kamu. The reason why is because I am not primarily a programmer so I have to modify what is available to suit my needs. :(
I really appreciate your help and will put your name in my projects credits now. :)

Most of my graphics are as icon states though, not individual icons. Does this snippet scale all of the states in an icon or only the icon and its first state?
Should be all states. If it, for some odd reason, doesn't scale all of the states, I can make a snippet for all states too. But I'm pretty sure it should do all the states, BYOND doesn't discriminate those unless you tell it to.

Also, you need not put me in your credits. If you really really want to though, just put me in as a very minor role, like a mini-snippet provider and idea generator, or something like that...
In response to Kamuna
That did the trick. All of them converted to true 64x64 in an instant. Thanks Kamu, you're amazing! :)

Here is another shot of 64x64 Pondera (No AA this time):
http://imgur.com/wOn46rf
Page: 1 2