Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

jozanza

3
Posts
2
Topics
3
Following
A member registered Apr 08, 2017 · View creator page →

Recent community posts

(1 edit)

It would be really cool to get the following methods added to apiBridge

  • DrawCircle - a filled/outlined version
  • DrawRect - a filled/outlined version

The following parameters would be super useful for DrawSprite(), DrawSprites(), and potentially DrawScreenBuffer()

  • rotationAngle - in radians or degrees (not sure what makes more sense)
  • scale - a number by which to scale the sprite(s) or screen buffer

The the following parameter to DrawFont() and DrawFontToBuffer() would reduce a lot of code

  • colorId - I'm not even sure how to print non-white text at this point. ReplaceColorId()?

And here's a general question:

Would it make sense to let these apiBridge methods accept a single table with various properties instead of a crazy huge arguments list? IMHO, it would help a lot for dealing with optional params, trying to remember the order of the params, memoizing params, and adding new options in the future.

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.

(4 edits)

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.