Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Sprite chopping on 1072

Author
Message
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 9th May 2012 20:37 Edited at: 9th May 2012 20:56
Link
In Windows 1072 some sprites are being shaved off the sides by 1 pixel.

All was fine in 1071.

This used to happen in AppGameKit 106 in odd sized sprites (35 x 37). Having sprites evenly sized (36 x 38) solved the problem back then.

Any ideas if there are some filtering commands that can be applied to sort this out?
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 14th May 2012 18:05
Link
This is happening on 1073 on Windows too.

On ios all works fine.
On 1071 windows all worked fine too.

I have attached how the circle should appear

Attachments

Login to view attachments
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 14th May 2012 18:06
Link
and this is how the circle is appearing erroneously

the edges are being chopped off

Attachments

Login to view attachments
Back to top
Profile PM Email
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 14th May 2012 18:14
Link
Have you tried the SetSpriteUVBorder(ID,0) command?
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 14th May 2012 18:23
Link
Paul

SetSpriteUVBorder(ID,0) has no effect.

Strangely enough all works fine on iOS but not on Windows. It used to work on Windows up to 1071!

It has to do with anti-aliasing as using SetDefaultMinFilter(0) works, but the anti-aliasing is totally ignored and the sprite looks horrible!

Any other ideas?
Back to top
Profile PM Email
LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 14th May 2012 18:32
Link
Send me a small project with media and email to lee@thegamecreators.com so I can try against 1071 and 1074, thanks.

I drink tea, and in my spare time I write software.
Back to top
Profile PM Email Website
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 14th May 2012 18:33
Link
Try SetSpriteSnap(ID,1). Also can you email me the image and the code you are using to display it?
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 14th May 2012 19:02
Link
I have attached a sample image here with the incorrect version of how its displayed.

There is just a SetSpritePosition() command!
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 14th May 2012 19:10
Link
Paul SetSpriteSnap(ID,1) fixed it!

Would it be possible to have this ON by default as it was in 1071?

Having to set sprites manually in code (I have more than 350) is a real bugger!!!!
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 14th May 2012 19:15
Link
Emailed the sample image to Lee too.
Back to top
Profile PM Email
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 14th May 2012 19:38
Link
In that case it is a result of the difference in device resolution between Windows and iPhone. If a sprite's edge falls on the boundary between two pixels because there are not enough to give a 1:1 representation of the sprite then those pixels could either disappear or bleed into the next pixel causing either 1) missing pixels or 2) a visible border along that edge. SetSpriteSnap avoids this by expanding or contracting the sprite ever so slightly that its edge will always be on a whole pixel, removing problems like this.

However if your sprite has alpha pixels along its edge, or is rotating then it will not suffer from this problem, and since this is more common in sprites the snap function is off by default.
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 14th May 2012 19:41
Link
Sprites don't have an alpha border and are not moving or rotating that's why they have this problem.

Is it a big problem to have it work by default like it was in 1071?
Or have some kind of Global SetSpriteSnap command?
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 16th May 2012 18:54
Link
I have updated to 1074 and on windows sprites are still chopped off.

For my information, do you plan to have SetSpriteSnap(1) on by default for aLL sprites in the future or it will always stay as it is now?
Back to top
Profile PM Email
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 16th May 2012 19:40
Link
Quote: "do you plan to have SetSpriteSnap(1) on by default for aLL sprites in the future or it will always stay as it is now?"


The majority of sprites shouldn't need it so unless there is a large demand for this it will stay as it is.
Back to top
Profile PM Email
DVader
20
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 16th May 2012 20:02
Link
@ bjadams, with no setdefaultspritesnap() feature available, although that could be an idea as an addition rather than just changing the default, I would just do it the brute force way.

Of course if you have no clue where your sprite ranges start and end, it may be a large range you check, but it wouldn't really take long. I always know exactly what sprite ranges I use, so I can do this sort of thing quite quickly in my projects. I have never been keen on letting AppGameKit pick a number for you automatically and just using names rather than numbers. They start from the 10000 range, as I am sure you know anyway, if you do use names and never set numbers yourself.

Back to top
Profile PM Website
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 16th May 2012 20:39
Link
DVader nice idea. Yes sprites start from 10000 and I have around 450 sprites right now!
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 16th May 2012 20:50
Link
Paul could this be happening a lot cos my sprites are line-art, black and white with greyscale anti-aliasing, like in the sample I attached above?
Back to top
Profile PM Email
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 17th May 2012 00:59
Link
Quote: "could this be happening a lot cos my sprites are line-art, black and white with greyscale anti-aliasing"


Yes, traditionally alpha is used to anti-alias the edge of a sprite into the background
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 17th May 2012 01:06
Link
What drives my curiosity most is why this is not happening on the iPad??? windows & ios projects are both 1024 x 768 pixels.

I need to check some other project then.

What I am doing is grab the AppGameKit screen, load in Photoshop, zoom, and compare the edges with the original to see if I can spot any difference!!!!

Maybe this sounds too extreme, but my graphic artist is a perfectionist and if he sees any variations on his artwork, he gets angry very fast!!!
Back to top
Profile PM Email
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 17th May 2012 01:25
Link
The resolution is a vital component in this problem, I can try a rough example. Say you have a sprite that covers one third of the screen, which on a 480 pixel width display would be 0 to 160 pixels. On a 1024 pixel display this same one third sprite would occupy 0 to 341.33 pixels, so its edge is not on a whole pixel boundary. In this case the 1024 pixel display might show an artefact, or cut that pixel off. In other cases, for different sprite sizes, the 480 pixel display will have the problem whilst the 1024 display looks perfect.

SetSpriteSnap would stretch the sprite slightly on the 1024 display so it occupied 0 to 341 pixels, which might make it jump every now and again but solves the half pixel problem.
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 17th May 2012 08:52
Link
Paul so why was everything working fine until 1071?

Why was this SetSpriteSnap necessary now?
Back to top
Profile PM Email
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 18th May 2012 02:23
Link
I believe sprite snapping was on by default until someone complained about the sprite jumping from pixel to pixel instead of moving smoothly, so it got turned off and the new command to turn it back on was created.
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 18th May 2012 16:41 Edited at: 20th May 2012 17:33
Link
I can confirm that with SetSpriteSnap set ON, I did notice some sprite jumping/jerking on Windows, when moving sprites left/right but NOT when just rotating sprites.
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 28th May 2012 18:16
Link
SetSpriteSnap is not working on 1075 on Windows. did not check other platforms.

Reverted to 1074 and the command works fine there.
Back to top
Profile PM Email
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 29th May 2012 01:15 Edited at: 29th May 2012 01:16
Link
Quote: "SetSpriteSnap is not working on 1075 on Windows. did not check other platforms."


A side effect of using native orientations, or at least my implementation of it, I've fixed it for the next update, possibly 1076.

Whilst digging around I noticed that on my machine using SetImageWrapU( ID, 1 ) and SetImageWrapV( ID, 1 ) (repeat instead of clamp) solved the issue without having to use SetSpriteSnap, on both Windows and Android, I've made this the default setting for the next version in the hopes that it will solve it once and for all.
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 29th May 2012 13:13
Link
Sounds great Paul!

How come this does not happen on iOS (just my curiosity)?
Back to top
Profile PM Email
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 29th May 2012 17:06
Link
Could be a different device resolution, or the lack of black borders, those are most likely. Does SetImageWrapU( ID, 1 ) and SetImageWrapV( ID, 1 ) fix it for you with the current version?
Back to top
Profile PM Email
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 29th May 2012 18:02
Link
I tried SetImageWrapU(ID, 1) and SetImageWrapV(ID, 1) on 1075 but I didn't see any difference.

Do I need to apply these to the image before a sprite is created?

Right now I am applying them AFTER the sprite is created.

Tested on iOS and all looks okish without any SetImageWrap or SetSpriteSnap

Luckily I am only using AppGameKit to output on iOS!
I have a project 100% ready for Playbook but I am waiting for the Playbook AppGameKit with adverts before releasing.
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-04-27 14:42:36
Your offset time is: 2024-04-27 14:42:36