Sonic and Sega Retro Message Board: FraGag - Viewing Profile - Sonic and Sega Retro Message Board

If you're reading this, you probably know what we couldn't commit to the svn repository for a while. Instead of figuring out how to keep the svn and WebSVN working all the time, I suggested that we switch to either git or Mercurial (hg). git and Mercurial use similar concepts that are quite different from svn, so there would be an adaptation period for those who have never used them, but then again, most of us probably learned svn through this project. :P

Both git and Mercurial are distributed version control systems. While with svn, the repository was stored on a server and all you had was a working copy, with DVCSes everybody has their own repository. This means that you can make local changes on your computer, commit them to your local repository to build a history, then you can push your changes to a central repository when you're ready to share them. You could also keep using git or Mercurial for your hack by committing your changes to your local repository without ever pushing them to the central repository. By committing regularly, you keep a version history and don't need to make manual back-ups in case you screw up with your hack; however, you'd still have to back up your repository or push it to a remote location in case your hard disk fails. (Technically, it would have been possible to use a local svn repository, but not with Retro's svn repository history.) Also, by building your hack in a repository, you can later pull changes made to Retro's repository and integrate them in your hack; if you edit very little code in your hack, the changes will most of the time be merged automatically.

And hopefully, the web access clients for git and Mercurial don't suck as much as WebSVN. :P

To help you make a choice between git and Mercurial, should you be asking yourself that question, here are some notes about them:

• git is faster than Mercurial.
• On Windows, git doesn't handle characters outside of ASCII (characters 0 to 127, for those who think ASCII is more than that) correctly in file names and commit messages: it reads them using the system's ANSI code page (e.g. CP1252) but then tries to interpret the bytes as UTF-8, which fails. This means that such characters would probably be rendered as ? or �. Mercurial also has this problem, but it can be fixed for the most part by using the fixutf8 extension (the only issue is when you try to create or clone a repository in a directory that contains characters outside of ASCII, in which case the repository will not be created correctly).
  EDIT: GerbilSoft made me notice utf8-git-on-windows, which aims to fix this problem.
• git identifies revisions using a SHA-1 hash. Unlike svn, revision identifiers are not sequential. This wouldn't make sense anyway, because it is possible to create revisions in separate repositories and merge them together later on. Mercurial does this too, but it also uses sequential revisions numbers. However, these sequential numbers are only relevant in a specific repository, so they won't necessarily make sense in other repositories, even if they're all based on the same source repository.
• Both have graphical clients on Windows. TortoiseGit is build from TortoiseSVN and tries to make git work like svn, which isn't necessarily a good thing... TortoiseHg, on the other hand, is completely different; it's really made for Mercurial. It's available as a Windows shell extension and as a GNOME/Nautilus extension.

KENSSharp is a set of libraries written in C# that contain compressors and decompressors for the Kosinski, Enigma, Nemesis and Saxman compression formats. It is a port of flamewing's port, which is included in Sonic 2 Special Stage Editor. This port was motivated by the desire to make S2LVL work on other implementations of the Common Language Infrastructure, such as Mono, in which P/Invoke is not available.

sonicblur independently ported the compressors and decompressors from the original KENS library to C# in a project called KensNET; see next post.

KENSSharp is licensed under the GNU Lesser General Public License, version 3 or later.

I've just committed Sonic Adventure Tools, a group of C# projects for working with Sonic Adventure and its derivatives (SADX, SADXPC). The main project here is SADXPCDecompiler, which extracts data from a DLL and generates a bunch of .c code files with the data contained in the DLL. The files that can be compiled to regenerate the DLL. As a matter of a fact, I've also committed the code files for CHRMODELS.DLL in Sonic Adventure DX PC Decompilation. The game will happily use the new DLL if you replace it in SADX's installation folder. If you find problems with the new DLL, please post in this thread.

The other projects in Sonic Adventure Tools are class libraries that could be used in other programs such as editors.

Xenowhirl's Sonic 2 split disassembly is now up on the SVN server, as Scarred Sun announced. This will allow everyone to improve the disassembly, but keep in mind that the built ROM must be identical to Sonic the Hedgehog 2 REV01. The ROM is included in the repository (named s2rev01.bin), and a batch file (chkbitperfect.bat), which uses this file, is provided to allow you to check if you didn't do anything wrong. Please, do not commit if the built ROM is not identical to Sonic 2 REV01!

Before committing, please leave a comment about what you changed in changelog.txt. You can also put the message in the message field when committing your changes.

Another reason I've created this topic was to gather opinions if someone wants to change something, but doesn't know if it will be well received. You don't need to get approbation for every change, but if you're unsure, just ask here. Also, if you want to revert someone's changes, please ask here first, unless what you want to revert is vandalism.

So, I'll go first! I've changed build.bat to make AS output the errors to a separate file (s2.log) using the -E switch, instead of outputting them in the console. AS will delete the file if there are no errors, so it is possible to test the presence of this file to determine if there were build errors/warnings. Having the errors in a file makes it easy to see all the errors, because the console may cut off the start of the errors if there are too many. It will also make it easier for starters to share their errors. Is this a good idea?

Another change I'd like to see is having the code split to several .asm files. If you've worked with the modified version of Hivebrain's Sonic 1 disassembly targetting AS, you may have remarked that when the messages appear, they can be lost (because the console's output is cut off) when there are a lot of files processed after that error. I believe outputting the error messages to a separate file will solve this problem and allow us to split the code without too many worries. What do you think?

FileRX is a utility I made to be able to use the powerful javascript function String.replace on files. The program can also use it on text put in a text box. The result can be written in a file or output in a textbox.

The program is currently at version 0.0.0 and is available on my website (oh noes silly ads). The rest of my site is in French only, so it's probably not interesting for at least 95% of the people here.

This is most a tool for geeks (JavaScripters in particular), I don't expect everybody here to find a use to it, or even to understand how to use it. Most text editors have a basic search & replace feature and it's enough for most people.