Jump to content
Double Fine Action Forums
Sign in to follow this  
Ryukaki

Editing Spritesheets

Recommended Posts

So, there's a problem with the GlyphRoom spritesheet.

['Port 1'] = {

dimensions = { 321, 246 },

eventTracks = { },

frames = {

{

colorRect = { 0, 0, 321, 246 },

imageIndex = 1,

rect = { 0, 1698, 321, 1744 },

size = { 321, 246 },

uvRect = { 0, 0.8291015625, 0.15673828125, 0.94921875 },

},

},

hitboxTracks = {

body = {

{

duration = 0,

frame = 1,

rect = { 22.5, 64, 160.5, 188 },

},

},

},

jointTracks = { },

pivot = { 160.5, 0 },

soundCueTracks = { },

},

['Port 2'] = {

dimensions = { 370, 474 },

eventTracks = { },

frames = {

{

colorRect = { 0, 0, 370, 474 },

imageIndex = 1,

rect = { 0, 1220, -370, 1694 },

size = { 370, 474 },

uvRect = { 0, 0.595703125, 0.1806640625, 0.8271484375 },

},

},

hitboxTracks = {

body = {

{

duration = 0,

frame = 1,

rect = { -160, 290, -31, 406 },

},

},

},

jointTracks = { },

pivot = { 185, 0 },

soundCueTracks = { },

},

Specifically, the issue is that the "rect" defining these two ports are grossly mis-aligned with what they should be, and due to this, there is some graphical artifacting and vfx playing incorrectly when you attempt to hack these blocks. (These are Port U and Port V for aligning the text offsets.)

The rectangles defined here, include very large areas of the spritesheet where there is only the transparency layer, and along with this, whoever set up the level used a silly hack to make the room work, specifically,

{

dir = 5,

loc = { 716, 174 },

name = 'Port 2',

path = 'Content/Game/DweebKeep/Entities/GlyphRoom/Port',

},

{

dir = 5,

loc = { 745.5, 172 },

name = 'Port 1',

path = 'Content/Game/DweebKeep/Entities/GlyphRoom/Port',

},

This line here, sets the origin points for these two ports erroneously at the bottom of the map:

http://cloud-3.steampowered.com/ugc/433783980817770738/6674484A5B85CAF646234A5DB377F5FF0F39CC9B/

You can see their origin points are right next to Alice, but the actual blocks collision/sprite components are located where they are intended. This causes the following effect:

http://cloud-3.steampowered.com/ugc/433783980817811321/6660F976AB7082AB375C9A6E15A00708E942646C/

As you can see, the "hack" sparkles are located at the bottom of the screen, where the actual origin point of this sprite is, rather than on the object being hacked. Additionally, there is a large black bar cutting across the screen which is the "top" of the rectangle defined above, accidentally cutting into the black chunk which is above this sprite area on the spritesheet.

Using the following coordinates for the origin points:

{

dir = 5,

loc = { 618, 531 },

name = 'Port 2',

path = 'Content/Game/DweebKeep/Entities/GlyphRoom/Port',

},

{

dir = 5,

loc = { 846, 310 },

name = 'Port 1',

path = 'Content/Game/DweebKeep/Entities/GlyphRoom/Port',

},

Puts the origin points for these sprites in the correct place, but because of the rectangles defined in the spritesheet, this offsets the sprites by a large amount:

http://cloud-2.steampowered.com/ugc/433783980817859246/F26273C5F30DB3DE6869A5CAF37A006D5732E864/

So, after all of my yammering about HOW this setup is broken, I'm actually writing this all to inquire about why making edits to the "Rect" component of the spritesheet entries seems to yield no changes at all in-game. Is there somewhere else I'm supposed to go to edit what sections of the spritesheet are reserved for specific sprites? I feel like I'm missing something simple here, again. Perhaps this is just broken right now and is also in need of fixing? I'm just not sure. I've tried fiddling with every component I can think of, but have come up dry.

Thanks a bunch for your time!

Share this post


Link to post
Share on other sites

I may be wrong, but I believe it's because "rect" only controls the draw area, not the draw location.

Have you considered the possibility that the cause of the bad alignment isn't some variables but the actual graphics?

Share this post


Link to post
Share on other sites

The problem isn't a graphics issue, though. The graphics in the file are just fine.

These are the areas defined by the "rect" variable in the spritesheet file (roughly, this is not exact, but it's close.)

http://i.imgur.com/uf6ld7C.png

If you assume the bottom-left of each rectangle to be the 0 coord (the point where the game starts drawing the sprite into the game world from the origin point of the actual placement of the object in the layout file) then you see these exact offsets are being applied in-game. This is what is happening in-game:

http://imgur.com/qkYtZet

There are further offsets to these placements because of the variable "pivot" which offsets the sprites by a number of pixels from the origin point.

Because those are the areas defined by the spritesheet. (The values in "rect" represent pixel-points on the spritesheet and form a rectangle over that area.)

My understanding is that the values in "rect" are just not set correctly-- even if it were the case that it only controls the draw area, I could modify the values in the spritesheet and fix the issue, but modifying the values in "rect" don't do ANYTHING. At all. No matter how much I change them.

I've checked every single other avenue, lua file, etc. on this one, and the only place I can find a discrepancy is how they're being accessed through the spritesheet :\

Share this post


Link to post
Share on other sites

Upon further examination, I think what you actually want to edit is uvRect. Those actually match up with the texture.

No idea what rect is actually supposed to represent though.

Share this post


Link to post
Share on other sites

Okay, so, uvRect did fix the issue with the black bar being drawn when you hack the object. Changing it very slightly eliminated that problem. It was helpful!

The variables that are invoked to fix this problem are actually pretty simple.

hitboxTracks = {

body = {

{

duration = 0,

frame = 1,

rect = { 22.5, 64, 160.5, 188 },

},

},

},

jointTracks = { },

pivot = { 160.5, 0 },

soundCueTracks = { },

},

This is where all of the magic takes place, really. "Pivot" is an offset from the 0,0 coords where the info pulled from the uv map is placed. Adjusting the UV map actually causes stretching/tearing with any major changes, so fixing it there didn't seem to be a good way of doing it.

However, the hitbox, and with it the associated sprite, can be moved by adjusting rect= in the hitbox tracks. These values are additional offsets from 0 which define a rectangle, simple as that.

Using a combination of the Pivot and Hitbox Track, as well as modifying the origin point of the objects, I cleaned up the two objects and now the room is sparkly clean.

These two files fix every issue with the Glyph Room layout:

http://ryukaki.com/HackNSlash/GlyphRoom.spritesheet

http://ryukaki.com/HackNSlash/GlyphRoom.layout

Feel free to diff those against your current ones to see exactly what I changed and where, it takes a bit of fiddling to get used to what each of the values do, but I'm writing up documentation for myself so that I can come back to it in the future \o/

Thanks for your input on the matter, Smash! Getting back in and digging around finally provided some workable results, and now I get how all of the object placement works. It's very, very clear that the guys at DoubleFine use a tool for placing objects in-level, and do not do it by hand. It's very clumsy to do that way x.x

Share this post


Link to post
Share on other sites
Sign in to follow this  

×
×
  • Create New...