pimathbrainiac wrote:
MateoConLechuga wrote:
samuelroy21 wrote:
Is there support or will there ever be support for tile sizes outside of powers of 2? I'm currently trying to work with 20x20 tiles at the moment.

Sure I'll add it this weekend probably Smile


While you're at it, will you also add support for sprites of a size greater than 256x256?


Sprites that size physically cannot fit on the screen. If you're using it as a background or something, it's cheaper to use a tilemap or just split it into parts.
samuelroy21 wrote:
pimathbrainiac wrote:
MateoConLechuga wrote:
samuelroy21 wrote:
Is there support or will there ever be support for tile sizes outside of powers of 2? I'm currently trying to work with 20x20 tiles at the moment.

Sure I'll add it this weekend probably Smile


While you're at it, will you also add support for sprites of a size greater than 256x256?


Sprites that size physically cannot fit on the screen. If you're using it as a background or something, it's cheaper to use a tilemap or just split it into parts.


Spritesheets, my friend
pimathbrainiac wrote:
Spritesheets, my friend

Spritesheets aren't used in programs. They are just images showing different sprites. What? Wink
Spritesheets make data easier to store for animations Razz
pimathbrainiac wrote:
Spritesheets make data easier to store for animations Razz
If it would be feasible, the "spritesheet" could just be an array of zero-terminated, or size-prepended sprites in memory. An engine could be made that could map these sprites to the screen based on something. That would however be a lot of work for mateo and take a lot of the fun away from programmers for creating their own rendering engines.
ACagliano wrote:
pimathbrainiac wrote:
Spritesheets make data easier to store for animations Razz
If it would be feasible, the "spritesheet" could just be an array of zero-terminated, or size-prepended sprites in memory. An engine could be made that could map these sprites to the screen based on something. That would however be a lot of work for mateo and take a lot of the fun away from programmers for creating their own rendering engines.


It's literally changing an arbitrary, hard-coded, limit in the conversion program. It has nothing to do with what's up on calculator. Spritesheets are just sheets of sprites, and in storing the sprites a specific way, you can animate by changing the location of the blit on the spritesheet. I think you may have misinterpreted what I was saying.
Spritesheets are very silly by design, because you still have to take the sprites from the image anyway. This is why a 'sprite' is a single image, which allows you give it a name, and a way to actually use it in your program. Unless you want to do the actual extraction on each of the individual sprites in the spritesheet during runtime, which is something that simply doesn't make sense.
Agreed; that method is very much slower than simply storing individual sprites and using them when necessary.
You're far from being the first person to request support for sprite sizes greater than or equal to 256 width or height Smile
However, as you know, this requires using wider, less efficient data types, and can be worked around easily by using two calls to the existing sprite routine when you really need wide sprites, or by using a tilemap engine when that applies.
pimathbrainiac wrote:
MateoConLechuga wrote:
samuelroy21 wrote:
Is there support or will there ever be support for tile sizes outside of powers of 2? I'm currently trying to work with 20x20 tiles at the moment.

Sure I'll add it this weekend probably Smile


While you're at it, will you also add support for sprites of a size greater than 256x256?


I'd say probably not.

From an API standpoint, the sprite structure would have to be changed, completely breaking compatibility with old libraries and tools. And from an implementation standpoint, not being able to fit each dimension in a single byte would make all sprite routines slower/larger/more annoying to implement. When weighing these against the seemingly very small need for such large sprites, supporting them doesn't seem worthwhile.

Out of curiosity, in what context do you want a sprite with a width or height of at least 256?
MateoConLechuga wrote:
Unless you want to do the actual extraction on each of the individual sprites in the spritesheet during runtime, which is something that simply doesn't make sense.
This actually makes sense, on the contraray, but its uses are limited. The main use of tilesheet support is that it speeds up the process of porting old hybrid TI-BASIC games, as well as HP Prime games considerably and it can make it easier to develop games for both CE and xLIBC/HP PPL at the same time. xLIB, xLIBC and HP PPL all uses tilesheets, so as a result, if your game has 100 different tiles, then you don't need to split each tile into different files one by one and you have less code rewriting to do.

However, it's unknown if implementing sprite sheet support in the C SDK/Libs would take more effort than rewriting said BASIC/PPL games or vice-versa. If it takes too much effort to implement such feature, then you might be better off creating a tool that can bulk-separate an entire tilesheet into separate files instead.
While xLIBC uses sprite sheets for creating sprites on a conceptual level, the actual structure of the sprite data inside appvars is just sequential tiledata. I think this is the distinction that Mateo was referring to.
Can't wait for custom tile sizes! Thanks, Mateo, you're a lifesaver!
Wait, so did you mean last weekend, or this weekend?
samuelroy21 wrote:
Wait, so did you mean last weekend, or this weekend?

Sorry about the wait Smile Custom tile sizes are now implemented; along with a fix that might fix some rare bugs, who knows Razz

Libraries: https://github.com/CE-Programming/libraries/releases/latest
Toolchain: https://github.com/CE-Programming/toolchain/releases/latest
Danke!
Documentation of the toolchain goes quite well, if anyone has anything that they have questions about, would like to see added, or anything else, feel free to comment here or on GitHub! Smile

https://github.com/CE-Programming/toolchain/wiki
Global palettes for convpng don't seem to work for me. I used this:


Code:
#CreateGlobalPalette : main_palette
#GroupC            : UT_char
#TranspColor       : 255,255,255,255
#PNGImages         :
otherPalColors
spr_f_maincharad_0
spr_f_maincharad_1
spr_f_maincharad_2
spr_f_maincharad_3
spr_f_maincharal_0
spr_f_maincharal_1
spr_f_maincharar_0
spr_f_maincharar_1
spr_f_maincharau_0
spr_f_maincharau_1
spr_f_maincharau_2
spr_f_maincharau_3


#Palette       : main_palette
#GroupC            : UT_tilesets
#TranspColor       : 255,255,255,255
#Compression       : zx7
#Tilemap           : 20,20,true
#PNGImages         :
tileset1


And the log said this:


Code:
Opened convpng.ini

--- Global Palette main_palette ---
Building palette with [256] available indices ...
[error line 26] could not create palette.


(Line 26 was the end of the file).
You have to put #Palette : main_palette after #GroupC : UT_tilesets; otherwise it doesn't know what group it is in. Also, you how do you expect to generate a global palette with no input files? The correct syntax is:


Code:
#CreateGlobalPalette : main_palette
#PNGImages           :
 apple
 dice

#GroupC              : dice_gfx
#Palette             : main_palette
#OutputPaletteImage  :
#PNGImages           :
 dice

#GroupC              : apple_gfx
#Palette             : main_palette
#Compression         : zx7
#NoPaletteArray      :
#PNGImages           :
 apple


As is shown in the documentation Wink
I should really document that on the wiki! Very Happy

Anywho, version 7.1 adds some optimizations to the libraries courtesy of Runer. Smile (If you happened to have downloaded v7.0 within the last day; it has a minor bug with interrupts that has been repaired).

Anywho, please make sure you have the latest version of the toolchain so you can ensure that everything is working correctly! Thanks for the awesome things you all have made so far; can't wait to see what else comes Smile

Toolchain: https://github.com/CE-Programming/toolchain/releases/latest
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3 ... 12, 13, 14, 15, 16, 17  Next
» View previous topic :: View next topic  
Page 13 of 17
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement