Fusion is closed source, so who can say? But other emulators with source you can look at. For Gens/GS R7, when the 32X part is activated, it builds an address map that never includes the CD, so it not only doesn't do mode 1 in 32X mode, but doesn't allow CD32X games either. Most emulators are more concerned about running existing software than actually emulating a platform EXACTLY, and there was never any 32X mode 1 software until I added it to Wolf32X. A good example is Fusion: the PWM audio in Fusion was originally done to work with existing games, which used a particular way of setting the PWM using sample code from Sega. It sounded weird with my early PWM demos because of that. Snake changed Fusion to handle that using my demos for testing for his final version. So I'd expect that if he came out with an update, it would probably do all these new things... so here's hoping he has a new rev coming out!
Well I was wondering more if there were any technical limitations, or of it was a lack of knowledge of the hardware. Neglect of a feature is something else. How is Nemesis' emulator coming?
Often, it's usually just lack of anything to really test with. Until my 32X demos came along, you really had little more than commercial games and a couple other demos that merely showed some simple graphics. Having code to look at also helps in fixing problems. As far as I know, it's MD only. No CD or 32X. You can check his official forum on it over at SpritesMind to get a better idea of the state of his emu. http://gendev.spritesmind.net/forum/viewforum.php?f=18 I don't have direct contact with him, he just will actually respond to my posts on boards we frequent if I direct a post to him and he's around. I haven't seen any posts from him in quite some time. That's not too unusual for devs - I took a few months off last year where no one heard from me for a while, too. Sometimes, it's because you're burned out and cannot even think of looking at the stuff until you get over it. Sometimes, you're on a project that consumes all your time, and you just haven't a single free second. A few projects I have worked on, when it gets to hump time, you're working 20 hour days for a couple weeks to months to meet the deadlines imposed. You can't be reached at all in that time, and afterwards you don't feel like doing anything for the next few months. And sometimes (usually the case for me), you update your computer, decide to reorganize your bookmarks, and miss a site because you frequent too many boards! So you don't check on a site you used to frequent until someone sends you an email or catches you on another board and asks if you're still alive.
The good thing of the architecture he claims to be making is that making things like mode 1 work with the 32x will be a matter of coding the add-ons correctly and linking them up to the emulated system. Lets see how well that works in practice...
I downloaded SonLVL and the Sonic 2 2007 INI files. I modified the INI files to use the legacy layout files from the original Sonic 2. Despite this, SonLVL still gets stuck on one thing I have not been able to resolve, and I think it is something that may need updating in SonLVL itself if it is to have even partial support for Sonic Boom: Sonic Boom doesn't use "s2.asm". Any workarounds for the time being?
It's the object definition for the Spring object. You can remove it from obj.ini, or change Common/Spring.xml so it uses the correct mappings.
Ah, I missed that. Thanks! Okay, here we go: http://1drv.ms/1z4fOUV It is a set of INI files that will work with the latest version of SonLVL. It will use the /levels/layout/old directory for level layout, and the /levels/rings/old directory for ring layout. Until SBLF support can be created, we'll have to make due with the legacy Sonic 2 format. The good news is you can start designing with the legacy format now, and then use my SBC and RingConv tools (see first post) to convert your levels to SBLF. And then, when we get SBLF support, those files can then be used instead of the legacy files. I hope this is an adequate solution for the time being. I'm willing to help anyone with SonLVL setup if needed. It's not that hard once you figure out that the INIs must go in a folder inside your actual disassembly folder.
Come on, you didn't check all the levels! Any level with an underwater palette makes SonLVL crash because of your splitting of the palettes between Sonic/Tails and Knuckles! Anyway, here's a fix for that, and a custom SonLVL definition for the ring format (surprise!). Speaking of, I've been meaning to bring this up: why did you go with a custom ring format? I get that by moving the 'orientation' bitflag, you gave the rings greater Y-range to cover that of your level layout format, but S3K does that and more. As you may know, S3K-format ring layouts specify each and every ring, with no grouping. So, there're no 'count' bits, nor is there an 'orientation' bit; X and Y get a whole word each. It also has the benefit of being easier on the RAM, like your level layout format, which gives you more rings for the same amount of RAM, again, like your format.
No, I didn't check every level. At my job, this would have been a slap on the wrist. Thanks for catching that and providing a fix! I have been been working on (sort of) supporting the Sonic Boom layout via another INI definition, and I have it partially working, except the levels aren't resizeable. So I have more to do, but MainMemory tells me it can be done (at least the way I intend to do it). But, more on that later. Regarding the ring layout, that's an excellent question, and I thought about doing it several times. I opted for a custom format with the Sonic 2 methodology mainly because, although it is more RAM-heavy, it is faster as a result of that. Sonic Boom's custom level layout format is more CPU intensive (try playing Chemical Plant Zone with Sonic and Tails -- it gets very sluggish at certain points), and so I didn't want to make it worse. Instead, the plan I have is to eventually support doing the ring layout the Sonic 3 way, but only AFTER the Sonic 3 objects manager is in place. The Sonic 3 objects manager adds vertical scope, so it doesn't process unnecessary objects above and below the camera's vertical position. This would fix a lot of speed issues, and so the Sonic 3 ring layout method then becomes more reasonable from my perspective. But luckily, there's guides on how to do that stuff if people want it now and not later.
I've been playing through the Sonic2r3.32x rom to see if anything is noticeably different in game. The speed at which an Act loads is a little quicker. This is quite obvious on some acts more than others where the title card flies off faster. I did encounter a weird issue though: The Chemical Plant Zone Boss has some very strange behaviour when he attempts to drop the liquid on you. He seems to get stuck slightly off screen to the right and "flickers" back and forth between being in the centre of the screen and being off screen. That being said; this seems like a solid idea that makes a good deal of sense; moving Sonic 2 (a familiar game/engine) over to the 32X, allowing people an easier time of creating a hack for the 32X. Well, that seems to be the idea, anyway. Either way, good luck with future developments with this. It's not something I'd ever use personally but I can see the potential.
I'm part of the way into porting Sonic 1 over to the Sonic Boom codebase. Click the link below to check it out: ==== Proof-of-Concept ROM ==== I need bug testers! This will have a lot of bugs, no doubt. Some are obvious, while some will be less obvious. No matter how obvious or not obvious they are, please report them here. The goal here is to try and collect as many problems as I can. I may miss some things. You, the community, can help make sure I see everything I need to see. This conversion contains three ported zones: Green Hill Zone Marble Zone Star Light Zone So, get testing! EDIT: I should mention that to complete Marble Zone, you WILL need debug enabled.
Only done a preliminary playthrough so only brief findings, so here goes, in order of appearance: SEGA screen is skippable. Title screen does not contain background or Sonic, and emblem scrolls. Title card for each zone is from Sonic 2. Title card displays garbled version of Sonic 2 zone name. Music for each zone is from Sonic 2. Art mappings for many objects are broken, most notably springs, end-of-level bonuses, and breakable blocks in MZ. Sound effects for many objects are broken, using Sonic 2 sound effects. Palettes for many objects are broken, possibly uniquely those that used to share Sonic's palettes. Spindash present - if this is supposed to be Sonic 1, it probably shouldn't be. Speed caps present, spike bug not - don't see any problems with this, but just pointing it out. Special stages aren't present. Pushable blocks do not appear; neither do blocks that drop from the ceiling (renders MZ1+3 impossible to complete). Lava flow in MZ2 does not appear. Rexon bug present - destroying two Batbots in MZ2 quickly enough from the start can sometimes cause the game to crash (stupidly I didn't get a savestate). Something's off with the girders in SLZ. They're either aligned incorrectly, or scroll at the wrong speed, or something similar; they seem to cover the screen in different areas than they used to. SLZ boss doesn't drop spike balls. Defeating SLZ boss causes girder graphics to be overwritten. And just for fun: Level select is deformed the way the background should be. SYZ, LZ, SBZ are mostly objectless and crash shortly after starting. Debug mode only contains ring and monitor. Most of these should be already known, but here they are anyway.
One thing you might want to consider as far as more S1-like gameplay goes would be implementing an option to use the alternate, more lethal spike behavior. Specifically, where you can die if you get hit again while still showing the pain animation. Though not entirely related to S1, could I suggest adding in a double-tap to look up/down option like in SCD? I liked it so much better than having to sit there holding it like in S2.
I recently got the title screen completed, except for one thing: the logo wants to scroll with the background! I have compared what I have with the Sonic 1 disassembly, and I am not finding anything unusual about my implementation. Any volunteers for looking at my code and trying to figure out what's wrong? Thanks for testing! That's quite a thorough list you've provided. I will have most of those fixed by the next demo. I plan to have at least two more demos before it's finalized. Because I consider the spike behavior to be more of a bug than anything, I am leaning against it. Unless of course anyone feels it makes the port of the game less legitamite without it. Or unless anyone thinks it makes for a good "feature" to have in hacks. I would actually very much like to add the double-tap look up/down style of Sonic CD. I've been considering that and a few other minor things out of the world of Sonic CD. No promises, but if I find the time to insert it, I will.
Tried another crack at it. It seems like everything is one step forward then another wall for me. Trying to keep up with all the fixes and figuring out which goes where...but it is daunting, especially with lots of error messages from SonLVL itself and the updater. Any updates saxman? MainMemory?
There's a reason why SonLVL has a built-in bug reporting feature, and why it saves a log file: screenshots don't help. At all.
