Sonic Classic Heroes

I mentioned it before, but I can forgive not wanting to read the entire thread for it. This is a known issue, for which I really, really, really, REALLY don't give a fuck about at the moment because any change I make internally has the potential to desynch the demos, and I would have to record them again.

At some point in the future I will record new demos; for now, their priority is -infinity.

 

That is a good solution, which I will be doing.

 

The two things that impact development of SCH are my job (I don't have nearly as much free time as I used to, and this free time is split among several projects, my wife and my cat) and the fact that the sprite sheets are done by volunteers on their free time.

I have been thinking of giving more people access to SCH code to work around the former issue (so it doesn't depend so much on me); for the latter issue, you may consider throwing a couple donations to the spriters to support their work.

As for releases, there is likely to be a release with Team SegaSonic, Team Super, Team Hyper, and a ton of bugfixes and improvements before any other teams are done.

 

You are guessing wrong; I barely had any time to work on anything this year, and won't be entering anything on the hacking contest this year.

 

On the Sonic side, and other than SCH and BFD, I have (in no order):

• three hack ideas I am working on at a conceptual level (there is no code, art or music, just ideas);
• one hack I started working on (but had nowhere near enough time to make it in time for the contest);
• one mini-hack I been wanting to make (and which would take a few minutes to do it);
• trying to figure out a way to allow editing the appearance of S2 special stage tracks;
• looking into ways of improving the framerate of S2 special stages (using different methods than the mini-hacks I had made);
• splitting off my libraries and tools off from s2-ssedit;
• I am working on a Genesis optimization guide;
• writing a 68k/z80/SH2 assembler to get rid of AS;
• writing a 68k peephole optimizer that makes source code transformations;
• Sonic CD 100% TAS (still routing and deciding what 100% will mean);
• Sonic CD disassembly;
• updating Sonic CD any% TAS with new tricks;
• improve my Sonic TAS lua HUD (planning to show distances for collision with terrain, ghost display, some auto-optimizers);
• see about adding 68k and z80 support for highlight.js.

Non-Sonic:

• Seeing if I get some work done on Exult (with a TODO list several miles long);
• try to get some work done on my usecode decompiler;
• trying to make U7: Black Gate and U7: Serpent Isle TASes;
• data extractor for Inkle games (notably, Sorcery! series) and maybe a repacker;
• X-Men 2: Clone Wars disassembly;
• (redacted);
• lots more I am probably forgetting.

Edit: added a couple more things I remembered.

 

Lets see:

I have a full 100% disassembly of R11A, which is done at a level near to that of the S2 Git disassembly (basically, every identifiable byte has been identified); and several IDA scripts which I plan to use to disassemble the other zones more quickly, then compare the differences. What I really need is to identify where data is (most likely using qiuu? SCD data dump) so it is auto-identified to make the process go smoother.

I have also been working with TheStoneBanana and Ralakimus, both of which also have buildable partial SCD disassembies.

My aim is to have a single codebase for all levels, allowing you to mod the whole game by editing things once. Then, see if it is possible to make a Sonic NoCD hack, with the whole game in a plain MD.

I know of 3 ways to do it, and I think I may have a few more. These are the ones I know work (base framerate is (60/9 = 6.666666667 FPS):

1. pre-decompressed plane data, transferred each frame at the same rate as the original (7 tile rows per frame). Disadvantage is that the data becomes 10 times larger. This allows 12 FPS.
2. Same as above, but transferring 14 tile rows per frame instead using DMA. This allows 24 FPS.
3. Not displaying the track for an added frame. By itself, this allows 7.5 FPS; combined with (1), you get 15 FPS; combined with (2), you get 30 FPS.

And these are the ones i am unsure:

• instead of 128x32 planes, use per-frame art for a 32x32 plane and transfer art+plane mappings. I think there is not enough bandwidth for this (my calculations indicate that the art+plane mappings would take 4 frames to upload).
• Try merging frames: each 128x32 plane "draws" not one, but 2 or 4 frames and hscroll is changed to show the others when needed. I need to write a frame merger* to test this, and it might turn out that I need to allow a small tolerance from bit-perfect rendering so that this can work. Would need to upload art and mappings frequently, unless a universal tileset for all frames is possible.
• Try using raster effects (in hblank) to double the lines of each tile, to reduce required bandwidth on the above two options.

I'd love to hear what you have to suggest about this.

The issue is basically time; in order to improve the script, I am planning on rewriting it in Moonscript, rewrite ROM detection code and add several improvements that allow loading ROMs based on the serial number, all so I can find collision data automatically. Before this, I rolled out my own OO code, and it takes some time getting re-used to it when I mess around with the script. But if you want to help, all you will need is a GitHub account.

So do I, I am the guy that cracked the format and documented it completely on S2 Git disassembly; the issue is coming up with a good UI for it. I have an idea on how to take an image and import it as closely as possible using the SS tiles, and you would edit based on that.