Woah! I have been great
honestly, you're a crack =D
thank you very much!
Greetings!

Nice hacking link12552!

This is BEAST!!!!! You should make it so we can edit title screens and tiles... or is that too much..?

This sorta look like gimp,or paint.net,due to the look,but either way this looks pretty good,at least we now have a transparent layer,so we know what colors need to be transparent.

Well, while you're doing things with plugins...
How's a tilemap editor sound?
( I would write one, but I haven't a slightest clue where to start as far as making a plugin goes. { Feel free to point me in the right direction? }

The plugin system will be interesting.

I might look into developing a few plugins.

Anything really is possible now.

This is actually easily possible in the new NSE.
The drawing and Lz compression functions could make this really simple.

Although I should add access to creating new editor forms from within a plugin... I'll add that sometime really soon

Both of you, that's awesome.

-and for all developers

I'll attach the source code to an exmaple plugin for you to look through.
Most of it is pretty straight forward, I even commented the steps.
When making a plugin, you get access to ALL of NSE's core functions by referencing the NSE Framework.dll.

Best of luck, and please ask or PM for help and suggestions
(Even things you would like to see added to plugin support, I allready metioned how I have to add access to the editor form, the one that shows up after you navigate)

-Again best of luck

p.s. today's my b-day (I'm 15 now ), so it might take a couple of days fo the next update, especially with finals.

Well, happy birthday!

I saw NSE a while back, but this like, NSE 1 on steroids! Great job, I'll be sure to try this. And it gives me an idea...

Whoa: I'm switching from Overworld Editor RE immediately! Nice job!

Awesome man, Awesome. I'll be sure to use it once I officially start hacking again...
EDIT: Ok how do I find the sprites to edit them? I used to be able to do this in unLzGBA when I first tried it but I must've forgotten... I'm using a FR ROM btw.
EDIT2: Nevermind, figured it out. Are you gonna make it so that we don't have to know the offset and we can look up the image number like in unLz?

Wow!
This looks good! I always used you NSE1X for my overworld editing now it can do so much more! <3
Good work Link (trying out now) xD

Oh... My.... Arceus....

This is looking awesome so far, you sir deserve a reward.
On another note I shall be checking back in every so often to view progress.

Yep, currently you have to use the naviagtor and provide the offsets.
There will be somthing similar to unLz's naviagtor for lz compressed sprites, maybe in a plugin (wouldn't be too hard).

The big plan is to bookmark Every Single Sprite (or atleast the important ones), so you'll never have to know an image number ever agian, you'll be able to just pick it from the bookmarks window.
The bookmarks are going to be allot more complicated than the old NSE,
I expect there will be reading of rom pointers and tables involved.

Thanks, but play gentle it's just an alpha :D

I'll be sure to keep updating, and expecting a reward!

---------------------------------------------------------------------------

Now a question for everyone, slightly more so towards developers, should I implement a solution/project system? (Similar to Visual Studio, Dreamweaver and other large programs)
-this would replace the simpler "open rom" that everyone is used to with a more complicated "open project"



Pros:

• NSE could keep track of every sprite you've ever eddited
• You could leave sprites unfinnished (they would be saved to the project file), and save them to the ROM when you have finnished (means less repointing)
• NSE could track and adjust to any pointers that have been changed(Means that if you repoint ,say charizard to 0x900000, the bookmarks would automagically reflect this change)
• Bookmarks would be stored in project files, along with other data.

Cons:

• No more simple "open rom"
• You won't be able to easily have multiple copies of the same rom
• You have another filetype to worry about, and whenever you wanted to edit you'd have to use the project file
• Redistribution of projects would be weird
• Project files and ROMs would have to stay in the same folder.

Input, suggestions, ideas?
-I kind-of need to decide before continuing

-link12552

I guess for now I'll just use unLz to look up the offsets.

As for the question, there ARE more Cons than Pros, so I would say no, unless the pros turn out to be WAY more prominent than the cons. Personally, I prefer it simpler, and no more simple open rom is one of those cons. Plus, I don't plan on doing any repointing, so that Pro would be irrelevant to me.

Long story short, I personally say no.

I believe I can help. I still have my old bookmarks file, and I've added a bunch of stuff. Weather, the each sprite for the intro scene with pallets, the Intro Message pikachu, and some others like the graphic for Surf.

Also, I cannot wait for the ability to open an editor window from a plugin. That's when I can really make some good plugins.

So how do we bookmark the sprites? Or is that unfinished?

Key features this is missing:

• Undo/Redo
• Scrolling Zoom - in fact, the entire idea of Alt+Up/Down is annoying. You should stick with the standards here (Ctrl++/-)
• 9-digit offsets
• Dock-able palette
• Palette editing
• Multiple palette switching
• Easy option to load full ROM

Also, the way the drawing works seems off. It should redraw the image from the data every time, rather than just drawing new pixels - when fully zoomed in you get little strands that don't get over written. It looks weird.

The concept is great, though. If you need any help with anything, let me know. I've been programming for 6 years and study it at university.

That's excelent, a better bookmark system will certainly be a major feature.
I've also finnished the ability to open an editor from within a plug-in. I actually converted the editor into a controll that can be placed on a form, and have it's properties changed like you would any controll.
The way I have it set up, there is a host command you can call, that will set the current editor for NSE to use.

I might also allow access to referencing the NSE.exe, so you can create or use any form you want (Editor Forms, Naviagtors, Dialogs, really anything you see in NSE)


Currently you can't, I need to know how people wan't me to handle files (projects or how it's been, see my previous post) before I can work on bookmarks






-I'm certaintly going to add Undo/Redo, hopefully more effecient than NSE Classics's old text-based system, and I originally wanted to do Ctrl + & - for zoom, but I also wanted to use the MainMenu shortcut property (which doesn't allow this for some strange reason) I'll see what I can do though... I'll also try to add scrolling zoom.

-I'll soon add support for offsets up to whatever the ROM's physical length is.

-A dockable palette would be a great idea

-As for palette edditing, I'm working on it, I'm going to hopefully do something with a color wheel based approach I've been working on.

-Palette switching is something I'm working on, loading palettes for edditing and importing from indexed images, .nsl (I'm working on a new format), and exported palettes from VBA (should make 256 color easier)

- I might will make a plugin to work like Tile molster, really the only reason I showed that pic of the entire rom opened was to show how fast NSE's new engine is. The sprite class isn't really meant to handle sprites that GIANT)
Now for the pianting interface, I know the bug exists (and it is quite annoying).

Now for the 0.5f px strands, the problem exists with the scaling function in .net (NSE draws a regular sized version and then up-converts it), but I seemed to have solved it, so in the next update it should be fixed.
I don't want to redraw the entire sprite again, because it's inefecient to A) redraw everything B) lock the bitmap to memory for edditing.

I wil be sure to ask any questions that will occur, so thank you


-Any other suggestions, comments, ideas, please 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 )

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

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.

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

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)


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

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

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)

Feel free to ask me about SQL any time, by no means am I an expert, but I got my basics covered.
SELECT * FROM TABLE ( WHERE X = Y )
the * can be either a '*' or a comma delimited list of fields
TABLE specifies which table to choose from the database
The ( WHERE X = Y ) is completely optional, and basically is a filter, if field X == value y then go ahead and select the entry being evaluated.
( A database looks a lot like an excel spreadsheet in my world, btw. think of a page as a table, field as in column, and entry as in row )