Sonic and Sega Retro Message Board: Sonic Retro on GitHub - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 3 Pages +
  • 1
  • 2
  • 3
    Locked
    Locked Forum

Sonic Retro on GitHub Who? What? When? Where? Why?

#16 User is offline KingofHarts 

Posted 10 July 2014 - 10:52 AM

  • WHY CANT I EDIT THE WIKIIII????
  • Posts: 1543
  • Joined: 07-August 10
  • Gender:Male
  • Project:Sonic 1 Complete (SHC 2016 Entry)
  • Wiki edits:1
So I've finally got myself forked onto the Mega Drive disassemblies. Expect plenty of pull requests as far as the S3K disasm goes, in the coming months... I've been hard at work.

#17 User is offline Clownacy 

Posted 22 July 2014 - 08:36 AM

  • Layin' the Wax and Spinnin' the Sounds
  • Posts: 629
  • Joined: 06-July 13
  • Gender:Male
  • Location:Englandland
How does cross-commiting work? I've documented S1's sound driver in the master branch, and want to begin improving the AS branch's using AS features. The thing is that commits made to the master branch aren't 'merged' with the AS branch, and I know that if I manually commit the changes to the AS branch, GitHub will say that the AS branch is both 1 commit ahead and 1 commit behind the master, ahead because of its own copy of the commit, and behind because of the master's copy of the commit.

#18 User is offline GerbilSoft 

Posted 22 July 2014 - 10:31 AM

  • RickRotate'd.
  • Posts: 2705
  • Joined: 11-January 03
  • Gender:Male
  • Location:USA
  • Project:Gens/GS
  • Wiki edits:5,000 + one spin

View PostClownacy, on 22 July 2014 - 08:36 AM, said:

How does cross-commiting work? I've documented S1's sound driver in the master branch, and want to begin improving the AS branch's using AS features. The thing is that commits made to the master branch aren't 'merged' with the AS branch, and I know that if I manually commit the changes to the AS branch, GitHub will say that the AS branch is both 1 commit ahead and 1 commit behind the master, ahead because of its own copy of the commit, and behind because of the master's copy of the commit.

On your local clone, do a full 'git fetch --all', check out the AS branch, and do one of the following:

1. Full merge:
git merge --no-ff origin/master


2. Cherry-pick:
git cherry-pick -xe (commit-tag)


Cherry-pick allows you to merge individual commits, whereas a full merge merges all changes. In the case of a single commit, a full merge should work fine.

You can then push the changes back upstream.
This post has been edited by GerbilSoft: 22 July 2014 - 10:41 AM
Reason for edit: `git fetch --all`

#19 User is offline Clownacy 

Posted 22 July 2014 - 03:44 PM

  • Layin' the Wax and Spinnin' the Sounds
  • Posts: 629
  • Joined: 06-July 13
  • Gender:Male
  • Location:Englandland
Even with cherry-picking, GitHub counts the commit as another commit to put AS ahead of master, instead of subtracting 1 from the commits that put AS behind master.

#20 User is offline GerbilSoft 

Posted 22 July 2014 - 03:52 PM

  • RickRotate'd.
  • Posts: 2705
  • Joined: 11-January 03
  • Gender:Male
  • Location:USA
  • Project:Gens/GS
  • Wiki edits:5,000 + one spin
It's always going to be ahead of master until you merge the changes back.

It's not really that big of a deal though, since it goes away once it's merged back to master.

EDIT: ...if the AS branch isn't actually going to be merged back from master (I.e. considered completely separate), then something's wrong. That's usually not how git development works. Maybe it'd be better to use some macro trickery to split out AS-specific code from asm68k-specific code in a single codebase?
This post has been edited by GerbilSoft: 22 July 2014 - 03:53 PM
Reason for edit: That's not how it works. That's not how any of this works.

#21 User is offline MainMemory 

Posted 22 July 2014 - 03:59 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 3767
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339
That would make the disassembly unnecessarily huge, considering I don't think the MapMacros branch will ever be merged into master either. Also making a disassembly multi-assembler compatible would require putting half the code in if/else blocks.
This post has been edited by MainMemory: 22 July 2014 - 04:04 PM

#22 User is offline FraGag 

Posted 22 July 2014 - 07:35 PM

  • Posts: 659
  • Joined: 09-January 08
  • Gender:Male
  • Location:Québec, Canada
  • Project:an assembler
  • Wiki edits:6
I think it's fine to have diverging branches. Also, I updated the MapMacros and AS branches against master.

#23 User is offline Clownacy 

Posted 22 July 2014 - 08:37 PM

  • Layin' the Wax and Spinnin' the Sounds
  • Posts: 629
  • Joined: 06-July 13
  • Gender:Male
  • Location:Englandland
I've done some more research on this and I'm beginning to think it was the rebase command I was looking for. I've read that the merge command by nature creates an additional commit, which is what I was trying to avoid.

#24 User is offline GerbilSoft 

Posted 22 July 2014 - 08:47 PM

  • RickRotate'd.
  • Posts: 2705
  • Joined: 11-January 03
  • Gender:Male
  • Location:USA
  • Project:Gens/GS
  • Wiki edits:5,000 + one spin
Rebase rewrites the branch history, which can cause problems for anyone who's using that branch.

#25 User is offline FraGag 

Posted 22 July 2014 - 08:48 PM

  • Posts: 659
  • Joined: 09-January 08
  • Gender:Male
  • Location:Québec, Canada
  • Project:an assembler
  • Wiki edits:6
We should not use rebase here. Rebasing a published branch is highly discouraged, because rebasing recreates the commits on the branch, and pulling a rebased branch tries to merge the old commits with the new commits by default (pull --rebase might get confused too). If you made local changes on a branch and some commits were pushed to the branch on the public repo before you got to pushing your local changes, rebasing your local branch is a good idea (it keeps the history linear). But for a published branch, it's easier for everyone to avoid rebasing.

#26 User is offline Clownacy 

Posted 30 July 2014 - 07:58 PM

  • Layin' the Wax and Spinnin' the Sounds
  • Posts: 629
  • Joined: 06-July 13
  • Gender:Male
  • Location:Englandland
Bump. As of the latest commit, the AS Sonic 1 branch is now producing bit-perfect REV01 builds. The REV01-only code has a bunch of branches with undefined sizes. It seems that asm68k doesn't give them any thought and automatically makes them word-sized, while AS optimises a few of them to byte-sized, causing differences in the built ROM that we don't want.

I fixed that, but still managed to mess it up. I'm just gonna use Git Shell from now on, that other program, the GUI thing, managed to not check for the whole 'MERGE_MODE' thing, and pushed it as a separate commit. Dammit.
Making real good use of my Techie privileges aren't I? :v:
This post has been edited by Clownacy: 30 July 2014 - 08:00 PM

#27 User is offline Clownacy 

Posted 04 August 2014 - 08:53 AM

  • Layin' the Wax and Spinnin' the Sounds
  • Posts: 629
  • Joined: 06-July 13
  • Gender:Male
  • Location:Englandland
There appears to be a problem with S1's AS branch's p2bin.exe. It gives 'Overlapping Memory Allocation' errors when zero-offset optimisations are disabled, likely to do with the org usage in insn1op and insn2op. Replacing the branch's bundled p2bin.exe with the S2 disasm's s2p2bin.exe stops the warnings from appearing. I have little to no understanding of the build process, but to me it seems that there's some kind of workaround or exception for the zero-offset optimisations in s2p2bin.exe that p2bin.exe lacks.

If anyone with the right know-how can implement the feature into p2bin.exe, then the build process can be made a bit nicer: Right now, I can't get build.bat to output an error log because every build would be interrupted and stopped because of these warnings.

#28 User is offline MainMemory 

Posted 04 August 2014 - 10:59 AM

  • Every day's the same old thing... Same place, different day...
  • Posts: 3767
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339
I've added source code for a modified version of s2p2bin that doesn't worry about compression or .h files, but it seems to fill padding with 00 instead of FF.

#29 User is offline Clownacy 

Posted 04 August 2014 - 03:58 PM

  • Layin' the Wax and Spinnin' the Sounds
  • Posts: 629
  • Joined: 06-July 13
  • Gender:Male
  • Location:Englandland
Er, okay, how about this? I don't speak this language (C++?), not at all, but I copied a block of code from s3p2bin.cpp and it seems to work.

#30 User is offline MainMemory 

Posted 04 August 2014 - 07:14 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 3767
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339
I decided to implement my own fix for it, which is fully built and integrated to the win32 build process in the latest commit. Speaking of custom p2bin versions, I extracted all of build_source.zip in the S2 disasm into a build_source folder, and edited the Linux build scripts to not extract the zip (at least that's what I think I did).

  • 3 Pages +
  • 1
  • 2
  • 3
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users