View Single Post
Old March 7th, 2010 (5:10 PM). Edited March 7th, 2010 by link12552.
link12552's Avatar
link12552 link12552 is offline
to measure how far we wonder
    Join Date: Dec 2007
    Location: The blue one
    Age: 21
    Gender: Male
    Nature: Calm
    Posts: 204
    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.

    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
    Reply With Quote