View Single Post
  #69    
Old March 7th, 2010, 05:10 PM
link12552's Avatar
link12552
just tired, that's all
 
Join Date: Dec 2007
Location: The not so distant future
Age: 18
Gender: Male
Nature: Calm
Quote:
Originally Posted by diegoisawesome View Post
Thanks a lot! This is really great, especially now that I know how to work it! XD

EDIT: I have a bug to report.
Whenever I, say, edit the palette number of a sprite from the new table I made, or try to import a sprite library, the program says that an unhandled exception has occurred and that the index was outside the bounds of the array. The sprite looks fine, and imports okay up to the pont that I click save...

Come to think of it, it only happens when it tries to write anything to the ROM.
I just noticed this as-well. NSE wants to save information to an index that is calculated incorrectly when in sprite table mode or when indexing past the calculated sprite count. This can be seen even by looking at what NSE thinks the sprite number is. Sometimes it will even show up as a decimal.

Quote:
Originally Posted by shiny quagsire View Post
Maybe for the nsl format you could use zip compressing with images in it, then encode it in a certain format to prevent unzipping.

I've made an encoder for files, so I can probobly help with that, except I only program java and C#.
NSL files are currently formatted as such:
  • Source location or author, followed by a ":" x char(s)
  • Palette in GBA format followed by a "#" 64 + 1 char(s)
  • Image data for each frame in the GBA format but reversed for drawing speed, y char(s)
Final size: x + y + 64 + 1
I guess if file size was an issue, I could store all information in hex, ideally cutting file size in half, but currently a 9kb file doesn't seem like a problem, I'm not worried about people decoding the NSL, obviously seeing how I just explained it, and the NSL is relatively stable
__________________

Last edited by link12552; March 7th, 2010 at 05:54 PM.
Reply With Quote