[Sodaholic]

The MCD is pretty limiting in some ways for mode 2 software, namely in that you have to keep everything that needs immediate access in the program RAM as the only other way to access data is through slow disc reading instead of fast ROM reading, and the program RAM only allows for 256kb of space. Of course, Stealth demonstrated that it was quite possible, but he had to jump through some hoops to do it.

Some questions:

1. If MCD support is added, could it perhaps be mode 1 at first? That would probably require less effort to tap into the MCD hardware as a faster cartridge game than to restructure the program to squeeze it into 256kb chunks?

2. I'm no programmer, but am I wrong to assume that 3K would be a huge chore or even impossible (without significant mid-level load delays) to port to MCD? I seem to recall that 3K heavily relied on dynamically loading what it needed from the cart from a pretty huge selection of content for even a single act.

3. Do you intend to have any fixed sprites built in? For a few examples: Sonic 1's forward-facing walking animation is horribly aligned (all other angles center him horizontally) and this was fixed in the Tax-Stealth Retro engine port. Sonic 2's walking animation has his face shift off to the left by one pixel in one of the frames, though this was not fixed in the mobile version. Sonic 2's floating animation still retains his S1 style eyes, but this was fixed in the mobile version.

Tiddles, on 22 January 2015 - 04:35 AM, said:

Most of the stuff that would be relevant to a project like this, I.e. tweaks and bugfixes, there shouldn't be any problem sharing - I'd have to scan through, but the vast majority of that category comes from either me or published tutorials.

I probably should have clarified that I didn't mean anything beyond tweaks and fixes, and I wouldn't want those (difficult to work with) options in there anyway as it wouldn't be fitting for a conservatively fixed version of just the base game.

[Clownacy]

Sodaholic, on 23 January 2015 - 06:32 PM, said:

Sonic 2's walking animation has his face shift off to the left by one pixel in one of the frames

Good god, I never noticed that! It's frame $11, sprite piece 0, if anyone else wants to see. Nice catch!

EDIT: Actually, it looks to be backwards: every sprite piece but 0 is shifted to the right.

This post has been edited by Clownacy: 24 January 2015 - 01:00 PM

[saxman]

Sodaholic, on 21 January 2015 - 06:39 AM, said:

Saxman, this is really awesome and I love every aspect of this project from the concept to the execution. If my coding skills were up to snuff, I'd have tried the same thing; a unified, polished/bug-fixed yet faithful version of the disassemblies, for community use. The thing I like most about it is the attempt to establish some kind of base standard so that hackers can focus on what they want to/are good at without having to worry about handling the commonly expected bug-fix/extra feature checklist. It's a goddamn waste of time to redo what's already been done but better, so why not just have those expected assembly changes be accessible by default?

You get it! I couldn't have said it better myself! I think with time, minds will change regarding the approach I'm using. This scene doesn't do things quite the same way as many others, and I don't see any reason it can't.

Tiddles, on 22 January 2015 - 04:35 AM, said:

Most of the stuff that would be relevant to a project like this, I.e. tweaks and bugfixes, there shouldn't be any problem sharing - I'd have to scan through, but the vast majority of that category comes from either me or published tutorials.

I wouldn't really want to give over feature stuff like selectable modes, layouts, level reorder, added music etc. for public reuse, but I don't think any of that is relevant to a project like this in the first place, nor to an original project based on S3&K - in fact, trust me on this, a lot of user end options to maintain only make the thing harder to work with. (I'd actively encourage taking on multibutton super though, since I detest the way that works as standard with the S3 moveset!)

That's good to know for the future. The more stuff I can access without reinventing the wheel, the easier it will be to make stuff happen =)

ThomasSpeedrunner, on 22 January 2015 - 04:56 PM, said:

To be honest, I'm not sure how to feel about this whole engine in the first place.

Things I like:
+ It's based off of Sonic 2, which means automatic higher score since I love Sonic 2.
+ Several assembly options allow for a mix of different fixes and features.
+ Objects are merged together with unique ways of detecting what subtype of an object to load.

Things I personally have a problem with:
- Touching on the merging of objects, the code on the Sol/Orbinaut example is kinda messy in my opinion.
- May I ask why 32X support was ever necessary? This could probably work perfectly fine without it, and the problem of people with no 32X knowledge attempting to make hacks utilizing it is going to be a thing rather quickly should this gain mass popularity among newcomers...
- Why dost thou includeth Sonic 1?
- The name is Sonic Boom, which is also the name of a cartoon, a game, a song, a user, and a Sonic 2 hack. I would suggest being more original with the title...

I know this is all kinda long for my first post here, but I've known about this for a while and have been keeping tabs on it despite preferring Xenowhirl's S2 disasm from '07.

While I do thing some of your concerns are misplaced, I do appreciate your feedback. I think Clownacy did a pretty good job summing up some of your concerns.

Clownacy, on 22 January 2015 - 05:48 PM, said:

Sonic 1 and 32x are both optional. The latter's already had its existence questioned. Also, people like Sonic 1. The Orbinaut/Sol looks like a space-saver, and the rest of the disasm is just as messy. The name came from what inspired the project. The wiki has info on that.

Anyway... Saxman, I can't find that line anywhere in the UPMEM disasm or my REV02 disasm. Not even a hex-search for the machine code had any results. Just where did you find that thing?

Also, another suggestion: In a similar manner to ReadySonic and my driver, could your changes be labelled, appended with a comment containing 'Boom Engine' or something?

I don't know what to say at this point. I searched Knuckles in Sonic 2, Sonic 2 revisions 01 and 02, Sonic 1, and Sonic 3 & Knuckles, and I did not find that line ANYWHERE. I could have sworn I pulled it from KiS2. I am honestly completely confused now. I clearly got it from somewhere, but I couldn't begin to tell you where.

And I need to do more of the commenting on specific changes. I have not been doing that, but I definitely feel there's a legitimate need for that. I'll try to have that done for future released.

Hitaxas, on 23 January 2015 - 03:48 PM, said:

I would actually be more interested in having it build for Sega cd. Maybe both ideas could be good. But allowing it to build on Sega cd would allow people to modify Sonic 2 on a system they previously could not. So far I think most if not all hacks made for Sega cd are of Sonic 1. This would enable to ability to utilize red book audio and also allow the creator to access more data space, allowing them to create bigger and better things.

Tl;dr : The Sega cd option is the way to go imho.

I'm a little intimidated by the Sega CD to be perfectly honest. That's why I kind of thought maybe bringing over some Sonic CD code and assets over to the Genesis/32X would be better. But I haven't made any decisions on that just yet. If I do decide to go the Sega CD route, it would be a big learning curve for me. We'll see what happens.

Sodaholic, on 23 January 2015 - 06:32 PM, said:

The MCD is pretty limiting in some ways for mode 2 software, namely in that you have to keep everything that needs immediate access in the program RAM as the only other way to access data is through slow disc reading instead of fast ROM reading, and the program RAM only allows for 256kb of space. Of course, Stealth demonstrated that it was quite possible, but he had to jump through some hoops to do it.

Some questions:

1. If MCD support is added, could it perhaps be mode 1 at first? That would probably require less effort to tap into the MCD hardware as a faster cartridge game than to restructure the program to squeeze it into 256kb chunks?

2. I'm no programmer, but am I wrong to assume that 3K would be a huge chore or even impossible (without significant mid-level load delays) to port to MCD? I seem to recall that 3K heavily relied on dynamically loading what it needed from the cart from a pretty huge selection of content for even a single act.

3. Do you intend to have any fixed sprites built in? For a few examples: Sonic 1's forward-facing walking animation is horribly aligned (all other angles center him horizontally) and this was fixed in the Tax-Stealth Retro engine port. Sonic 2's walking animation has his face shift off to the left by one pixel in one of the frames, though this was not fixed in the mobile version. Sonic 2's floating animation still retains his S1 style eyes, but this was fixed in the mobile version.

1) I have no idea. Big learning curve for me!

2) I imagine there must be some way of making this work. But again, the learning curve!

3) I may. I already fixed the Knuckles look-up sprite offset issue pointed out earlier in the topic. I could potentially do the same for other sprites. It's not a high priority for me, but it's good low-hanging fruit if I decide I need to do more before I'm satisfied with things prior to making a release. I am very curious about the Sonic 2 sprite issue (I'll be loading Sonic 2 after I post this to see it for myself so I know what you're referring to).

This post has been edited by saxman: 23 January 2015 - 09:42 PM

[GT Koopa]

I want to use this, really want to use this, but with my hour or two of fiddling with SonLVL I can't seem to get it to work properly. I did once long ago but I never really used the program much. Now the updater keeps giving errors and reinstalling the thing or following the guide while trying to mimic placement with the SB disassembly and the files provided. Maybe I am mistaken with what goes where or if it currently works with SonLVL in the first place.

[MainMemory]

It doesn't. Someone would have to create custom definitions for the level layout and ring layout formats.

[saxman]

MainMemory, on 24 January 2015 - 10:27 AM, said:

It doesn't. Someone would have to create custom definitions for the level layout and ring layout formats.

That is true for the SBLF, but Sonic Boom still supports the standard Sonic 2 format as well. But as far as setting it up, I am not an expert in this realm. Can lend some advice, MainMemory? Or perhaps someone else who has done it more than a few times?

EDIT: If you want to use the new level format instead of the Sonic 2 format, I can whip up some tools that will allow you to make those enhanced levels and still use SonLVL. But can someone confirm that SonLVL can still be configured to work with Sonic 2 using the old level format first?

This post has been edited by saxman: 24 January 2015 - 04:14 PM

[flamewing]

Sodaholic, on 21 January 2015 - 06:39 AM, said:

Yes, CD seems a better next step than 3K given that it is mostly a souped-up S1, whereas 3K made fundamental changes to many, many things.

Yeah, I had this misguided notion of SCD too, until I started disassembling it. SCD is actually its own beast; it is very similar to S1, true, but has many things in common with S2 and many things neither of them have. The good news is that, as far as levels go, the amount of shared code is astounding and the differences are mostly data and object code. The bad news is that qiuu's data dump does not have all needed data by a long shot, and there are minor code differences between the levels, so you would need to disassemble all MMDs to make sure you got everything. Supporting S3K would be easier in many ways (as there is a disassembly available); but since Saxman's engine is S2-based, it would end up being almost as hard, because of S3K's changes to OSTs, and the whole 'code pointer in OST' thing, among others. Especially since he chose the less maintainable 2007 disassembly as a base.

[Chilly Willy]

I've posted a number of demos with code on using the CD over at SpritesMind and Sega-16. For example, an 8 channel mod player, and a mikmod player. I also did an example for doing Direct Color DMA mode from the CD. The SCD is pretty cool. A version of Sonic 2 that ran from CD (or used the cd in mode 1) would be pretty cool. Imagine having extra levels (or user levels) on CD, and extra/replacement music on cd. MOD format music on the CD PCM chip sounds awesome. It's the next best thing to having an Amiga.

[Sodaholic]

saxman, on 23 January 2015 - 09:25 PM, said:

1) I have no idea. Big learning curve for me!

Mode 1 is where the game is cartridge based but accesses the MCD hardware for extra features such as its audio and additional co-processor. Mode 2 is where the game runs from the CD drive. Mode 1 is clearly superior for having all the advantages of cartridge-based games and none of the downsides of slowly loading small chunks of program data from a CD. Theoretically, it should be easier to do mode 1 first given that it doesn't need to be crammed into 256kb chunks and can pretty much run as-is while calling the extra hardware when needed.

Maybe this would help to take a look through? http://forums.sonicr...ndpost&p=649833

As a side note, that linked thread is one in particular that opened my eyes to the code hoarding mentality that seems to (at least in the past) take hold in this community. Also worth noting that Iron Sonic did approach me privately and apologized for that attitude about half a year ago, and likewise I apologized for calling him an "elitist prick" which was a bit over the edge.

saxman, on 23 January 2015 - 09:25 PM, said:

2) I imagine there must be some way of making this work. But again, the learning curve!

To clarify, that was more of a question to general (techie) readers about the feasability of S3K's sheer size of data and how quickly it needs to access it for a seamless gameplay experience. I'm obviously not qualified to answer that question myself, but I strongly suspect it'd be infeasible without serious interruptions in the gameplay just from an uneducated gut feeling.

flamewing, on 25 January 2015 - 06:45 AM, said:

Yeah, I had this misguided notion of SCD too, until I started disassembling it. SCD is actually its own beast; it is very similar to S1, true, but has many things in common with S2 and many things neither of them have. The good news is that, as far as levels go, the amount of shared code is astounding and the differences are mostly data and object code. The bad news is that qiuu's data dump does not have all needed data by a long shot, and there are minor code differences between the levels, so you would need to disassemble all MMDs to make sure you got everything. Supporting S3K would be easier in many ways (as there is a disassembly available); but since Saxman's engine is S2-based, it would end up being almost as hard, because of S3K's changes to OSTs, and the whole 'code pointer in OST' thing, among others. Especially since he chose the less maintainable 2007 disassembly as a base.

I dunno how Saxman is implementing Sonic 1, but I imagine it's more of a port to work within Sonic 2's structure (like that Sonic 1+2 hack) than actually directly implementing its older systems along with the content, but Saxman would have to be the one to clarify what methods he's using.

That being said, does it have to be a 100% accurate port of all of its quirks, at least at first? Since the level layout systems are closer to the "everything at once" method 1 and 2 had, maybe it'd be nice to start with an incomplete port of just the levels, at least as a starting point.

Chilly Willy, on 26 January 2015 - 03:02 AM, said:

I've posted a number of demos with code on using the CD over at SpritesMind and Sega-16. For example, an 8 channel mod player, and a mikmod player. I also did an example for doing Direct Color DMA mode from the CD. The SCD is pretty cool. A version of Sonic 2 that ran from CD (or used the cd in mode 1) would be pretty cool. Imagine having extra levels (or user levels) on CD, and extra/replacement music on cd. MOD format music on the CD PCM chip sounds awesome. It's the next best thing to having an Amiga. />/>

Oh man, I've always wanted to see mode 1 module music in a hack. It'd be an easy way to get the SMPS music sounding all Amiga-like.

This post has been edited by Sodaholic: 27 January 2015 - 12:47 AM

[Varion Icaria]

While the factor of Sonic 3K falls into my territory, I've long since had it ported to Sega CD, Using both Modes for Sega CD. I will tell you right now that Transitions albeit possible are the hardest things to accomplish with Mode 2. Mode 1 everything is generally easier because it's just enabling the CD hardware but still running off the cart. Honestly the amount of time I put into porting S3K to Mode 2 it's really not worth dealing with it. Though with the lack of emulation supporting Mode 1 [Especially with the 32X mind you] There's really not much use in designing something that can only be tested on legit hardware with a flashcart. [Expecting everybody to have all 3 consoles and a flash cart that can support it is asking a bit much.] This was why I made a decision to continue my hack via mode 2 personally for right now. Until emulation is properly functioning with Mode 1 I'd really just steer clear of it. There's a lot of glitches such as DMA not working, 32X completely not working right with Mode 1 in emulation among many other glitches I'm sure exist.

[MarkeyJester]

Assuming you're refering to Kega Fusion in "Mode 1", then DMA does in fact work, so long as the source address is not located around the ROM region, this region is rather iffy, and I'm under the impression the Mode 1 aspect of Kega Fusion, was designed specifically to handle the requirements of "Flux" and nothing more. This (interestingly enough) makes Sonic 1 ideal, given that all "transfer" related DMA requests are done so with 68k RAM as the source.

I feel however, that whether it does or does not work properly in Kega is irrelevant. The simple fact is, no one's going to step up to using this thing effectively within a hack, and with any form of gameplay elements to it either. I know, that at the end of the day, I shall be disappointed in seeing everyone boast about their Mega CD hack, when the irony is, it's not far off different from their hack if it were on a Mega Drive alone. Having said that, I would like to see more graphical use of the machine (yes, I'm aware that the resulting graphics supplied by the Mega CD are not displayed by the Mega CD, and that other display hardware (such as the Mega Drive's VDP) are required for actual display, so don't bother with the lecture) as it'll be nice to have products that stems away from the obvious CDDA/PCM.

[Chilly Willy]

MarkeyJester, on 27 January 2015 - 03:42 PM, said:

Assuming you're refering to Kega Fusion in "Mode 1", then DMA does in fact work, so long as the source address is not located around the ROM region, this region is rather iffy, and I'm under the impression the Mode 1 aspect of Kega Fusion, was designed specifically to handle the requirements of "Flux" and nothing more. This (interestingly enough) makes Sonic 1 ideal, given that all "transfer" related DMA requests are done so with 68k RAM as the source.

He meant mode 1 in 32X mode. A 32X cart cannot use mode 1 under ANY emulator currently. It works just great on real hardware, as my mode 1 support in Wolf32X shows.

[Varion Icaria]

MarkeyJester, on 27 January 2015 - 03:42 PM, said:

Assuming you're refering to Kega Fusion in "Mode 1", then DMA does in fact work, so long as the source address is not located around the ROM region, this region is rather iffy, and I'm under the impression the Mode 1 aspect of Kega Fusion, was designed specifically to handle the requirements of "Flux" and nothing more. This (interestingly enough) makes Sonic 1 ideal, given that all "transfer" related DMA requests are done so with 68k RAM as the source.

I feel however, that whether it does or does not work properly in Kega is irrelevant. The simple fact is, no one's going to step up to using this thing effectively within a hack, and with any form of gameplay elements to it either. I know, that at the end of the day, I shall be disappointed in seeing everyone boast about their Mega CD hack, when the irony is, it's not far off different from their hack if it were on a Mega Drive alone. Having said that, I would like to see more graphical use of the machine (yes, I'm aware that the resulting graphics supplied by the Mega CD are not displayed by the Mega CD, and that other display hardware (such as the Mega Drive's VDP) are required for actual display, so don't bother with the lecture) as it'll be nice to have products that stems away from the obvious CDDA/PCM.

Well that much I knew because with the way Mode 1 was implemented in Fusion it's still using parts of the normal CD functions which disable the Rom DMA ability. However it still just sucks 32X + Mode 1 isn't supported by any emulator.

[MarkeyJester]

Chilly Willy, on 27 January 2015 - 06:51 PM, said:

He meant mode 1 in 32X mode. A 32X cart cannot use mode 1 under ANY emulator currently.

Oh! My mistake! I thought he was referring to standard MD only Mode 1 access. I do apologise for a lack of clarity evolved around the confusion.

[Aerosol]

That's interesting. Anywhere I can read a write-up as to why that is?

This post has been edited by Aerosol: 27 January 2015 - 08:21 PM