I fixed the hidden blocks issue. There where actually two places they where hard coded. One was for enemies and one was for players, I've fixed them both. I haven't gotten to the lifts yet, because I'm working on some other stuff, expect a release later today. (Speaking of which, it'd be nice to get the latest levels for it.)

With the hidden coins moved over one, can you still hop over the flagpole (much to your chagrin)?

Edit:

Hmm, I seem to be crankin' out the releases. You can get the latest expanded patch here. There are some significant changes in this version.

Finally, after much promising, procrastinating, etc. I've fixed the graphics on the ends of the upsidedown pipes. To make room in the CHR-ROM for the new tiles, I moved the title screen into PRG-ROM. (It was actually a lot easier than I expected.)

As mentioned above, the new hidden blocks can no longer be stood apon. The whirlpools (water pits with downward suction) have been disabled. (Do you think they should be turned back on in hard mode?) The castle in the middle of 8-2 no longer generates spurious solid blocks. (I made a new object which is simply the castle object, but it never generates solid blocks. I figured that was the easiest way.) I restored the endless ropes for elevators which where removed as part of the original upsidedown pipe patch (but they'll have to be added to the levels where they belong, so there's no noticable change yet).

I still haven't made all the lifts six tiles wide. The code that handles that is spread out all over the place and after my first attempt messed them up, I backed it all out.

Hack and enjoy.

Does SMBS have a hard mode?  I know SMB has one when you beat it, but should a hard mode even be included if SMBS didn't have one?  I just worry about keeping it true to the original and all.  Also, is the speed of the whirlpools the same (the rate at which they suck you down)?

-Rob

Oh, so the normal run through the first quest is basically identical to SMBS?  The hard mode is just additional stuff being added?

BTW, Starscream sent me a link to the X1 version.  Didn't know if posting a link here was OK.  I can forward to whoever wants it.  I mentioned he should post it, but I don't see that he did.  I haven't gotten a chance to look at it yet, but I'm excited at the possibility of seeing the differences!

-Rob

I noticed that Bowser only throws hammers at Mario in Worlds 6-4 (repeat of World 1-4), 7-4 and 8-4. Why didn't they program Bowser to throw hammers at you starting in World 5-4 (which is a repeat of World 2-4)?

Also, when you play the Primary hard mode (after beating World 8 for the first time), Bowser's hammer-throwing is still relegated to Worlds 6-4, 7-4 and 8-4.

~Ben

Ok, thanks for the info. The reason I asked was that it seemed to me that they could work. So it's a matter of the platforms being aligned to the metatile grid, such that a plaform four tiles wide doesn't line up correctly. It occures to me that the engine could be altered to "correct" this (by moving the platforms 8 pixels), but should it?

I suppose the proper answer depends on SMBS and it's usual practices. Of course, a completely faithful reproduction of SMBSs behavior depends on a number of features not present in SMB or our alterations to date of it's engine. Firstly, there is the matter, mentioned above of SMBS having three independant sizes of lift. Secondly, and perhaps more importantly is that SMBS allows for higher precision in the alignment of inital sprite positions than SMB. SMBS can allign sprites to 8 pixel precision, while SMB only has 16 pixel precision.

If SMBS favors aligning four tile wide platforms such that they end up on even rows, the current behavior is more accurate in most cases. On the other tentacle, if SMBS favors aligning such lifts on odd rows, the idea I proposed above would be more accurate. However, I suppose the entire question is rendered moot if all platforms are to be six tiles wide anyway.

Which brings up another interesting proposal. While the addition of new sprites in general is a fairly complex proccess due to two factors, the lack of CHR-ROM space and the lack of frame table space, neither apply in the case of lifts. The lifts are all handled by special renderers and don't use the frame table and would require no additional tiles. A fuller investigation of the requirements to add the mid-sized platforms as first class objects would be needed, but it would probably entail much less work than other enemy additions. (In fact, I belive it'd be signifigantly less work than adding the Red Piranha Plants was.)

Furthermore, even if the mid-sized platforms are not added (at this juncture), if my proposal to shrink the large platforms down to mid-sized ones in primary hard mode (as opposed to secondary hard mode, as standard SMB does, or not at all, as Frantk's patches do) is implimented, the question of alignment is still present. Specifically, if large platforms are given endless ropes and align correctly centered on them, such alignment would be needed for the smaller case to look correct.

To better provide recommendations for these questions, I'm going to look at the SMBS level renders and see what sort of information I can glean about the usual positioning of platforms in SMBS and the usage (or not) of endless ropes. Some more concrete information (as opposed to my hazy recollections from months ago) will give some better guidance as to how to proceed.

As for the endless rope itself, it's much easier to give it it's own object, rather than special case the balance platform rope. The endless rope has it's own init handler which was not overwritten by the pipes patch, only it's entry in the level decoding jump table was overwritten. To re-enable them, all I had to do was add the init routine to the table. To add them as a special case of the balance platform rope would require alterning it's routine, which seems to be unneeded work to me.

To provide more detail on the space issue I mentioned earlier, it's a matter of level format ID space. The various types of SMB level objects have differing ranges of IDs based on thier usage of the seven bit space allocated to them. The following table provides the full details.

Object Type     ID Range  SMB Usage  SMBS Usage (current)

Small Objects   16        12         15
Large Objects    7         7          7
Special Row 12   8         8          8
Special Row 13  64        12         13
Special Row 14  n/a       n/a        n/a
Special Row 15   8         6          8

As you can see, SR 13 has the most free space. (In fact, it's possible that the ID range of the row could be expanded to 128 as one bit is specifically set to one. However, the full signifigance of that bit is currently unknown to me, so that may not be the case.)

In light of that, putting the endless rope on SR 15 may be somewhat wastefull. If at any point in the future we wish to add an object with a size feild, the use of the last SR 15 slot for an unsized object (the endless rope) may be imprudent.

Oh dear, sometimes I think I have entirely too much knowledge of SMB's internals crammed in my head. I wonder what got displaced to make room for it all. Proabably bits of my sanity =_=

So, does no one want the X1 version?

-Rob

Rob,

I would like screenshots of the X1 version, just to see if it's any better than the PC8801 version.

~Ben

I definetly want the Xl version. (Or any other version for that matter. I'm still hoping to get a clean dump of the disk image. If anyone has a PC88 version which has an MD5 signature of something other than 94a92e15ad909b7510dccca26128b54c, please let me know.) Hopefully the level format is similar and I can reuse the level renderer codebase to generate a comparison set of images.

I appologize for not responding to your offer earlier. I was preoccupied with other stuff. I can't recall off-hand the RHDN rules on linking to ROMs. (Unlike many forum users (not anyone specifc, or even at this site, just in general) I read the rules when I joined, but the details escape me.) I know that requesting links to ROMs in the ROM hacking forii is frowned apon. (Thus my request for a clean disk image may be taboo, but I think there's some leeway.) However, (unlike many sites), ROM sources is an allowable topic in the General forum. (There's even a dedicated thread, so I hear.)

What I suggest you do is re-read the forum rules. If if's absolutely forboden (that is a word) to post the link here, go to the thread I mentioned above and post the link there. If posting ROM links (as opposed to requesting them) is allowable in the hacking forums, post the link here. I'm not the only one interested. Early in the thread, there was some interest in the Sharp version as well. One member in particular (I can't recall who and am too lazy to look) seemed to be a serious X1 fan and was disappointed to find that the image wasn't in his extensive collection.

In either case, PM me the link. It may be a distraction from the work at hand, but I'd really like to point my hexeditor at the port. BTW, (OT) can anyone recommend a good un*x or cross platform Sharp X1 emulator?


Sure, I can do that. I haven't really been keeping up on the source releases. This is because the intial one seemed to generate a lukewarm reception at best. Other than an aside concerning the custom level extractor, it didn't seem to garner any enthusiasm. Furthermore, there haven't been any requests for a second release until yours. (However, as I get my web hosting from my ISP, I have no download statistics, so I have no idea how many people actually grabbed the intial source release.)

Please be aware that the build enviroment is somewhat involved (especially for a Win32 user; un*x users, including those running OSX should have an easier time). The build process is automated using make. (GNU make specifically, but it should be reasonably portable across make variants, AFAIK.) Honestly, as a un*x freak, I (personally) can't imagine building a complex software project (and SMBS for NES has become moderately complex) without make (or an equivilant, like autotools, or Python's distutils), so I've got no sympathy for those without a proper dev enviroment. "Thems tha breaks", as they say =_=

In addition to make, there a number of other dependancies for a fully automated build. The primary ones are as65 and ld65, which are part of the cc65 suite of 6502 (and relatives) development tools. While not the most popular NES assembler, as65 is (in all likelyhood) the single most powerful freely availible and portable 6502 asm ever; Thus, it is my tool of choice. (As a side note, I was turned onto it by the famed (at least locally) Disch, who used it for his re-buildable dis-asm of  Final Fantasy, my other (on hold) ROM hacking pursuit (at the moment).)

Beside the assembler and linker, you'll also need some standard file manipulation tools (cp, rm, dd). However, copy and delete on a MS system should work fine; Provided you edit the Makefile. dd is a bit trickier; I don't know off hand a Win32 equivilant, but I imagine any serious ROM hacker has something that's roughly equivilant. Additionally, you'll need a command line IPS patcher and (optionally) an NES emulator (for testing).

Finally, as you're already aware, the level extraction tool requires Python. While a final source release will likely include a Win32 stand-along executeable (created using py2exe), probably as a seperate package, I haven't gotten a proper cross-compilation eviroment set up at the moment (I don't run Windows and won't).

That's a pretty heavy list of deps, but there are two cavetes that lessen the burden to the technically skilled. (Which one ought to be if one's interested in the source code.) Firstly, all that stuff is only needed tor an automated build. For most of it, a manual build could be accomplished with whatever ROM hacking tools one has on hand. Secondly, all the tools are open source and have been ported to all major (and many minor) plafforms, so they are readilly accessable.

The build processe has changed slitghtly since tha last release (streamlined mostly) and, as such, I should update the README, which hasn't been touched in weeks (or longer). Additionally, I've decided on a license for my personal source code contirbutions (i.e. the legal parts) and so should update that aspect of the documentation as well. While I'm at it, I may as well add a mini-HOWTO for building the package manually. All together, that entails a fair (but not major) ammount of documentation to be written. As you've requested a source release, I will provide one, but don't be surprized if it takes me a day or to to clean things up.


While I, clearly, can't speak for Frantik, I'm not sure he's got Py and is capable of generating level packages. That said, given the demand, I will release a level package coincident with the source package. (As I did shortly following the first one.)

Currenlty, there are (though it's not readily apparent) three "current" versions of the levels. The first (and primary) is those contained in the latest patches released by Frantik. Second is my own (very very minor) adjustments to those levels (well, one level, actually), which are present in the latest expanded build. Finally, there are any changes Frantik has implimented since the last release. (Although, those can be ignored as I doubt anyone will see them until they're released.)

When I do the source release, I'll include mine; Unless a new version shows up first.

Well, that was pretty random, and (I'm sorry) really long (and, probably boring as well). G'night!