Is a Sonic and knuckles collection widscreen mod possible?

Currently I think the only way people can play Sonic 3 & Knuckles in widescreen is with the fangame Sonic 3: Angel Island Revisited. Sonic Origins will also allow people to play S3&K in widescreen when it comes out this year. I highly recommend giving Sonic 3: A.I.R. a try. It's a lot of fun.

 

Yes, and someday I will make that mod.
I've figured out most of the rendering code already, the real challenge is figuring out what parts of the game I have to edit to do it.

 

For the record, you can use custom music with AIR. People have made multiple audio packs based on the S&KC midis, even recording the actual hardware. Since the original midis sounded differently on different MIDI synthesizers, the results vary, but I think this one sounds pretty good.

 

Hi! Wow, I am still alive here? Anyways...

I have been through the Sonic & Knuckles Collection for decades now, so I might be able to help.
The main screen render code (the function) is located at offset 0x403101 in SONIC3K.EXE.
There are multiple branches to different tile rendering code, such as AIZ's blimp, split screen for 2P competition modes. It is quite a lot of code to go through, but the actual rendering is done quite easily, optimized for whole tiles with clipping on beginning tile and end tile. It is written in assembler, but not that optimized. There are quite a lot of loops with 0xE0 (224 scan lines), meaning tiles are rendered one scan line at a time, so look for number of tiles and not pixel. Start tile and end tile will most likely be clipped and require special code.

Basically, you can't just hack Windows API, DirectDraw calls, or window sizes to make this game wide screen (unless you want to stretch the original screen).

The render is called from the VBlank "emulation" function, which is called directly from the Sonic game at original/default source code ~WaitForVBlank locations, and does everything from frame timing, updating looping sound effects, to dealing with the Windows message pump, making it a hybrid of a Win32 Application and a Genesis game. The offset to this function is at 0x403101.

The DirectDraw back buffer rendering is done in a function at offset 0x40336E, which is also where the HBlank water palette color is applied.

 

I also looked into the S&K Collection back in the day (there are dozens of us!) and in my opinion there is very little to be gained from modding it today. The port is nothing special, just a straight code conversion with rendering/sound/input patched in, in a "pseudo-emulation" sort of way. Eukaryot appears to have taken the same approach in the conception of Sonic 3 A.I.R; if you were to attempt patching widescreen support into S&K Collection you would only be retracing Eukaryot's steps in having to rewrite and patch the original game's code in a variety of places to be compatible with the new rendering code. So basically, go play/mod S3 A.I.R. because it's the same thing but with the widescreen work already done and better support.

 

A.I.R. modding is completely incomprehensible to me. I'll keep doing S&KC, thanks.

 

I was going to say I think I remember an interview where they explained that S&K collection was an assembly port. Maybe take a look at how the gx wide patch for S3&K works and try and line up the assembly code between the patched/unpatched Gen code and PC code using Ghidra?

 

I use IDA, but yes, that is basically what I'm planning to do. And yeah, S&KC was incredibly obviously machine translated from 68000 ASM to x86 ASM. It's got a set of 15 variables in memory that correspond to each of the MD's 8 data and 7 address registers (a7/sp is just the esp register), and the code is incredibly redundant; every source instruction that reads from a register generates an instruction to read the memory variable into one of the x86 registers, even if the previous source instruction also read or wrote that same register.
A while ago, I posted on Twitter an example of how insanely bloated the code gets sometimes:

Code (Text):

1. loc_3F9E:
2.    move.l (a0)+,(a1)+ ; Fill 2 palette lines with title screen data
3.    dbf d0,loc_3F9E

becomes:

Code (Text):

1. .text:006DC26E loc_6DC26E:                             ; CODE XREF: Title_Screen+2C6↓j
2. .text:006DC26E                 mov     edi, dword ptr reg_a0
3. .text:006DC274                 mov     eax, [edi]
4. .text:006DC276                 add     edi, 4
5. .text:006DC279                 mov     dword ptr reg_a0, edi
6. .text:006DC27F                 mov     edi, dword ptr reg_a1
7. .text:006DC285                 mov     [edi], eax
8. .text:006DC287                 add     edi, 4
9. .text:006DC28A                 mov     dword ptr reg_a1, edi
10. .text:006DC290                 test    eax, eax
11. .text:006DC292                 pushf
12. .text:006DC293                 mov     ax, word ptr reg_d0
13. .text:006DC299                 dec     ax
14. .text:006DC29B                 mov     word ptr reg_d0, ax
15. .text:006DC2A1                 cmp     ax, 0FFFFh
16. .text:006DC2A5                 jz      short loc_6DC2AA
17. .text:006DC2A7                 popf
18. .text:006DC2A8                 jmp     short loc_6DC26E

 

Look like the conversion must have been at least partially automated in that case. Makes sense they would try and make their lives easier at the expense of some inefficiency.

 

That was used by Sonic CD PC (and its Gems Collection ports) and I think Sonic 3D Blast PC. I've seen Sonic Jam's code (edit: heh), and, from what I remember, that one was very visibly done by straight automated 68k ASM -> SH2 ASM conversion - no C in-between. Same for Sonic & Knuckles Collection (though targeting x86 ASM instead of SH2 ASM, of course).

There was even a thread on here once by a guy claiming to have written that 68k->C converter. I don't have a link to it though (edit: found it).