GMS 2 Poor Image Quality

D

djrain

Guest
Hey everyone,

Before GameMaker I was using another game engine called Stencyl. After running the same game in both engines, I have noticed that the sprite image quality isn't looking as good in GameMaker. Take a look at the below comparison (all the exact same sprite, same scale, taken directly from iPhone screenshots)



What's going on here? How can I make my sprites appear more like in the first images?
 
Last edited by a moderator:

Simon Gust

Member
Happens in gms 1.4 too, I just tested this.

But honestly, who rotates pixel art? I always though rotation / skewing pixel art was just for lazy artists, no offence your point still stands.
 
D

djrain

Guest
Happens in gms 1.4 too, I just tested this.

But honestly, who rotates pixel art? I always though rotation / skewing pixel art was just for lazy artists, no offence your point still stands.
Fair enough, but like you said that's beside the point. Non pixel art would look equally bad.
 

dannyjenn

Member
How so? We're talking about plain rendering and antialiasing, not scaling.
The pictures you posted are scaled. And rotated. Vector graphics would suffer no loss.

Anyway, GameMaker doesn't claim to do any sort of antialiasing. I think you're confusing "antialiasing" with "interpolation". Those two terms do not mean the same thing. ("Antialiasing" = smoothing the edges / "Interpolation" = filling in the missing pixels.) I am guessing that Stencyl uses nearest neighbor interpolation to upscale it, then rotates the scaled version (probably also using nearest neighbor interpolation), and then uses some sort of antialiasing filter on it.
 
Last edited:
D

djrain

Guest
The pictures you posted are scaled. And rotated. Vector graphics would suffer no loss.

Additionally, GameMaker doesn't claim to do any sort of antialiasing. I think you're confusing "antialiasing" with "interpolation". Those two terms do not mean the same thing. ("Antialiasing" = smoothing the edges / "Interpolation" = filling in the missing pixels.)
They are rotated, yes. But not scaled (in game, I mean. Obviously the images are scaled up here).

I suppose you're right about the interpolation. But still, that doesn't explain why the image rotated in Stencyl without AA looks great but Gamemaker makes a mess out of it. This needs to be fixed.

Also, GameMaker does have antialiasing, though the capabilities depend on the exact device running the game, correct? I tried using display_reset to set the AA but it didn't seem to do anything on my iPhone.
 

muki

Member
No interpolation/aa, scale up then rotate. It'll be sharp. Just tried it on my end, it's sharp, down to the inherent resolution of my view.



Personally I think rotating pixel art looks bad in a different way (diagonal pixels don't exist), but doing it in that order would fix your issue.

Rotating then scaling makes a mess of raw pixel data, as it *should* for any kind of raster manipulation. If an engine somehow "fixes" that mess, it's probably doing some weird non-raster workarounds/bandaids behind the scenes. I'd prefer an engine do exactly what I tell it to do with predictable results.
 
Last edited:

RangerX

Member
For this test to be relevant anyways we would need to know how Stencil handles your sprite. If he handles it as vector graphics without telliing, you would totally get that better result in the opening post.
If it pure 2D sprite, you get what GMS gives you because the graphical quality is 100% related to the resolution at which your sprite is rotated.
I sadly won't install Stencyl to make a proper test but I doubt there's anything to write about here. GMS is not rotating your sprite there in "unnacceptable quality", it's just unaltered and real 2D that's all. Rotate the same sprite at the same resolution in Gale, Photoshop, Paint, anything else and you will get the exact same result.
 
D

djrain

Guest
No interpolation/aa, scale up then rotate. It'll be sharp. Just tried it on my end, it's sharp, down to the inherent resolution of my view.



Personally I think rotating pixel art looks bad in a different way (diagonal pixels don't exist), but doing it in that order would fix your issue.

Rotating then scaling makes a mess of raw pixel data, as it *should* for any kind of raster manipulation. If an engine somehow "fixes" that mess, it's probably doing some weird non-raster workarounds/bandaids behind the scenes. I'd prefer an engine do exactly what I tell it to do with predictable results.
What do you mean, "scale up then rotate"? There is no scaling happening in my example images. It's just an imported sprite, original size, rotated 45 degrees.
 

muki

Member
There's definitely scaling up happening there, to some degree.

Look at it this way. By eyeballing it, you can estimate around 8-10 screen pixels for every 1 sprite pixel. Meaning it was scaled up 8 to 10 times. Maybe less since the screenshot itself looks to be lower resolution than the native of my monitor.

Not knowing Stencyl, I can't tell you where in its rendering pipeline its doing it. But it is doing it.
 
D

djrain

Guest
There's definitely scaling up happening there, to some degree.

Look at it this way. By eyeballing it, you can estimate around 8-10 screen pixels for every 1 sprite pixel. Meaning it was scaled up 8 to 10 times. Not knowing Stencyl, I can't tell you where in its rendering pipeline its doing it. But it is doing it.
The image was scaled up afterwards, yes. But the sprite was not scaled when the game was running, which is what matters.
 

muki

Member
The image was scaled up afterwards, yes. But the sprite was not scaled when the game was running, which is what matters.
Which image, post-screenshot?

In any case I'm refering to your 2nd and 3rd basketballs. There are diagonal sprite pixels there. It's absolutely 100% impossible to have diagonal pixels unless the sprite was scaled up first (to a surface, or whatever stencyl's equivalent of a surface is), then rotated. Whether your code is doing it or Stencyl is doing it without you knowing, or the iphone hardware is doing it, I can't say, but it is happening.

And to acheive the same image quality in GM you'd do the same thing, scale up then rotate, in that order.
 

RangerX

Member
The image was scaled up afterwards, yes. But the sprite was not scaled when the game was running, which is what matters.
Depends how Stencyl handles it. It appears like its scaled. And no program in this world can recreate the sprite perfectly rotated like that without having more available pixels. Else you get the result you see in GMS (or in any other software ever that is -- since its purely logical here and not related to quality)
 
D

djrain

Guest
Which image, post-screenshot?

In any case I'm refering to your 2nd and 3rd basketballs. There are diagonal sprite pixels there. It's absolutely 100% impossible to have diagonal pixels unless the sprite was scaled up first (to a surface, or whatever stencyl's equivalent of a surface is), then rotated. Whether your code is doing it or Stencyl is doing it without you knowing, or the iphone hardware is doing it, I can't say, but it is happening.

And to acheive the same image quality in GM you'd do the same thing, scale up then rotate, in that order.
All of the images are from screenshots which I zoomed in on and cropped. I guess it is true that both engines are scaling the image, since my game resolution is 480 x 320, but my point was that they're both being scaled the same amount -- to fit the aspect ratio of the screen. So why does Stencyl's version look better?
 

muki

Member
All of the images are from screenshots which I zoomed in on and cropped. I guess it is true that both engines are scaling the image, since my game resolution is 480 x 320, but my point was that they're both being scaled the same amount -- to fit the aspect ratio of the screen. So why does Stencyl's version look better?
Because it's likely scaling up first, then rotating. Somewhere internally. Or it's telling the graphics hardware to do it.

You can achieve the same quality in GM. You just need to do that stuff manually. Scale up your entire project. Keep the art/sprites the same resolution, but make your room 4x bigger, and have the game "math" use bigger numbers to compensate for the bigger room size.

It's a bit of a hassle. But keep in mind that all of this is for an effect that a lot of people prefer not to do, rotating sprites. Usually the rotation is done with animation frames as it tends to look way better. If scaling your room/project size just for the single goal of making the ball's rotation look better is too much work, you might consider animating the rotation instead.

A trickier way is you can keep your room/project size the same, but do some custom rendering for the ball. Something like

1. Draw the unrotated ball not to the view/screen but to a hidden surface
2. Scale the surface 4-8 times
3. Rotate the ball the amount you want
4. Scale it back down again 4-8 times, make sure filtering is on
5. Draw the result to view/screen.
6. Repeat every frame.

It's a hassle, sure, compared to something Stencyl does automatically and quickly. GM isn't perfect. But rotating pixel art (the diagonal pixels) is a pretty niche application anyway. It's just a different way of drawing things to screen. Not as intuitive/quick, but offers more control is a way to look at it.
 

Yal

šŸ§ *penguin noises*
GMC Elder
You could always set a shader before rendering the ball, then let that shader do some custom interpolation, then unset it again (or keep it perma-active, if you'd prefer). GM can run any OpenGL shader so you can basically extend drawing any way you want.
 

CMAllen

Member
The two version of the image aren't operating at the same screen resolution. Nor are they performing the transformations in the same order. Now how much of this disparity is GM's failings and how much is the user's misunderstanding (or possibly deliberate misinformation?), I can't say. But it definitely isn't a fair comparison by any stretch.

If you rotate first THEN scale, you're just scaling the imprecision created by the rotation. If you scale first then rotate, you increase the pixel density of the image, which can then be used to maintain the image's form and structure when rotated. Yes, like with math, the order of operations can change the results dramatically.
 
D

djrain

Guest
It's a hassle, sure, compared to something Stencyl does automatically and quickly. GM isn't perfect.
Exactly why GMS should have an option to do this automatically. :)

1. Draw the unrotated ball not to the view/screen but to a hidden surface
2. Scale the surface 4-8 times
3. Rotate the ball the amount you want
4. Scale it back down again 4-8 times, make sure filtering is on
5. Draw the result to view/screen.
6. Repeat every frame.
I might try this, but I don't understand step 3. How do you rotate something you already drew? Also what do you mean by filtering in step 4?
 
Last edited by a moderator:

RangerX

Member
Exactly why GMS should have an option to do this automatically. :)
Like the other poster said, its just a question of order of operation. What stencyl MIGHT be doing for you there, GMS give you the choice to do it or not depending your need.
I'd argue that options/choice is better! ;)
 

dannyjenn

Member
I don't think it's entirely an issue with the order of operations. Notice how there are diagonal lines? That would not be possible if the rotation had been done before the scaling. From the picture, it looks like: 1) GameMaker first scales the sprite (by 200%), 2) GameMaker then rotates the scaled sprite (by 45 degrees), 3) GameMaker, or perhaps the iPhone itself, scales the rotated sprite a second time (by 600%).
 

RangerX

Member
That's what we been saying and yes its therefore and question of operation order.
Keep it simple. If you see more pixels in the image.... its because there is! No other possibilities. Its that plain an simple.
When a small sprite is rotated, the fact its small means there's not many pixels. If you rotate it "as is" it will look like ****. But if you scale it first and then your rotate it, the fact it was scaled up simply means there's more pixels available to accurately represent your sprite in its rotated state. It appears smoother.

What game maker does there (and the image in the opening post if proof) is that it draws "as is" first and THEN it scales up. While Stencyl simply might do it the other way around, always scaling first.
 
D

djrain

Guest
What game maker does there (and the image in the opening post if proof) is that it draws "as is" first and THEN it scales up. While Stencyl simply might do it the other way around, always scaling first.
Then why can't GameMaker just do it the other way around and make it look good?
 

RangerX

Member
Then why can't GameMaker just do it the other way around and make it look good?
I said it earlier. GameMaker give the choice. You do it or you don't. For certain situation you will want it and certain other you will not. I've seen people complaining about both on this forum.
I think the GameMaker way is more natural and better because it let's you decide. And if you do nothing, it leaves your graphics "as is". I don't like a software that does something to my stuff without me deciding/asking for it, having the choice is better.
 
D

djrain

Guest
I said it earlier. GameMaker give the choice. You do it or you don't. For certain situation you will want it and certain other you will not. I've seen people complaining about both on this forum.
I think the GameMaker way is more natural and better because it let's you decide. And if you do nothing, it leaves your graphics "as is". I don't like a software that does something to my stuff without me deciding/asking for it, having the choice is better.
But what's the benefit to doing it that way? When would you want that?
 

RangerX

Member
Those are artistic choices. There's not much to say about it. Certain games are doing it, certain games aren't.
Debate is always possible when its about design or art. And that's why under any circumstances CHOICE is better. :)
 

Samuel Venable

Time Killer
So why does Stencyl's version look better?
Not to hate on GameMaker, but that's probably because how Stencyl renders your art is overall better. I've used Stencyl before, and quite frankly why I stopped using it was the subscription model it has, otherwise I'd be using it instead of GameMaker. Its Box2D implementation is a lot more logical and straightforward, and its DnD has all the same power as using code, as there is a DnD action for pretty much everything. Before I'll get too far off on this rant, I will say that I still prefer GMS (because GMS's subscription model only applies to the console exports). All this is very little relevant to my plans however as I'm going to be switching to Unity soon, (well, partially)...
 
Last edited:
D

djrain

Guest
Those are artistic choices. There's not much to say about it. Certain games are doing it, certain games aren't.
Debate is always possible when its about design or art. And that's why under any circumstances CHOICE is better. :)
Well then Gamemaker should give us the CHOICE to do this automatically.
 

muki

Member
Well then Gamemaker should give us the CHOICE to do this automatically.
Maybe in the future we'll get more advanced AA as an easy plug-&-play featureset, like supersampling, I wouldn't mind that. But given that there are several manual workarounds (some incredibly fast and easy), I imagine it's low on their list of priorities of stuff to add.

It's fairly straightforward to just build your room larger and scale sprites up so you can rotate them. Or animate the sprite itself (which will look better than any rotated sprite any engine can deliver). Whichever works best. If rotating sprites is a key part of your game then I would build the room/project around the larger size this kind of sprite manipulation requires. If it's just the ball that needs rotating, then animated rotation is probably better.
 

RangerX

Member
Well then Gamemaker should give us the CHOICE to do this automatically.
Sure, but just like Stencyl, you can't have it both ways. There's always a default method and then alternate methods you can use. It would change nothing if GameMaker would default on Stencyl's way because while you would like it then there would be another person wishing the default was on the other method. Also, do you know how much lines of codes it takes to take control of everything GameMaker does automatically with the application surface?
It takes one line: application_surface_draw_enable();
At least GameMaker isn't too hard on us.
 

CMAllen

Member
Those are artistic choices. There's not much to say about it. Certain games are doing it, certain games aren't.
Debate is always possible when its about design or art. And that's why under any circumstances CHOICE is better. :)
The problem with choice, in this instance, is that it removes certain core functionality from drawing routines, forcing the user to reinvent the wheel (origin offset relative to image scale and rotation being the biggest ones, but hardly the only ones). And since these user-written functions are going to be interpreted, they're also going to be slower. Now, if there actually was a OOp flag we could set in draw calls that tells GM which order to apply transformations, that'd be great. It really would be a user's choice. But as for now, it's kind of an empty choice.
 

RangerX

Member
The problem with choice, in this instance, is that it removes certain core functionality from drawing routines, forcing the user to reinvent the wheel (origin offset relative to image scale and rotation being the biggest ones, but hardly the only ones). And since these user-written functions are going to be interpreted, they're also going to be slower. Now, if there actually was a OOp flag we could set in draw calls that tells GM which order to apply transformations, that'd be great. It really would be a user's choice. But as for now, it's kind of an empty choice.
Well, this is an endless debate there. I personally prefer the GMS way or not altering my graphical assets in anyway unless I tell it to do so.
What choice do I not have with GameMaker?
- I can scale my sprites at run time and draw them scaled up on the application surface or draw them native size.
- I can scale the application surface before hand or draw everything "native size" on it and scale it up right before drawing it to screen.

So basically I can make my sprite rotations look any way I want. Can you have it appear "raw" in Stencyl?
 
D

djrain

Guest
Well, this is an endless debate there. I personally prefer the GMS way or not altering my graphical assets in anyway unless I tell it to do so.
What choice do I not have with GameMaker?
- I can scale my sprites at run time and draw them scaled up on the application surface or draw them native size.
- I can scale the application surface before hand or draw everything "native size" on it and scale it up right before drawing it to screen.

So basically I can make my sprite rotations look any way I want. Can you have it appear "raw" in Stencyl?
I don't know whether you can make it "raw" in Stencyl, but I do know that I've never had the desire to, or even thought about the possibility -- my images always just looked right the way Stencyl rendered them, which is why I think that should be the default behavior for GameMaker as well.

Having the choice is great, but at least make both choices easy to implement. I have just about no idea how to actually go about making my sprites look like they did in Stencyl. Can you give me a simple script that will work for any sprite? Because it should be that easy...
 

CMAllen

Member
I don't know whether you can make it "raw" in Stencyl, but I do know that I've never had the desire to, or even thought about the possibility -- my images always just looked right the way Stencyl rendered them, which is why I think that should be the default behavior for GameMaker as well.

Having the choice is great, but at least make both choices easy to implement. I have just about no idea how to actually go about making my sprites look like they did in Stencyl. Can you give me a simple script that will work for any sprite? Because it should be that easy...
Okay. Just to put this whole thing to bed, I did my own test project, loaded this exact sprite into it, applied scaling, and set it spinning in the step event. Results? Exactly as I expected. The original test images aren't actually representative of anything:


Both images are direct captures from GM test window. 4x scale. Achieved and tested both via a direct scale set using image scale variables and by viewport scaling. So the original images are EXTREMELY misleading (to the point of being questionably deliberate). Those images of the ball from GM weren't scaled inside GM (or scaled to less than whole values). They were captured, brought into an image editor and THEN scaled to match the size of the Stencyl images. Compare apples to apples, if you would.
 
D

djrain

Guest
Okay. Just to put this whole thing to bed, I did my own test project, loaded this exact sprite into it, applied scaling, and set it spinning in the step event. Results? Exactly as I expected. The original test images aren't actually representative of anything:


Both images are direct captures from GM test window. 4x scale. Achieved and tested both via a direct scale set using image scale variables and by viewport scaling. So the original images are EXTREMELY misleading (to the point of being questionably deliberate). Those images of the ball from GM weren't scaled inside GM (or scaled to less than whole values). They were captured, brought into an image editor and THEN scaled to match the size of the Stencyl images. Compare apples to apples, if you would.
This is simply not accurate. Let me see if I can explain:

I did not intentionally scale the sprites inside GM or Stencyl when running the game. The only scaling that happened was the scaling that the engines automatically applied to fit the screen's aspect ratio. So the images were equally scaled when the screenshots were taken.

Then I simply took the liberty of zooming in on the images so we all could see them better. I tried to make sure they all ended up more or less the same size, although I really don't think it makes much difference.

So my original images are representative of how the sprites looked in-game. Not scaled 4x like you did.

Below is the ball captured directly from GM test window on the left, Stencyl test (without AA) on the right. The sprites were not scaled, nor were the resulting images (actually the forum seems to be upscaling them a bit, but I can't help that. I just took the screenshots and put them straight in here.)

Screen Shot 2017-08-24 at 12.32.57 AM.png Screen Shot 2017-08-24 at 12.44.57 AM.png
 

CMAllen

Member
This is simply not accurate. Let me see if I can explain:

I did not intentionally scale the sprites inside GM or Stencyl when running the game. The only scaling that happened was the scaling that the engines automatically applied to fit the screen's aspect ratio. So the images were equally scaled when the screenshots were taken.

Then I simply took the liberty of zooming in on the images so we all could see them better. I tried to make sure they all ended up more or less the same size, although I really don't think it makes much difference.

So my original images are representative of how the sprites looked in-game. Not scaled 4x like you did.

Below is the ball captured directly from GM test window on the left, Stencyl test (without AA) on the right. The sprites were not scaled, nor were the resulting images (actually the forum seems to be upscaling them a bit, but I can't help that. I just took the screenshots and put them straight in here.)

View attachment 12110 View attachment 12111
And so are the images I've shown. Right out of a running GM app. There's clearly something different between the two, and it is skewing the results. They're not being uniformly transformed or in the same manner.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
I haven't read this whole thread so apologies if this is covered... The difference you are seeing is related to the APP SURFACE resolution. By default this will be set to the room size or (if views are active) the visible camera view size, and so may not be 1:1 with the screen resolution. If you want it to be 1:1 with the screen resolution make sure that it is the same size as the game WINDOW (and/or View Port) using surface_resize(). I would suspect that stencyl draws directly to the screen buffer (something that GMS can do too if you disable the application surface).

So, run the test project, get the window width/height and set the application surface to be the same and then see how it looks, and also try by disabling the app surface and checking.
 

RangerX

Member
I haven't read this whole thread so apologies if this is covered... The difference you are seeing is related to the APP SURFACE resolution. By default this will be set to the room size or (if views are active) the visible camera view size, and so may not be 1:1 with the screen resolution. If you want it to be 1:1 with the screen resolution make sure that it is the same size as the game WINDOW (and/or View Port) using surface_resize(). I would suspect that stencyl draws directly to the screen buffer (something that GMS can do too if you disable the application surface).

So, run the test project, get the window width/height and set the application surface to be the same and then see how it looks, and also try by disabling the app surface and checking.
Thanks, you worded it better than me in just one post!
*sweat
 

dannyjenn

Member
Wait... is the original sprite 15x15 or 30x30? It appears that the sprite was already upscaled to 200% (nearest neighbor), either in the sprite editor or else before it was even loaded into GameMaker.
Then in the game, GameMaker just rotated it 45 degrees. The one with "interpolation on" is bilinear interpolation (I think), which is why it's so blurry. The one with "interpolation off" is nearest neighbor interpolation, which is why it looks like garbage (nearest neighbor rotation never looks good on pixel art).
As for what Stencyl is doing, I have no idea. It is literally impossible to get those results without additional scaling, since those "diagonal pixels" are each at least 4x4. I think Stencyl is probably doing some scaling behind the scenes.
 
Last edited:

dannyjenn

Member
Kind of off-topic, but if you want to rotate pixel art without getting the "diagonal pixels", there is an algorithm called RotSprite.
https://en.wikipedia.org/wiki/Pixel_art_scaling_algorithms#RotSprite
http://info.sonicretro.org/RotSprite
http://forums.sonicretro.org/index.php?showtopic=8848&st=15&p=159754&#entry159754
https://brashmonkey.com/forum/index.php?/topic/3394-great-algorithm-for-rotating-pixel-art-sprites/
This hasn't been implemented into GameMaker, but I think a shader could do it (too advanced for me to write at the moment...)
 
Last edited:

muki

Member
I'm assuming the ball is meant to roll 360+ degrees in many cases? I did this in photoshop.

This is the ball sprite, unrotated.


Here it is with a 155 degree rotation, looks good?


It doesn't. Because suddenly the ball is being lit from the lower right, instead of the top left. Look at the shadowing/highlight. This is a huge reason why rotating sprites looks bad.

You can achieve much higher art quality by animating the rotation by hand with multiple frames of animation, and having the light/shade be consistent. You can use RotSprite to help too. Rotate some frames of a full ball rotation, then fill in the shade in touchup. Animating a sprite well is not automatic or "free", it is work. But most good looking pixel art takes work.

Rotating sprites is bad pixel art. You'll have a rotating ball and the sun/light source spinning around the ball as quickly as it turns.

Can stencyl automatically fix the light/shade issue? Not trying to be confrotnational, just trying to make a point that automatic isn't always a good solution for good image/art quality. And in some cases it's detrimental.
 
Last edited:
  • Like
Reactions: Yal

Simon Gust

Member
I'm assuming the ball is meant to roll 360+ degrees in many cases? I did this in photoshop.
This is the ball sprite, unrotated.
Here it is with a 155 degree rotation, looks good?
It doesn't. Because suddenly the ball is being lit from the lower right, instead of the top left. Look at the shadowing/highlight. This is a huge reason why rotating sprites looks bad.
You can achieve much higher art quality by animating the rotation by hand with multiple frames of animation, and having the light/shade be consistent. And it would be extremely fast and easy with RotSprite too. Rotate some frames of a full ball rotation, then fill in the shade in touchup.
Rotating sprites just looks bad. You'll have a rotating ball and the sun/light source spinning around the ball as quickly as it turns.
Can stencyl automatically fix this?
The main problem with rotating pixel art isn't the lighting though, it's the fact that you have diagonal pixels. That is the single most ugly art that exists and it's just lazy.
 
  • Like
Reactions: Yal
D

djrain

Guest
I'm assuming the ball is meant to roll 360+ degrees in many cases? I did this in photoshop.

This is the ball sprite, unrotated.


Here it is with a 155 degree rotation, looks good?


It doesn't. Because suddenly the ball is being lit from the lower right, instead of the top left. Look at the shadowing/highlight. This is a huge reason why rotating sprites looks bad.

You can achieve much higher art quality by animating the rotation by hand with multiple frames of animation, and having the light/shade be consistent. You can use RotSprite to help too. Rotate some frames of a full ball rotation, then fill in the shade in touchup. Animating a sprite well is not automatic or "free", it is work. But most good looking pixel art takes work.

Rotating sprites is bad pixel art. You'll have a rotating ball and the sun/light source spinning around the ball as quickly as it turns.

Can stencyl automatically fix the light/shade issue?
It was just an example to demonstrate the graphical issues. I'm not actually going to rotate this particular sprite in my game. Let's not assume things.

The main problem with rotating pixel art isn't the lighting though, it's the fact that you have diagonal pixels. That is the single most ugly art that exists and it's just lazy.
That is your opinion, and I don't agree. Sure it isn't "true" pixel art, but who cares? Art is subjective. I will point out that it's not any more "lazy" than making a single vector image and rotating that. But I really just want to figure out how to fix this, so if we could stay on topic that would be great.
 
D

djrain

Guest
Wait... is the original sprite 15x15 or 30x30? It appears that the sprite was already upscaled to 200% (nearest neighbor), either in the sprite editor or else before it was even loaded into GameMaker.
Then in the game, GameMaker just rotated it 45 degrees. The one with "interpolation on" is bilinear interpolation (I think), which is why it's so blurry. The one with "interpolation off" is nearest neighbor interpolation, which is why it looks like garbage (nearest neighbor rotation never looks good on pixel art).
As for what Stencyl is doing, I have no idea. It is literally impossible to get those results without additional scaling, since those "diagonal pixels" are each at least 4x4. I think Stencyl is probably doing some scaling behind the scenes.
30x30.
 

muki

Member
It was just an example to demonstrate the graphical issues. I'm not actually going to rotate this particular sprite in my game. Let's not assume things.
I understand.

But if you do sprite rotation, *any* sprite with lighting/shading on it is going to look wrong. Doesn't matter what it is, unless you're just rotating unlit particle effects.
 

RangerX

Member
If you want to fix this, resize your application surface at the size of the monitor the game is displayed in and your rotations will benefit from the full resolution available.
Use the function "surface_resize()" and the constant "application_surface" when your game boots.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Use the function "surface_resize()" and the constant "application_surface" when your game boots.
Yep, please try this and get back to us. I said the same too earlier, but with all the off-topic comments in this thread you may have missed it... ;)
 
Top