🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

v0.6.3 - Sprite importing is generally a bit broken [RESOLVED]

A topic by jozanza created 196 days ago Views: 130 Replies: 7
Viewing posts 1 to 3
(Edited 4 times)

I spent the past several hours playing around with different bits of functionality and reading through the very thorough documentation on gitbook. I'm very excited about this virtual console :)

Unfortunately, unless I'm just doing it wrong, I've encountered several major issues with importing sprites:

  • Setting SpriteChip's spriteHeight/spriteWidth to values other than 8 causes Sprite Editor to glitch out. Using 16 or 32, for example, will cause the sprite editor to ignore colors in sprites.png and jumble the imported image into a strange glyphs. Luckily, the image on disk is not actually corrupted; it's only being displayed improperly in the editor. Too bad it also causes the game to throw an "IndexOutOfRangeException: Array index is out of range" error when running.
  • SpriteBuilder sprites do not get imported. I troubleshot by deleting the existing sprites.png / reloading / re-exporting, but I could not get it to work. Obviously, as a side-effect, Sprite Editor's "builder" button appears, but has no effect.
  • Regardless of which system colors you have set, only black/white and the GB palette colors are imported/exported from sprites.png. Every other color is converted to #FF00FF. I did get it to work properly for a bit by copying colors.png and renaming it to color-map.png. However, this workaround broke at some point while I was messing around with the SpriteBuilder folder.

UPDATE: I just noticed colors.png is probably the culprit behind the color mismatches. The Display Editor shows similar but different hex values on each swatch when compared to each pixel in colors.png.

UPDATE: I had assumed SpriteBuilder replaces the need for a sprites.png, however, SpriteBuilder actually relies on sprites.png inside the Game directory to generate the tables that get injected into code.lua.

It sounds like you were able to sort some of this out? The importer is picky on making sure that colors match across the board. If you are off or missing colors in the sprites.png that don't exist in the colors.png, they are ignored. I will look into a way to help debug import via the log so you can have more visibility into what is happening when everything is parsed.

As for increasing the sprite size that isn't currently supported. The plan is to optimize everything for 8x8 sprites then look into supporting different sizes. The Nes, for example, supported 16x8 sprites as well, but currently, I do not have a clean way to define that. While you can change it manually in the data.json file it will probably break the renderer.

The last thing, I am not sure what your issue may be on the SpriteBuilder. I plan on creating a dedicated tool to help make that process clearer. If you have color issues importing your art, the SpriteBuilder will fail too since they all rely on the same importer.

Hope that helps. If you have specific problems you are stumped with, you can link to a .pv8 project, and I can try to take a look as well. For anyone that bought early access, I will do my best to offer 1:1 support where/when I can ;)

Thanks for the quick reply! I was actually just about to add another update to my original post.

I stepped away from my project for a while, and when I revisited, I figured out the issue with SpriteBuilder.

For some reason, I had assumed sprites.png would be generated from a composite of all the pngs in the SpriteBuilder folder. I know now that's apparently not the case, and in order for the SpriteBuilder injection to work properly, PV8 still requires a sprites.png for matching purposes. So, that one's sorted...but it does seem a little redundant to require a sprites.png when PV8 could just create one on the fly.


Also, small enhancement I'd love to see: don't strip characters from the filenames of SpriteBuilder .pngs.

Since dots and brackets are stripped, I ended up putting unicode escapes into my png filename -- sprites\u005B'foo'\u005D\u005B1\u005D.png, for example. Then after hitting the 'builder' button to inject the data into code.lua, I run a small shell script:

#!/bin/zsh
echo -ne "$(cat code.lua)" > code.lua

This converts the unicode escapes back into UTF-8, so I wind up with the very convenient code below:

local sprite_names = {'foo'}
local sprites = {}
for i,v in ipairs(sprite_names) do
  sprites[v] = {}
end
-- spritelib-start
sprites['foo'][1]={width=2,unique=4,total=4,spriteIDs={2,3,10,11}}
sprites['foo'][2]={width=2,unique=4,total=4,spriteIDs={0,1,8,9}}
-- spritelib-end

I do this because if you have a lot of animation frame sprites, it kind of makes more sense to push all the injected data into a table than create a unique var for each one. It would eliminate the code smell of having to manually write code to table.insert each one. Obviously, it would be a lot nicer for my workflow (and eyes) to be able to use brackets/dots in my filename without them getting stripped during injection into code.lua.

The importer is picky on making sure that colors match across the board. If you are off or missing colors in the sprites.png that don't exist in the colors.png, they are ignored. I will look into a way to help debug import via the log so you can have more visibility into what is happening when everything is parsed

This threw me off for a couple hours as well. It would help to have a blurb about this in the document section related to loading sprites. Maybe just something that mentions the issue and points the reader back to the color map section for further information.

I agree! The docks have been on the back burner for some time. I need to dedicate a sprite to just getting all of it up to date.

If you need help with the documentation, whether it's editing or layout or something, let me know. I'd be happy to help.

I appreciate it. Unfortunatly most of the documentation is on my head. I have an automated system for converting google docs into an ebook. It just takes time to write it all down. Each release gets a little bit closer to full documentation. 

I totally understand. Still, if you want someone to read over the docs before a release, I would love to help. I do this kind of thing for customer-visible knowledge base articles at work.