nesdev.org

I have been talking with the developer of NESICIDE and I may be partnering up with him and trying to get together and push development along. I have some questions for you guys to see what changes and improvements can be made to make it more useful. I'll list some ideas I have and see if anyone has any comments, or any of their own to add.

First off, what I would like to see is to change the UI to libGtk so it can work with windows (native UI instead of the default 9x style UI), linux, and mac. Since Gtk is anti-mdi, it would require the UI to be a bit different. Instead of a big window with everything in it, it would have a main window, and the editors would be in their own windows (I like this anyway as I have multiple monitors). What I was thinking is having the treeview navigation and such (the left side of the app) being the main window. The toolbars will still be at the top of this window, along with the main menu.

I'd also like to make it use all of the CPU cores to maximize performance, since NESICIDE does a LOT of stuff at once when running the emulator.

The compiler and linker should also be built into the app so that it can compile/link in real-time and give useful information like page boundaries in the code editor (VERY important), as well as having real-time warnings for instructions that have cross-page situations that add an extra cycle to the execution of said instruction. We could add other features as well such as syntax highlighting and in-line help.

And finally, I'd like to separate the emulator out as a module so that it can both be embedded in the IDE, as well as run separately.

These are just some ideas I had. If anyone has any comments of their own (improvements, features, annoyances, etc) please reply with them.

Thanks!

I think it a matter of personal preference but if you go with a UI that is like gimp (multiple windows), count me out. I hate that like hell. I prefer a multi-tabbed environment like visual studio with docking since it feels more organized to me.

But like I said, maybe other people don't mind about this.

No, your input is good. Some people like me hate the tabbed interface, others hate the multi-window setup. I personally use multiple monitors and I simply don't like 60% of my screen being wasted with whitespace.

I will look into a way to choose between MDI and SDI modes; that way everyone is happy.

Having said that, do realize that some things WILL be tabbed (like the code editor will tab the source files) even in the SDI style layout.

[edit]
Thanks again for your input, now you will be able to switch between the two.

essial wrote:No, your input is good. Some people like me hate the tabbed interface, others hate the multi-window setup. I personally use multiple monitors and I simply don't like 60% of my screen being wasted with whitespace.

I will look into a way to choose between MDI and SDI modes; that way everyone is happy.

Having said that, do realize that some things WILL be tabbed (like the code editor will tab the source files) even in the SDI style layout.

[edit]
Thanks again for your input, now you will be able to switch between the two.

Switch between which two? I originally developed it with SDI because I wanted it to be like Banshaku described. However, essial, as you have seen in the latest, I have been creating break-off dialogs for the different viewers, very similar to FCEUX DSP.

I would also like it to have an option to open in "emulator only" mode if it is used to open a ROM file, with basically only the TV visible. A menu option would explode it into the full IDE if selected, or back to the emulator-only mode [with of course prompting to save any open project first].

OK, I see your point. How about I use Qt then, it supports said pullapart windows, which I'll be happy with. Here is an example (note that it looks native when ran in windows, and I wont use ugly huge icons like that..):



And no problems about the EMU only mode, but wouldn't it make more sense to have it as a separate executable in case someone wants to run the EMU by itself? We can still support the "hide designers" style option, but I think we should also have the stand-alone as well. It will obviously include the exact same code, only the debugging hooks would be #ifndef'd away to speed the emulator up.

For the record though, I HATE SDI...

Here are some screenshots:


Keep in mind that that will NOT be the final welcome page, I just put that there for testing purposes. I figure we could have news, user posted projects, tutorials, etc there in the future.

I see. If you can dock back the content inside the main docker and at a later stage make one of them "float" so you can use in another monitor: I have no problem with that.

In the case of gimp, everything is a single window (if I remember well) and I always hated that.

For my map editor, you can dock everything in one frame or you can let them float if you find it useful. If you check the free component dockPanel Suite for dot net you will see what I mean.

Yes, all of the windows are dockable just like in visual studio.

Just a little update:
(image removed)

Still lots of work to go but progress is progress nonetheless! And fyi, the rendering is done in OpenGL so it is super fast.

Seems to move forward. If you do decide to go with ca65, one thing that will make it hard at first is all the scope you can define. If you make something like intellisense, it may be hard at first to find the right code (module scope, function scope, user defined scope in a module, nested scopes etc) and with the include you can put here and there.

But if you can do it and show at anytime the symbols for a specific scope: that will be great. Online help for all the ca65 command and instructions and that would be nice. Of course, once you can "remote debug" in your emulator with your code, you're in business.

This is quite a huge project but it someday someone can pull it out, that would be incredible. I thought about working on such a project but have no time for working on a simple home brew these days so I gave up on it. I would still think about a way to make it plug-able in some way to support other assemblers in the future since everyone have their own taste for this.

We plan on embedding an assembler so that the IDE can be consistent across all platforms. If we ever add support for other external ones we may support some sort of scripting language or something. Whatever the method it will have to be cross platform so that anyone with the IDE can access any shared resource from anyone else.

And yes, theres a lot of features we are going to try to put into the code editor.

Here's a new image of the 'final' chr-rom viewer:


We now have a git page at http://gitorious.org/nesicide. If you'd like to contribute, you can contact us most of the time at irc.freenode.net on channel #nesicide.

May I suggest efnet? It's what the #nesdev channel is on.

Jeroen wrote:May I suggest efnet? It's what the #nesdev channel is on.

That's because nesdev is weird. Most of the OSS apps have rooms in freenode, so that's where we're at

**Update**

Nesicide2 finally qualifies as a cross platform emualtor! I am now in the process of starting work on the designer aspect of the project while chris works on rounding the corners of the emu port. We also have a mac guy who is making sure things are working well on that third platform

It should be noted that the emulator does *not* work off of ROM files. It is emulating based off of the content in the "Cartridge" section of the tree-view. This means it is already ready to be used for custom projects without even dumping a rom file!

Good job so far.

TIP: If you plan on having the mainstream gaming press cover your emulator, it's best to make sure the emulator works with copylefted or otherwise free software.

• The carrot: Wikipedia, for one, prefers screenshots of free ROMs running inside an emulator. (The ideal screenshot would be a free ROM inside a free emulator running in a free desktop environment.) It's also a good way to raise the profile of the homebrew community over the (shadier) ROM hacking community.
• The stick: Nintendo has declared an intent to investigate NES emulator videos for possible infringement.

So how well does it work with LJ65?