Almost all of the NESmaker codebase is easily visible. Some few sections of it are gui generated such as most of the enumeration and init values for some of them. Also things like key input handling and AI sequences. But i can see the practicality of it. I wouldn't blame the gui for hiding code. There's even a built-in editor with highlighting, which is useful for quick edits or if you don't care for installing a 3rd party editor.
Things that i think do get in the way of hand modifications are:
-code is modularized into too many, too small text files. Most users are windows users and windows search is not suited to this style of code organization. Text search is off by default (i'm assuming for performance reasons). Rather than rebuilding my search index and restarting, i use a 3rd party search tool to mitigate this problem. I didn't feel like i needed one until i started modifying the NESmaker codebase.
So, i ended up with maybe 40-60 tabs open at any time for one project. If you close some of them down you'll have to search for them again sooner or later. I wound up with organizing some of them in notepad++ and some in sublime for quicker/easier to remember browsing.
Things like tile and AI behaviour obviously need to be modular, but i'd go as far as to organize texts per bank elseplace if it was me. My first impression was the opposite; that the modularization made for easy browsing. But after half a year with it, i found it more bothersome than convenient.
-numerous unused text files with previous versions of this or that function laying around, or unused code within a file. Sometimes you find yourself modifying the wrong version. It's hard to keep track of what exact file is linked where and when. Some cleanup of unused code is in order.
-overuse (to my taste) of macros. hides away what is actually happening behind cryptic labels and argument passes are sometimes without comments. Some of the macros are too large to be useful as such. It sometimes hides bugs from plain view, or eats space where a subroutine would fare better.
Especially the "rendering objects as both BG and sprites" might be not possible with the engine.
yes.. there's no support for 8x16 sprite mode (a reasonable tradeoff), and it's tough fitting the extra tiles otherwise needed into the background chr table with the current direct metatile scheme. Furthermore, you can't conveniently disable individual metasprites (ie detatch collision position from sprite position) for an object. best you can do conveniently without mods is use a 1-tile, no-pixels sprite for an animation.
Anyway... i can't for sure tell if the engine has been modified or if it's all clever use of the preexisting pieces. Screen transitions look more stable than what the vanilla code allows. In any case, good work!
supercat wrote:I found the "physics" confusing with regard to to what can pass through what. For example, in the first level, if the left block is pushed south, it gets blocked without moving far enough for the vertical face to be obscured by the wall, but if pushed east it will not be obstructed by the bottom block even though its face is obstructed by that block.
The answer is that you can walk behind sprite based objects, but not background based ones. NESmaker allows for walking behind background, but the handling is minimal. You're manipulating the sprite object as a whole, rather than individual component sprites, for one thing, meaning you need a fairly big area of non-solid pixel to not look glitchy. I made a quick and dirty replacement for the "behind tile" script for increasing the fidelity on the y-axis but it's only a solution to some particular situations. - it wouldn't solve the current southwest/east corners in this game.