View Single Post
Old June 9th, 2011 (4:27 PM).
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 Full Metal View Post
    Implement both.
    For ROMS:
    load bookmarks from:
    standard INI file
    specific INI file ( possibly ) found in the ROM's directory.
    For projects, just store it in the project file.
    ( Use sqlite for your project files? Just a suggestion. Use the BLOB to store sprites )
    Projects would probably just be progromatically reflected xml files (Similar to how visual studio makes a project file)
    -but then sprites would be stored outside the project file... I'm actually not familiar with sql, I might have to look into it... or just ask you...

    Anywhoo, I've already finnished the new nsl system, now *.nslx, using reflection, and it works quite well.

    It looks something like this, in fact this is it:


    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;
    namespace NSE_Framework.IO
         public class SpriteLibrary 
            byte[] nslx = {1,0,0,0};
            public byte[] NSLx
                get { return nslx; }
            public List<SpriteSet> Sprites;
            string origin = "GBA";
            public string Origin { get { return origin; 
    } }
            public SpriteLibrary(string Origin)
                this.origin = Origin;
                Sprites = new 
         public class SpriteSet 
            public NSE_Framework.Data.SpritePalette Palette;
            int width;
            public int Width
                get { return width; }
                set { width = value; }
            int height;
            public int Height
                get { return height; }
                set{height = value;}
            public string Name = "Sprite Set";
            public List<SpriteData> 
            public SpriteSet(string Name, 
    NSE_Framework.Data.SpritePalette Palette, int Width, int Height)
                this.Name = Name;
                this.Palette = Palette;
                this.width = Width;
                this.height = Height;
                SpriteData = new 
         public class SpriteData
            public string Name;
            public byte[] Data;
            public bool Compressed = false;
            public SpriteData(string Name, byte[] Data, 
    bool Compressed = false)
                this.Name = Name;
                this.Data = Data;
                this.Compressed = 

    It works like this:
    You create a new Library simply by providing an origin (NSE reads 18 bytes from 0xA0 and converts it to a string)
    Then you create a new spriteset, specifying the name, palette, width and height: and add it to the library.
    Next you create a new SpriteData for each "frame" or sprite with the same dimensions and palette, possibly compress them, and add them all to the spriteset.
    Repeat as nessesary, you can keep adding new SpiteSets to the Library.
    Finnaly export it using the binary serializer.

    So: Library>> SpriteSets >> SpriteData(s)

    Originally Posted by Dragonflye View Post
    I do not know if that was mentioned, but I would hope that it has an INI file, where you can specify the unknown pointer 1 and 2. Because I am a German hacker and would find it much easier if he would do it. The offset must not look for her, you would need an INI indicating where the stop. That would be a great relief.

    And I would be grateful if the new NSE would work with 7-digit offset.
    Betsimmt some things you have mentioned.

    I apologize for the bad English, I'm not very good at it.

    Yours sincerely,
    NSE will support INIs, but I plan on just reading constant pointers from the ROM, thus eliminating the need for you to specify offsets.
    (this is assuming, that moved data has been repointed properly, hence the reason for including them anyways)

    I'm actually, at the time of posting, am working on more than 7-digit offsets.
    When you create a new read object it stores the files size as a long
    Or in regular speech: I'm working on it

    Originally Posted by agentgeo View Post
    I've gotta say that I really like the Plugin System. When I saw the download for the sample, I started writing a plugin right away! Really powerful stuff here.
    Thanks, I'm focusing NSE on plugins.
    I'm actually writing NSE with the same frameworks that you'll get to use as a plugin developer.

    I've finnished the Editor control and the SelectColor control so you can, as soon as I release the next alpha, make some super powered plugins, NSE accelerated plugins :D

    Originally Posted by Meta Paradox View Post
    While NSE 2.X will be the hottest thing in cool (huh?), I certainly will NOT throw NSE Classic out in the dump (hmm... Recycle Bin. :D). NSE Classic is still a good tool on its own, but still, heads up to Link for making an even better graphics editor! :D
    Thanks, NSE classic is in no means going to completely dissappear, it's still one of the best OW editors. I might actually just port NSE classic as a plugin into the new NSE 2.X (yes I can do that, I think so at least)

    But, thanks for the heads up.

    Now some news regarding NSE 2.X's progress:
    • Imports are done (bitmaps, png's, nslx)
    • So are exports (bitmap and nslx)
    • I've implemented, as Darthatron mentioned, Ctrl +/- and scrolling zoom
    • I've figured out how to properlly encode and decode bitmaps, thanks to wikipedia.
    • Now you can import AND export 256 color bitmaps (this includes importing unlz's weirdly formated exports it says it's 256 color but ITS' NOT!)
    • As I've mentioned there are some new controls
    • NSLx format is done
    • Fixed LOTS of bugs
    • more... (Just can't think of it)