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?
Point taken about screenshots with copyrighted material running. They can investigate all day long though, even with that rom running, it's not illegal in any way, shape, or form. The whole purpose of the IDE is to create home-brew ROMs and programs. It's coded to do this, that is the goal of the IDE. If they send a cease and desist, I will respond with a pirate-bay style reply. The patents on the Nintendo have expired. We do not offer commercial roms, nor do we link or give directions for using said roms. Have at it Nintendo.
Oh, and LJ65 doesn't currently work, but I'll make sure chris knows about it. We haven't spent a lot of time on the tester roms yet, just trying to get the old stuff ported over first. Once he finishes cleaning that code we will work to improve accuracy.
Do you know of any places that have collections of home-brew nes games? I haven't found much on that, we hope to change that with this project.
essial wrote:
Do you know of any places that have collections of home-brew nes games? I haven't found much on that, we hope to change that with this project.
http://www.nesworld.com/homebrew.php is the best list I've found. He even shows which ones work on a real NES of the ones he's tried so you don't go crazy trying to make a broken game work. (Though he never added me as creator of Galaxy NES, even after we exchanged emails.)
essial wrote:
Oh, and LJ65 doesn't currently work
To get LJ65 to work, make sure that sprite 0 is accurate and that the VRAM port is available through $2006/$2007 when the program turns off rendering.
Quote:
Do you know of any places that have collections of home-brew nes games?
PDROMS.de is one, but it appears to be down right now. Another collection is on the
projects and
emulator test cases pages on the wiki. But make sure to test them against the PowerPak or an EPROM cart so that you don't waste time getting
NES-incompatible software to work.
Thanks, and yeah, I plan on buying the $120 powerpak so I can play on a fairly unmodded NES. I have 3 of them (NES consoles), and I figure one can be dedicated to testing nesicide2 stuff
But yeah, I hope when this app is done we can get some devs to join up and actually get some finished, fun games written for the NES. It'd be nice to have compos and things as well -- but that could be just a big impossible dream
There's a lot more planned for this app than is immediately apparent with the screenshots, but of course I'll be posting more as they come -- just with non-commercial games running in them. Actually within a week or so I'll most likely be showing games compiled in the IDE itself anyway!
Kasumi wrote:
essial wrote:
Do you know of any places that have collections of home-brew nes games? I haven't found much on that, we hope to change that with this project.
http://www.nesworld.com/homebrew.php is the best list I've found. He even shows which ones work on a real NES of the ones he's tried so you don't go crazy trying to make a broken game work. (Though he never added me as creator of Galaxy NES, even after we exchanged emails.)
That page doesn't work in Google Chrome, grrrrrr.
I recommend you use Opera.
I was wondering why that page was blank. Oh well, theres other links recommended to me
tepples wrote:
essial wrote:
Oh, and LJ65 doesn't currently work
To get LJ65 to work, make sure that sprite 0 is accurate and that the VRAM port is available through $2006/$2007 when the program turns off rendering.
Quote:
Do you know of any places that have collections of home-brew nes games?
PDROMS.de is one, but it appears to be down right now. Another collection is on the
projects and
emulator test cases pages on the wiki. But make sure to test them against the PowerPak or an EPROM cart so that you don't waste time getting
NES-incompatible software to work.
The LJ65 problem was a migration problem. The game works fine. I had just forgotten to move over the code that replicates the single iNES PRG-ROM bank to both banks in the emulated machine.
Yeah, he has it fixed now. Do note we do not run off of rom files directly. You CAN import roms into the project, but the emulator runs off of the data in the Cartridge object (displayed visually in the treeview under the "Cartridge" node).
Oh and some screenies:
I have a screenshot of the code editor but chris doesn't like me posting half-finished screenshots so I'll hopefully get a shot up tomorrow when it looks nice and pretty.
And a screenshot from OSX:
Cool! The program you have there seems very poorly coded though! It probably comes from an old tutorial or something, and from what I can see I doubt that program would work on a real NES.
If "Start" is the location pointed by the reset vector, this code is hideous. It doesn't wait for the PPU to warm up, it writes the palette with rendering enabled, it treats $2003 as a 16-bit register... it scares me that newbies might be learning from code like this. Where is it from?
Anyway, I'd just like to suggest you use something newer that has been coded by someone that actually knows the NES, and stop propagating these old pieces of broken code.
EDIT: I checked and found out this is one of those godawful GBAGuy's tutorials. I heard they were bad, but I didn't know they were this bad.
Hehe, honestly I just googled nes tutoral and copy-pasted the code over. I couldn't be arsed to write an NES program this early in the game when I can't even open a saved project yet! I just needed some NES code to show off the editor. (I honestly didn't even look to see what it does)
Rest assured once this project is more mature, we'll be writing our own tutorials with code that actually makes sense. It sounds like you would be a good candidate to help us with this -- eh?
I knew you weren't the ones coming up with the code, I just don't like how those terribly inaccurate tutorials seem to live on and on! So I suggested you used something better for future screens.
Now about me writing tutorials... well, I don't think I'd have the time for that! Plus I'm not very good at explaining things in english. Don't get me wrong, I never deny help, and I always try to correct or explain things to newbies here in the forums (as long as the person that's asking for help shows signs of actual effort - I simply ignore "do this for me" requests), but I don't think I could ever write a series of organized lessons, I'm not that organized! =)
I'd be glad to offer my criticism on whatever written material you might come up with, as would many other coders here, I'm sure. If we work together in order to refine the tutorials until they are truly accurate, maybe someday we will get rid of the ghost of GBAGuy's tutorials.
Just to be clear, I don't hate GBAGuy, I'm sure he was well intentioned when he wrote those tutorials, but it's clear he didn't understand much of the subject, and you simply can't teach what you don't know.
Well you can help (or not help) with whatever you want. This is an open source project after all. Feel free to join as content quality control if you would like to; or you can do nothing and simply give encouraging feedback as the app develops
New updates:
- APU (Sound) system ported to libSDL to support cross-platform audio. It's not 100% yet but it's getter there.
- Emulator is now in it's own thread and does not affect the speed of the user interface.
- Source Code Designer has full syntax highlighting and line number counting.
- You can now create, delete, and rename source code items.
- Added setting in project properties to specify the 'root' source code file.
- Started implementation of the source assembler.
- Full load/save support for the project, as well as source code items.
- Started implementation of the emulator debugger windows and tools.
Nice! I like how you guys seem very commited to the project! Keep it up! =)
I, too, am interested to see this project reach completion. Keep it up =).
Just a reminder, we are on irc.freenode.net, channel #nesicide. We currently have 5-6 people on average there; The more people we have helping us test things as we go along -- and giving suggestions, the better this program will be when its done. We support all 3 platforms (and it most likely works on several other platforms too) so pretty much anyone with a PC can help us test.
I plan on building the first beta installers for mac, win, and (packages for) linux on xmas eve, and releasing it first thing on xmas day.
Assembler support is well on its way as shown in the below screenshot. Most of the text you see in the debugger output is just informational while I write the assembler, and will be removed once the assembler is done (I have to see what it's doing right now :p). It already supports line number reporting of syntax errors, detection of labels, as well as opcode compilation for a few parameter types. Hopefully I'll be able to finish up the basic assembler support soon.
Lastly.. I plan on making the macro system work like NASM's macro system. I think that will add great flexibility and power to your code.
Sorry if this is a bump, But should I suggest:
a Sprite Editor with a option to use thier own Mapable/Custom Sprite Formats?
Also a 2-type MetaTile editor for Hacks and Homebrews: SMB-style format and Normal Format, with size options: 2x2, 4x4, 8x8, 16x16 and 32x32 metatiles.
Just so people can use these as easy tools for faster project completion.
What is a "sprite editor"? Is it a tile editor (of which there are many)? Or is it an editor to create (x, y, tilenumber) data structures that get inserted into OAM?
tepples wrote:
an editor to create (x, y, tilenumber) data structures that get inserted into OAM
I believe he meant something like this: meta-sprites and animations. This is as hard to implement as a level editor though, because every programmer uses their own format.
Every word processor had its own format for rich text until everyone standardized on interchange formats: RTF, HTML, then ODF. Likewise, every image editor had its own format for bitmaps until everyone standardized on interchange formats: BMP, then PNG. And every digital camera had its own protocol for connecting to a PC until USB came around and cameras pretended to be hard drives.
Ideally, everyone could standardize on some common format for a display list, and NESICIDE could edit this format. Then anyone wanting a more compact format could write something in Python or C++ or VB to convert it. Likewise, developers of CHR RAM games standardized on a format identical to CHR ROM for storage of tiles in PRG ROM, although some used a more compact representation such as RLE (e.g. Contra), 1bpp (e.g. the font in Jeopardy!), or a more sophisticated codec (e.g. Bee 52).
But like Hamtaro said, it would make the process faster when the programmer doesn't already have their own format. And if the editor and format is good enough, it may even be tempting to switch over to it unless you've already created a ton of data otherwise (which most of us haven't, I'm sure).
I'd considered coding an animation displayer thing, but was still planning on writing the frames out by hand (well, and using macros when appropriate).
tepples wrote:
What is a "sprite editor"? Is it a tile editor (of which there are many)? Or is it an editor to create (x, y, tilenumber) data structures that get inserted into OAM?
#2, an OAM editor, for use with the OAM data structures
(Y, Tile, Attribute, and X are the actual format for NES OAM)
Hamtaro126 wrote:
tepples wrote:
What is a "sprite editor"? Is it a tile editor (of which there are many)? Or is it an editor to create (x, y, tilenumber) data structures that get inserted into OAM?
#2, an OAM editor, for use with the OAM data structures
(Y, Tile, Attribute, and X are the actual format for NES OAM)
So you would like something like a canvas to place sprite tiles onto and move around at-will until you get it "just right" and then the ability to click a button and have it gen a sprite list for you fit for blasting into OAM? If I understand you correctly, then this type of thing is indeed on my list of features. I would also like it to be able to animate so you can test sprite movements without having to code them! Then a 'tutorial' might take such a list of sprite data and 'play' your sprite for you on the emulator with code.
Updates:
- Fixed bug dealing with multiple OpenGL rendering windows.
- Finished CHR memory inspector.
- Began work on OAM debugger.
- Assembler now assembles all single (and no) operand instructions.
Almost made this a new topic but..
NESICIDE2 has officially been used to compiled and emulate a NES application without support for 3rd party tools.
(Simple NES app that sets a color emphasis bit to create a blueish background)
(The first program to be compiled and ran in NESICIDE2)
essial wrote:
Almost made this a new topic but..
NESICIDE2 has officially been used to compiled and emulate a NES application without support for 3rd party tools.
We're on our way...no looking back [except for the occasional copy/paste migration] now! =]
I'm really glad this is going so well!
Good job so far.
My current project makes use of ca65 features such as .proc (labels scoped to a procedure, for local variables in low zero page), .repeat (loop unrolling without copy and paste), and .enum (namespaced constants). How do you plan to handle things like these in NESICIDE's assembler?
And is NESICIDE intended to be lightweight enough to run on my laptop? (It has 1024x600px screen, 512 MB of RAM, 900 MHz Celeron CPU, and Ubuntu 9.10.)
tepples wrote:
My current project makes use of ca65 features such as .proc (labels scoped to a procedure, for local variables in low zero page), .repeat (loop unrolling without copy and paste), and .enum (namespaced constants). How do you plan to handle things like these in NESICIDE's assembler?
I'm planning on implementing a macro system very similar to how NASM works. After that, I'll take suggestions on what can be added to make life easier for NES deving. Procedure-level label scopes will definitely be in. Loop unrolls of course will be in. .enum sounds sorta like a struct system. I plan on supporting enums and structs in the macro system. The assembler is finished, all of the higher level 'niceties' will be the responsibility of the preprocessor -- but I know what you are saying.
tepples wrote:
And is NESICIDE intended to be lightweight enough to run on my laptop? (It has 1024x600px screen, 512 MB of RAM, 900 MHz Celeron CPU, and Ubuntu 9.10.)
Right now, most likely not (in its current state) -- although it seems to run the fastest in linux (compared to Windows and OSX currently). Though right now chris is in the process of importing all of the inspectors, and all of the debuggers are running full steam. Once the debuggers are all ported over (he's done 4 so far), we will toggle the callbacks so that if a debugger is not visible, it will not eat CPU. Aside from that, we run profillers to try to trim down on execution time. If, after we get those debugger toggles in it still runs too slow for you, by all means let us know and we'll work to get things sped up. A celeron processor is pretty weak (regardless of how new it is) due to it's itty bitty cache, but it should be at least usably fast (again, after the debugger toggle logic gets added). If not, we'll have more work to do
One thing I want to reconfirm: is this time the files (source code) will be in clear text? If I remember well, the original Nesticide used it's own proprietary format.
Banshaku wrote:
One thing I want to reconfirm: is this time the files (source code) will be in clear text? If I remember well, the original Nesticide used it's own proprietary format.
The NESICIDE2 project file is in XML. Original NESICIDE used MFC CObject serialization...
Banshaku wrote:
One thing I want to reconfirm: is this time the files (source code) will be in clear text? If I remember well, the original Nesticide used it's own proprietary format.
Yup, the project file is one big XML, all data is expressed inside of CDATA tags. No compression is currently being used. At some point I may have an option in project properties to compress the entire xml file with gzip, but right now it's all open. Although in the near future I plan on publishing the XML specs, I can go ahead and give you the current specs if you'd like (though they will change a bit as we continue development).
Popular revision control systems prefer each translation unit to be in a separate file. But you can still single-file and XML: make the project file a zip file containing an XML configuration file and separate source code files.
tepples wrote:
Popular revision control systems prefer each translation unit to be in a separate file. But you can still single-file and XML: make the project file a zip file containing an XML configuration file and separate source code files.
Honestly the idea is to have the development of games in nesicide2 be centralized in the community, and revision control in-ide is planned. I plan on getting the nesicide.net domain (and hopefully we can get control of nesicide.com since he knows the guy) and setting up a back-end system on there to host, upload, share, download, rate, etc project files. That way the IDE, while usable offline, can be tightly integrated, and people using it will not feel so isolated. I'll have options for protecting the source code via encryption and pass phrases, but this is further down the line of course.
Having said that, the way the project subsystem is coded, it wouldn't be hard to support external files.
[edit]
Also I don't see a reason why we couldn't explicitly add support for revision control systems internally in the future as well. I just want to make this software as internally accessible as possible.
Although we wont have time to put in any graphics designers before the xmas eve cutoff, we will be able to handle graphics. I have already added support for importing binary files, and am currently working on the CHR-ROM bank designer. Basically under the Project/Graphics/ section of the project browser, there will be a folder called "Banks", which you can add banks. You then double-click said bank to open up the bank designer. In this designer, you will be able to import binary data files. In the future you will also be able to add items from the graphics designers (and yes, these designers will have convenience functionality to automatically add a bank and/or add itself to a bank if the user wants it to).
CHR-ROM banks cannot be declared in the source code because the graphics banks must be already completely assembled to allow preprocessor directives that can get the bank number, as well as offsets into said banks for named resources.
About this project: I can't seem to download anything from these GIT servers via TortiseHG. So is it closed until release, or do I have to sign up for server access?
EDIT: I used the wrong type of GIT for windows, so I read and will use MSYSGIT.
Is this project dead, or what's going on with it?
Nesicide2 is not dead, but it's going much slower after essial disappeared, but progress has been made. (essial, if you are reading this, we miss you
)
Anyone can download the source from
http://gitorious.org/nesicide and build it (dev libs for QT and SDL are required). The x-mas version was delayed we still need some kind of installers for linux to be able to release a n00b-friendly package.
If anyone wants to help with the project or wants to know more about it feel free to join #nesicide on irc.freenode.net
Gradualore wrote:
Does NESICIDE currently have the ability to import bitmaps, or, is this a planned feature? There was a bit of discussion in the Art Showcase thread about various custom editors some of us have made that can do this and make it a lot easier to get graphics into your game. I was thinking of suggesting an open source project be created for this graphics editor, but then I thought maybe NESICIDE is going to do this eventually anyhow.
Bitmap import sounds like a nice feature. I think nesicide (1) had some kind of binary import, but .png import wouldn't be that hard to implement either as long as it's only 2bpp... (perhaps even something like
tokumaru's level converter could be added)
But don't hold your breath... nesicide2 has some more important features that needs to be worked on before we can start on import/export functions and algorithms for graphics. But thanks for the idea, it's noted as a feature request
edit: guess i should have been slightly faster with the submit button :S
hyarion wrote:
Gradualore wrote:
Does NESICIDE currently have the ability to import bitmaps, or, is this a planned feature? There was a bit of discussion in the Art Showcase thread about various custom editors some of us have made that can do this and make it a lot easier to get graphics into your game. I was thinking of suggesting an open source project be created for this graphics editor, but then I thought maybe NESICIDE is going to do this eventually anyhow.
Bitmap import sounds like a nice feature. I think nesicide (1) had some kind of binary import, but .png import wouldn't be that hard to implement either as long as it's only 2bpp... (perhaps even something like
tokumaru's level converter could be added)
But don't hold your breath... nesicide2 has some more important features that needs to be worked on before we can start on import/export functions and algorithms for graphics. But thanks for the idea, it's noted as a feature request
edit: guess i should have been slightly faster with the submit button :S
Yep nesicide(1) had binary import for palette/tile/nametable but it was just flat binary. Intent was to extend it to popular picture formats (.bmp, .png) but never got there.
nesicide(2) needs to have the designers implemented to be able to have something to import *to*. The designers are something I keep putting off and putting off [having waaay too much fun with the emulator/debugger side of things right now] but will have to get around to eventually so that I can completely bring over nesicide(1) functionality and sunset it.
Can someone point me to a description of the "nlist" [?] file format or what assemblers generate these? I'm at the point where I am ready to tie in assembler symbol tables to the code browser.
Er, sorry about that. I later browsed the rest of the thread in more detail, and I thought I noticed that bitmap import was already a requested feature. I didn't want to make the conversation redundant.
I've found it really useful in my graphics editor to allow importing of a 256x240 bitmap. It assumes the bitmap in question follows NES graphics constraints (regardless of color depth---it just counts unique colors within the bitmap), and then proceeds to build a palette, pattern table (eliminates duplicates, reports an error if > 256), attribute table and name table. If you're in sprite mode, it builds a bogus attribute table with an attribute for every 8x8 tile so you can build meta sprites instead of backgrounds (I don't support 8x16 yet...). If the bitmap to import violates any constraint, an error is reported. I was going to suggest in the Art Showcase thread that a bunch of people pool their ideas and come up with a new open source project but, then I remembered NESICIDE and thought that feature would be really cool in a comprehensive development IDE.
Gradualore wrote:
I've found it really useful in my graphics editor to allow importing of a 256x240 bitmap. It assumes the bitmap in question follows NES graphics constraints (regardless of color depth---it just counts unique colors within the bitmap), and then proceeds to build a palette, pattern table (eliminates duplicates, reports an error if > 256), attribute table and name table. If you're in sprite mode, it builds a bogus attribute table with an attribute for every 8x8 tile so you can build meta sprites instead of backgrounds (I don't support 8x16 yet...). If the bitmap to import violates any constraint, an error is reported. I was going to suggest in the Art Showcase thread that a bunch of people pool their ideas and come up with a new open source project but, then I remembered NESICIDE and thought that feature would be really cool in a comprehensive development IDE.
Both versions of NESICIDE are now open-source [www.gitorious.org/nesicide] so having people help implement things like this would be great! As I said tho there's work to be done before that in getting the designer framework going. I can see the bitmap import feature going into several designers. First, it would load the palette designers up with palettes it finds, then it would load the tile designer up with unique tiles it finds, and finally it would load the static nametable designer up with the arrangement of tile/palette that it has deemed are as close to the original bitmap as it can get. On the way it *could* try to generate meta-tiles but the whole meta-tile thing seems to be more of a user-preference than a tool necessity. [Aggregation into 16x16 might be the only case where that is not true.] Aggregation to >16x>16 could be made available but not automatically done by the bitmap import.
Those are my thoughts, anywho...need to get three designers ported over from nesicide(1) before it is implementable.
NESICIDE wrote:
Gradualore wrote:
I've found it really useful in my graphics editor to allow importing of a 256x240 bitmap. It assumes the bitmap in question follows NES graphics constraints (regardless of color depth---it just counts unique colors within the bitmap), and then proceeds to build a palette, pattern table (eliminates duplicates, reports an error if > 256), attribute table and name table. If you're in sprite mode, it builds a bogus attribute table with an attribute for every 8x8 tile so you can build meta sprites instead of backgrounds (I don't support 8x16 yet...). If the bitmap to import violates any constraint, an error is reported. I was going to suggest in the Art Showcase thread that a bunch of people pool their ideas and come up with a new open source project but, then I remembered NESICIDE and thought that feature would be really cool in a comprehensive development IDE.
Both versions of NESICIDE are now open-source [www.gitorious.org/nesicide] so having people help implement things like this would be great! As I said tho there's work to be done before that in getting the designer framework going. I can see the bitmap import feature going into several designers. First, it would load the palette designers up with palettes it finds, then it would load the tile designer up with unique tiles it finds, and finally it would load the static nametable designer up with the arrangement of tile/palette that it has deemed are as close to the original bitmap as it can get. On the way it *could* try to generate meta-tiles but the whole meta-tile thing seems to be more of a user-preference than a tool necessity. [Aggregation into 16x16 might be the only case where that is not true.] Aggregation to >16x>16 could be made available but not automatically done by the bitmap import.
Those are my thoughts, anywho...need to get three designers ported over from nesicide(1) before it is implementable.
About metatiles, I also wrote a level editor for myself, and I wrote it to be at least partially pluggable. The level editor always deals with 2x2 tiles as the "smallest" metatile, since this so naturally fits in with 2 bits of an attribute entry. Beyond that, a specific game plugin is entirely responsible for reading a large 2D array of meta tiles and converting it to its own compression format. I suppose one could come up with some generic way of multiply nesting meta-meta tiles as far as the user pleases (I think Banshaku was working on an idea like this for his editor), but sometimes people use totally different approaches like RLE (or a combination). So I mean maybe NESICIDE could give the user a few "basic" things that would work out of the box, but allow them to write their own plugins to perform customized map compression.
*edit* it seems like even a plugin system based on 2x2 meta tiles may not be sufficient in all cases, what about games that have variable height and slopes and so forth? It seems like it would be quite a challenge to create a flexible map building system into an IDE. I guess one could still use 2x2 meta tiles but embed the height information within them. Perhaps the plugins could expose customized properties and data for height or other attributes..etc.
I usually say that it's impossible to make a generic enough level editor, as each game has very specific needs. Even though level maps can be divided in two main groups, grid-based and object-based, every game has different requirements.
Technically you could use a generic editor to place the blocks in a grid and make level maps, that will later be converted to the specific game formats, but what about games with level formats such as the one used in MD/GEN Sonic games, where intermediary blocks are used (the metatiles are used to build larger blocks which are the ones used to build the map)? If you draw freely using only metatiles, without considering the intermediary blocks, the data converter will generate an insane number of intermediary blocks, killing the whole purpose of the compression scheme.
This is why I decided to use GIMP to edit my maps, I can set the grid to the size of any of the blocks (16x16, 32x32, 64x64, 128x128, 256x256) so that I can draw each area with the precision I need. If I need to make a very specific ramp, I'll use the 16x16 blocks, but when I need long flat grass sections I can probably copy a whole 256x256 chunk.
Of course, the problem with drawing with roughly screen-sized chunks, such as your 256x256, is that it makes the maps more repetitive. In fact, some sections in 1-1 of Super Mario Land for Game Boy were so repetitive that the first time I played, I thought I was in a looping level similar to 4-4 and 7-4 of the original Super Mario Bros. I think that's why Sonic 2 for Genesis used chunks no larger than 128x128.
tepples wrote:
Of course, the problem with drawing with roughly screen-sized chunks, such as your 256x256, is that it makes the maps more repetitive.
Depends on how well you design the maps. I don't remember anyone complaining about Sonic 1 or Megaman X.
It's common sense that you shouldn't reuse very characteristic blocks, like Somari does... If you play through all 3 acts of Green Hill in that game you'll get that looping sensation several times. Then again, I think it only has 32 256x256 blocks for all 3 acts, so they *have* to reuse them a lot.
Anyway, it makes sense to reuse long floor sections, a sky with clouds, some generic ramps... There are several sections in Sonic games that are generic enough to be repeated without drawing attention. Plus, you can make the same block look different by placing objects (such as spikes) on it.
Quote:
I think that's why Sonic 2 for Genesis used chunks no larger than 128x128.
Yeah, Sonic games other than 1 and CD used 128x128 blocks, but I still don't think Sonic 1 and Sonic CD felt repetitive at all, specially since many times you just run through the repeated blocks without paying much attention.
I know that such big blocks wouldn't work well for all kinds of games, but for a platformer with large levels I can't think of a better way than using huge blocks. How else would you have a 32768x2048-pixel large stage on the NES? I plan on making some levels that big.
Was hoping for some support in compiling Nesicide2 for OSX 10.5x. I'm not sure where to start. I downloaded the tar file from the GIT repository, created a new directory, dropped the tar in and thats where I am now.
any help would be appreciated.
mattdc wrote:
Was hoping for some support in compiling Nesicide2 for OSX 10.5x. I'm not sure where to start. I downloaded the tar file from the GIT repository, created a new directory, dropped the tar in and thats where I am now. any help would be appreciated.
I'm not an OSX user but if what you are looking for is the following:
You need Qt, SDL [audio] and OpenGL [gfx]
then that is probably about all I can offer. My other suggestion would be to ask on #nesicide on freenode.net.
The project does not currently have distributable binaries.
if anyone else is wondering how to build it on osx, look here:
http://nesdev.com/bbs/viewtopi ... 6991#56991