Author Topic: Sprite Encoding  (Read 2967 times)

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Sprite Encoding
« on: January 26, 2017, 12:24:12 PM »
I've been thinking a bit about one of my other projects and how to encode basic information so I don't need to either hard code it or have an external definition file.

The general idea is this. You have a room with several different states including footprint (which includes width of the room and how many floors it occupies). Each room has several states -- empty, idle, active, busy, burned and flooded.

The image file for the room is stored as a 32-bit image, 8 bits per channel with four channels (RGBA).

Rooms need a few bits of information -- the locations of the slices within the overall image of each 'state' of the room, the width and height of the room, its build cost, maintenance cost, room type and a few other things.

It occurred to me that almost all of this numeric in nature and can be encoded into the RGBA values. Width/Height is easy enough using the Red and Green components assuming you never have anything that exceeds 255. OR, you can interpret each pixel as a 32bit value giving you up to 2,147,483,647 for signed values (and 4,294,967,294 for unsigned values). In terms of the above, this should be more than sufficient. Hell, even words can be encoded this way when using the ASCII code page only (values 0 - 255), allowing for a single pixel to store up to 4 characters (though this would suffer from a problem with localization to other languages).

I guess what I'm wondering if this is worth the effort? It would eliminate the need for external definitions separate from the image files themselves and could encode all pertinent information within the pixel data itself. It would also be fast as there would be no need to parse and interpret a text file though a basic utility would be needed to encode the more complex data (fairly simple to develop, honestly).

Thoughts?

Offline Arklon

  • Administrator
  • Hero Member
  • *****
  • Posts: 1269
Re: Sprite Encoding
« Reply #1 on: January 28, 2017, 09:48:01 PM »
I'm honestly not sure I see the point. I would think ease/straightforwardness of working with the files is better than baking information into bitmap data in an unusual way. If you really wanted them to be in one file, you could make a container. Also, nothing saying the definitions file has to be text, OP2 has a binary one, and if you can make a tool to bake defs into a bitmap, you can make one to generate a separate binary-formatted file.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Sprite Encoding
« Reply #2 on: February 01, 2017, 01:38:20 PM »
As I started to get further into thinking about it it occurred to me this is encroaching on 'clever' which usually translates to 'bad'. It'd be a lot easier, as you suggested, to just create a binary container format. I'll stick with human readable text definitions that simply reference an image file -- it's worked for me over the last 10 years or so.

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: Sprite Encoding
« Reply #3 on: February 04, 2017, 04:58:54 PM »
I've gone back and forth about this also. Eventually I settled on the fact that it's really only "useful" (practically speaking) when the data is inherently visual. If it's not really visual data, then encoding it in rgb channels really ends up obfuscating the information. When things aren't quite right, it becomes an exercise to break it all back out (when the data isn't inherently visual) to see where things have gone wrong.

Offline Goof

  • Jr. Member
  • **
  • Posts: 57
Re: Sprite Encoding
« Reply #4 on: February 05, 2017, 05:50:43 PM »
Hi

It seems that PNG could include text data.
On wikipedia they talk about "iTXt","tEXt" and "zTXt" chunk

See : https://en.wikipedia.org/wiki/Portable_Network_Graphics#Ancillary_chunks

It may need a PNG library that could handle those data fields.

It may worth digging.

Otherwise.
At work we had to display a "graphical" state of cheeses cellars.
The tricky part was to link the graphical data with the database data or consolidated data.
We used SVG files to describe the graphical layout of the cellar.
As it's encoded as an XML files.
We added some extra fields to the SVG elements that we needs to tune from our software.
It was mainly a location Key from the database.
In the display part of the software we use DOM to alter the SVG file on the fly.
It worked perfectly for us.
Our client manages more that 100 000 cheese wheel that way.

It may depend on the type of sprites you need to use.

As there is more and more Hi-DPI screens, the use of a vector image format might be a good idea.

A++ Goof