banshaku wrote:I'm not sure if you can mix asm/c and other things with it for a ca65 project?
while typing, this went from being an answer to your question to being a more general review, to being a plea for the thing i think needs improvement the most. If not interested, skip reading halfway.
the tl;dr is you can't out of the box, but might be possible if you're willing to put some work into it and accept the framework of both the tool and the codebase.
EDIT: Apparently, you can write plugins in C# and add them to a plugin folder for nesmaker. Here's a resource that helps with that. http://joshuafallon.com/nesmaker-plugins-part-1/
That may change the outlook for some.
You can look at the neatly organized and fairly well-commented codebase, and the functions and macros are easy to browse because of appropriate naming. But i'd say the tool UI itself is not designed to be a general project organizing solution for any other code base than the one included and things you add or modify yourself that will work well with the mother engine. It enforces some fundamental design decisions and if you override them by writing code and structuring data differently enough, the i'd argue the point of the tool GUI sort of gets lost (quick level, object and assets editing, file organization and graphically assisted conditional assembly).
You can problably translate the code base to ca65 syntax if you wish and work from there, but there may be some caveats since the linker works quite differently with ca65 (automated) than with asm6 (manual).
You can very well code your own "modules" (basically a modular set of rules for the game) to jigsaw into the baseline engine.
It's really great for trying out ideas and producing results quickly. That way they won't stay in your "for later drawer" as much. Besides being able to go from an idea into something of a game quickly, You can kind of view it as one big interactive nes programming tutorial, which is awesome. You can look at one function at a time in a functioning game and modify it or its trigging conditions to see what happens.
I can vouch that it is pretty easy and fun to set up a project with NESmaker. I haven't been able to spend as much time with it as i'd like, but you can quickly have it do things that doesn't seem obvious at first glance even without code modification, like for example sprite animations with different frame durations and the like. I've even used it to try out animations in non-nesmaker projects just because it has sometimes been quicker than mocking them up in photoshop or writing the code to have some animation cycle on-screen by hand.
As far as modifying and adding your own code goes, that's pretty easy too. Modular code snippets + an interface that organizes it all is great for managing code assets.
Managing code is easy and transparent. You can quickly find the thing you're looking for in- and outside the interface and edit away. There are some things though that if you wish to replace, the GUI tool won't work for you any more.
Managing data and assets is.. a bit limited and not as transparent. A lot of it is baked into the project file, as opposed to creating a visible subfolder system of individual files. You can import and export certain things (such as palettes to clipboard and graphics from .chr binaries and to .bmp files) through the interface, but dealing with stuff such as data tables outside the interface is hard and time-consuming because it obfuscates where everything actually is. Some of the stuff needs to be string-searched for in the packed project file. Visual representation of modified assets is unfortunately not as robust as i would like; you will run into unhandled exceptions this way. And i find myself wanting to have a look at the data as text a lot to 1) get a better look at how it actually organizes things, 2)attempt editing it free from the restrictions that the editor imposes.
If there's a weak point that effects the creative output unnecessarily and that really concerns me, i'd say it is missing a properly game style-agnostic metatile system and how the lack of it is forced on the user through the GUI. The big advantage of not having one is the very direct approach to constructing the building blocks of a level. When creating tile assets*, you pick an even tile offset on a portion of the chr table (the UI will quantize your click into an even ID), and it picks the following tiles for you, relative to that offset: $00, $01, $10, $11. That makes for a super-easy interface that everyone can get at the very first glance.
But the interface also gets in your way if you decide to do something more versatile (ie. 4 freely definable tile indexes per metatile). Currently, cons are:
-You can't reuse a hardware tile in several meta-tiles.
-You can't pick an odd-numbered offset (except if editing by hand in a hex editor, but then you sort of lose the point of a GUI. I just found out that the GUI can't handle this properly, so the option left is patching your ROM after each build, or searching and replacing and then reassembling the text file).
-Most noticably, the number of unique metatiles is capped at 24 uniques per game screen (again you can enter any index using a text editor). Metatiles have variable size from 2x2 hardware tiles to 32x32 hardware tiles, in steps of 2x2 increments. So you can technically have more metatiles, but they will contain the same 24 basic 2x2 patterns.
Silver lining: Beside the "fixed relative index metatiles", up to 4 rows of tile data are dedicated to path-drawing which dynamically can create 4 different fill-tile fields with automatically drawn borders. With this you can make clouds, canopies, mud, ponds, etc. The fill uses one tile for the fill closest to the border, and another tile for "deep" fills. This helps alleviate the problem with the metatiles greatly. But it also decides a very specific style of level construction for the level designer/artist. You'll quickly run into limitations such as not being able to make paths within paths without creating borders, or adding a unique metatile detail to the fill or border without creating a new path-generated border around it. I found this a tad frustrating, but it can be somewhat worked around outside the GUI.
You can see these limits in the showcase. Some of them are doing really impressive things within those limits, but it is still apparent that the number of metatiles with unique content/arrangement is quite low. You get 24 unique two-by-two:s and 4 dynamic fill fields with border tiles per screen and bank.
All this sounds a harsher than i would have liked to put it, but i'd rather do away with the current metatile system altogether, except the paths. Paths are pretty cool for some game styles, and you can disable them comfortably if you don't like them; potentially freeing up that space for more unique metatiles.
2x2, fixed-size, 6-byte metatiles (1 byte per tile offset/ID + 2 properties byte, since NESmaker engine assigns properties per metatile) would be a slightly more indirect method as you need to pick each of the four ID:s for each metatile individually, but it is just as easy to get into, while both allowing for creative freedom pretty much exponentially, and more varied end results, and producing a better tile usage economy. The drawback is the expanded asset size. There may need to be a cap to how big a metatile table is per bank, depending on available space. To get to the same number of unique tiles as the existing system (24), you'd need to reserve just 144 bytes. And you could still use the tilespace in chr-ram more efficiently. Any single addition at 6 bytes each would be a well-needed improvement. Plus you could assign any currently loaded tile from RAM, not just the 96 designated "background bank" ones. If you for example don't need all those text symbols, you could use that space for commonly used background graphics across banks, and so on. The liberty with one such system is not just that you get more unique metatiles, but also a bigger artistic freedom on what to put in them and less hassle with pre-organizing your tileset to match the current metatile system in 2-by-2 sets.
It'd require extra work on the GUI tool beside putting the metatile system into place since it wasn't designed for this, but if there's one single area where i think the tool and codebase needs to improve, this would be the one. The rest is great.
*asset is NESmaker terminology for, among other things, a metatile + attributes for the same.
**the second (paths) is easy enough to disable if one really wants to.