Progress
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:
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)
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,
Dragonflye
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 :)
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
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)