[Feature request] Zero-indexed frames

[joolin1]

For me it is troublesome that the frames are indexed from 1. When coding, everything is zero-indexed. This means I constantly have to translate the indexes in piskel to what I use in code (i e subtract with 1). What about an option to choose how to index the frames?

[blurymind]

I am failing to see a use case where this would actually make a difference to the end user? Do you have a problem with the way exported files are named?

[joolin1]

Let's say you make 10 sprites (32x32 pixels) for use in a game. If you export them as a .c-file you get a two dimensional array: data[10][1024]. Then you refer to sprite 1 by stating data[0][0], sprite 2 - data [1][0], that is because the array is zero-based like always when coding. I am making a game in assembler. Same thing, I read a binary file to a certain address. At offset 0 I find what Piskel call sprite 1. By adding the size of a single sprite (1024) once I get the address of sprite 2. I also use Piskel for making tiles to build a map (graphical background). When defining the map that is 32x32 tiles, 0 - becomes what in Piskel is called frame 1, 1 becomes 2 etc. Shorter said: when drawing in Piskel frames are numbered from 1, when turn to coding everything starts with 0. Therefore it would be easy and consistent for developers if Piskel would have the option to start with frame 0, at least that is what I think.

[blurymind]

So what are you using piskels json data for rendering sprites in your game, just so you can write some very specific logic that is not clear of it would translate in any fun for the player mechanic? I am very confused by your request? It sounds like a waste of time and kind of inneficient. Won't it be cheaper to use png images for sprite resources?

On Thu, Jan 30, 2020, 7:15 PM Johan Kårlin notifications@github.com wrote:

Let's say you make 10 sprites (32x32 pixels) for use in a game. If you export them as a .c-file you get a two dimensional array: data[10][1024]. Then you refer to sprite 1 by stating data[0][0], sprite 2 - data [1][0], that is because the array is zero-based like always when coding. I am making a game in assembler. Same thing, I read a binary file to a certain address. At offset 0 I find what Piskel call sprite 1. By adding the size of a single sprite (1024) once I get the address of sprite 2. I also use Piskel for making tiles to build a map (graphical background). When defining the map that is 32x32 tiles, 0 - becomes what in Piskel is called frame 1, 1 becomes 2 etc. Shorter said: when drawing in Piskel frames are numbered from 1, when turn to coding everything starts with 0. Therefore it would be easy and consistent for developers if Piskel would have the option to start with frame 0, at least that is what I thing.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/piskelapp/piskel/issues/914?email_source=notifications&email_token=ABRRWVKTHBOB64F4OOGYB7LRAMRNRA5CNFSM4KCR3RJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKMFUZI#issuecomment-580409957, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRRWVJYJHGDOT64OQQ2ZOTRAMRNRANCNFSM4KCR3RJA .

[joolin1]

Yes, you seem to totally miss my point. If I export my sprites as json files, c source files or binary files is totally irrelevant. It was just an example I used for explaining. That is why I started the sentence with the words "Let's say...". It doesn't matter in what format you export you sprites, the problem is the same. Maybe we have a linguistic confusion? However, let us look at a new example:

1. You are making a game in assembly language
2. You draw 10 sprites in Piskel and export them as a png file for use in your code
3. You include the binary file (i e the png file) in your project.
4. The size of each sprite is 1024 bytes.
5. The formula to address a sprite becomes: base address of sprites + index * 1024
6. To address what Piskel call sprite 1 you set index to 0
7. To address what Piskel call sprite 2 you set index to 1

Conclusion: This example tries to show what always is the case when coding. Arrays or whatever you are using are zero-indexed. Piskel on the contrary is not. It's not a big issue, but offering the possibility to number the sprites from zero would be an improvement for coders.

[blurymind]

I guess I dont get your point, so therefor have no interest to address it :) but you can. Feel free to submit a pr

Then present with your PR a real minimal example of its use. If it has no regressions and the example case does make sense, its more likely that it will get in

https://scontent.fman1-1.fna.fbcdn.net/v/t1.0-9/83576237_2713940661988128_2843196598228353024_n.jpg?_nc_cat=104&_nc_ohc=G9STItXrwSIAX_14ooO&_nc_ht=scontent.fman1-1.fna&oh=ab43b8e9952406bd6bf9dc367d89bac1&oe=5EBFEF8E

:D

[Picsiri]

Hope this thread is not dead yet. I need this exact same thing. Why I need it?

I have a database for the things that I want to draw sprites for. I will use a sprite sheet. The framework that I use (as almost all languages) uses 0 indexing. The first sprite can be adressed as 0 and so on... If I look into the database I always have to offset by on in my head.

Other solution would be to write some janky logic (using 1 indexing). As a programmer you may understand the frustration.

I would even dare to say that rendering the indexing from 0 woldn't hurt anyone, so making it optional is unneccessary.