Golden Sun Hacking Community
June 24, 2017, 06:55:39 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
  Home   Forum   DC Wiki Help Search Calendar Downloads Login Register  
Pages: [1]   Go Down
  Print  
Author Topic: Android/iOS/PC Porting...?  (Read 335 times)
0 Members and 1 Guest are viewing this topic.
Claros Flamestrike
Of the Vibrant Life
Mars Clan

Living vibrantly since 1989.™

Regular Member
*

Coins: 0
Offline Offline

Gender: Male
I am: cringing so hard, I think my face is stuck like this forever. Thanks, 2011 version of me! >_< lmao
Posts: 104

« on: April 25, 2017, 02:37:45 AM »

Okay, question for all you nerds who know assembly code. (Because I'm lazy and have no idea how to learn that crap. lmao)

I am looking into porting various games to different OSes through what I call "wrapped emulation". Dunno what it's actually called, but it basically entails running an emulator with a frontend to allow parts of the emulated game to be changed/edited/etc on the fly, usually via RAM or hard-mods to the game's code. I want to see if it's possible to do something like this with multiple games, (like porting Final Fantasy games to Android, but making them less @#$%), but I will use Golden Sun as an example, since it's both the topic of this forum and a game I want to do this with.

In Golden Sun, there are many windows/menus. The Psynergy menu, the Djinn menu, the Start Menu... Et cetera. What I want to do is implement full point/click and hotkey support to it via the "wrapped emulation" concept that I mentioned above. Emulate the game, then live-edit the RAM from a frontend that contains the emulator. Would probably utilize screenspace pixel analysis to detect if a menu is open. Could maybe even do it on the scale of icons and whatnot: have the wrapper scan for certain pixel patterns that match up with an icon, then go from there. But that still presents an interesting problem: scrolling.

The way that GS handles menus is pretty standard for D-pad-controlled games: move the cursor, accept the choice that's highlighted, boom, new menu opens, action is queued/taken, etc. In my vision for this, it would jump directly to the option closest to where the screen was touched: tap on Status from the Overworld menu, and it instantly opens the Status menu, rather than having to hit Right or Left on a D-pad, then A. This is where you assembly code nerds come into play.

I was curious if anyone had dug around in GS's code for long enough to possibly know where to find the pointers for "open menu x" or "execute action y" or "select item z on list a". More than likely, such things could be found in the RAM, much like how the Debug commands can be added to the Start menu by changing just a single address via memory editing. And that is my preferred way of doing this: create a wrapper that intercepts the RAM and live-edits the addresses based on user input. "If address a is set to value b, then create button at (x,y) that changes address c to value d upon use." Something like that.

So, in simpler English: I need the RAM addresses for "is menu a open", "open menu b", and "select list item c" for every menu in the game. I also would need to know more about how Golden Sun handles lists and menu items: is it a simple array that includes the values of whatever is in that slot? ("Slot 0 = 180 x 5, Slot 1 = null, Slot 2...") Or is it more complex? If anyone knows this stuff and could dump a collection of it for me, I'd love them forever. (I already love all of you forever, so it's kind of a moot point. But still!)

If anyone is confused and has any questions, feel free to ask! I might not reply right away, (lots of IRL stuffs going on right now; this is just something that I've been thinking about lately), but I will get back to you as soon as I can.

Anyway, cheers for now! =D?

- 2br02b, 2017

EDIT 1: I also would like to figure out point/click movement, but that can come later; a virtual joystick or WASD will suffice for now. *shrug* lol

EDIT 2: It also occurred to me that I could probably learn assembly code, specifically for GS, if someone has a link or download for a comprehensive tutorial on the language. I've been looking around the web for anything of worth, but I can only find old machine code stuffs and one very old, pre-2000 tutorial site on GBA assembly code that is so shoddily formatted that I can't understand it, at all. So any information about reading materials that you guys have or have used in the past would be appreciated! =D?
« Last Edit: April 25, 2017, 04:49:47 PM by Claros Flamestrike » Logged
View Profile WWW
Fox
Fox McCloud, the Hacking Doctor
Mercury Clan

Prodigy
*

Coins: 25
Offline Offline

I am: certainly not a Gallant!
Clan Position: Head Gallant
Posts: 2306

« Reply #1 on: April 26, 2017, 12:51:35 AM »

I not big on pixel analysis if there are other ways of doing it.... so umm.... yeah.

@EDIT 2 = Looking for the GBATEK bible...? It's a very precious source of information that should not be understated... GBATEK bible to the rescue! (Literally my favorite page for GBA and DS research.)

There is also the Thumb guide. http://forum.goldensunhacking.net/index.php?action=downloads;sa=view;down=27
 You could look at ARM, but isn't really necessary. (Some things like decompression routines may often use ARM, though.)
mov r3, 0x20 would be the same as r3=0x20 (Assume r#'s are just variables containing any number they have in them... usually the result goes in the first register listed depending on the instruction. In this example, that's r3.)

If the value was known, I could make that into more easily readable code like: mov hp, 0x20 (Might not be valid?) ... to kinda/sorta say the registers are just as much variables as in any other programming language (They can be set to values, they can be retrieved/etc.) ...
r0-r7 = General purpose
r8-r12 = General purpose ... Hi-registers ... In Thumb mode, only certain instructions can access them.... but should be available to the majority of ARM instructions.
r13/sp = Stack pointer (Most games have it, so get use to seeing it... Pointer to where to store information when you don't have enough registers... basically.... It's common to push/pop values in/out of here so functions have registers they can use. When calling functions, r0-r3 would be the arguments, if you have more than 4 arguments, they are stored in the stack... when the function is done with, the return value goes in r0 if there is one. (Sometimes you can have a second return value.. (r1... like in division)... but it is very rare.)
r14/lr = Link Register (Pointer to where you return when function you are in ends.)
r15.pc = Program Counter (Current place in execution.)

« Last Edit: April 26, 2017, 01:49:57 AM by Fox » Logged

Golden Sun Docs: Broken Seal - The Lost Age - Dark Dawn | Mario Sports Docs: Mario Golf & Mario Tennis | Misc. Docs
Refer to Yoshi's Lighthouse for any M&L hacking needs...
View Profile
Claros Flamestrike
Of the Vibrant Life
Mars Clan

Living vibrantly since 1989.™

Regular Member
*

Coins: 0
Offline Offline

Gender: Male
I am: cringing so hard, I think my face is stuck like this forever. Thanks, 2011 version of me! >_< lmao
Posts: 104

« Reply #2 on: April 26, 2017, 03:51:24 PM »

@GBATEK: That looks MUCH cleaner/better than the one that I had found before. And it's for GBA, specifically, too, unlike the other one. (The other one was generalized assembly code stuffs, which probably wouldn't have helped, anyway.) So thanks for that. I'll look through it when I get some time. The THUMB chart should be interesting, too, considering the "if you have troubles understanding GBATEK" part in the description. With both, I should have no problems at least getting into it. So thanks for that!

@pixel analysis: I agree. But it was the only way that I could think to do it sans the assembly or RAM stuffs needed to hardmod it into the game. If we can get it all implemented through the game, a full wrapper might not be needed: just the input overlay to handle (x,y) clicks and scrolling. That would be nice. I'm just not sure how it all would work. With a headstart on GBA assembly code, though, I can at least get a look at it from the perspective of the game and figure some stuffs out on my own. But if anyone still wants to dig around for those menu addresses, though... >_> lol?

Anyway, thanks again. Got the THUMB chart downloaded and the GBATEK page bookmarked. I'll follow up here if I figure out anything/have any questions. =D?
Logged
View Profile WWW
Fox
Fox McCloud, the Hacking Doctor
Mercury Clan

Prodigy
*

Coins: 25
Offline Offline

I am: certainly not a Gallant!
Clan Position: Head Gallant
Posts: 2306

« Reply #3 on: April 27, 2017, 05:38:11 PM »

@GBATEK/thumb guide = You are welcome.

@pixel analysis = Umm... yeah... Since we're talking about clicks, it would have been cool to have converted GS into a DS game, but that's probably more difficult than it sounds?
But yeah, I figure having it implemented int the game itself, it could reduce the need for unnecessary execution. (e.g. Instead of checking if a menu is open for the life of the game, you could simply embed the code in the menu itself.)

@menu addresses = Well, general locations of most things have likely been documented (With the exception of anything we forgot about? -- Map code, while some was documented, has mostly been left alone.) -- So I don't figure a whole lot of digging would be necessary. Especially with breakpoint debugging.

« Last Edit: April 27, 2017, 05:48:56 PM by Fox » Logged

Golden Sun Docs: Broken Seal - The Lost Age - Dark Dawn | Mario Sports Docs: Mario Golf & Mario Tennis | Misc. Docs
Refer to Yoshi's Lighthouse for any M&L hacking needs...
View Profile
Pages: [1]   Go Up
  Print  
 
Jump to:  

Cbox
Yesterday at 02:25:42 PM
Seto Kaiba: you know I miss how SMF is almost dead now because having 1pt text to hide my true feels was perhaps the best part of web 2.0
Yesterday at 04:19:13 AM
Fox: Alright. Sounds good.  I agree it does seem a bit silly.  Sounds more of an April Fools type of thing. (Maybe having an ability for people to change their names limitless times specifically on April Fools is an idea.)
Yesterday at 04:09:25 AM
Kain: Sala asked me about the name, I thought it was silly but agreed he could have it only for a week.  Tomorrow his name goes back to Salanewt.
Yesterday at 03:29:10 AM
Fox: And yay! Atrius is back! Thanks for the reply. Somehow I didn't notice the recuriveness before.
Yesterday at 03:25:29 AM
Fox: @ridiculous name for a week =  Hm? So, how many characters would you say should be the maximum to have a name "permanently"... or better yet... How many characters can a name have on registration?
Yesterday at 01:00:50 AM
Atrius: @Javi3, Lo siento, ya no tengo tiempo.
June 22, 2017, 08:57:37 PM
Fox: @conundrum = Think about 8/16/32 bit aligned address, and what that means... Etc.
June 22, 2017, 08:55:23 PM
Fox: @Space manager thought for gsmagic = What a conundrum... Whelp... I'll just do whatever.... Probably would waste more time thinking about preventing bugs than coding anyway. :P
June 21, 2017, 09:30:34 AM
Fox: Because he quit a long time ago and has other priorities?
June 21, 2017, 08:35:54 AM
javi3: Atrius, por que no sigues con el editor de golden sun?
June 20, 2017, 10:52:48 AM
Fox: It feels like the safest bet is to do Atrius's repointering system, and have something that organizes the tables done a bit separate... er... Well, it's something to think about.
June 20, 2017, 08:53:41 AM
Fox: HOWEVER... I can see other problems that might cause..... (Even with just the pointer in the MFT)  Meh. It's like you actually need a program to apply patches to do it appropriately.
June 20, 2017, 08:46:38 AM
Fox: ... So... What am I thinking? You ask? That the patches the point data after MFT, should have had pointers in the MFT themselves.... In that case, I can see a possibility of everything working smoothly even if space is needed to the very end of the ROM.
June 20, 2017, 08:37:22 AM
Fox: It's basically that everthink from the point of  editing, to the closest free space to the last entry's address would get repointed forward/backwards depending on space needed... and if space is mapped after patches are added, then that could mean the patches are also repointed. (:o)
June 20, 2017, 08:29:03 AM
Fox: Well, I mean if I map the space out the same way Atrius did it.
June 20, 2017, 08:26:41 AM
Fox: I have a hunch... when I add Map Palette editing the way I'm thinking about... it will cause all patches that repoint to after the MFT to break.... Especially if Atrius's editor wasn't used beforehand. Etc.
June 20, 2017, 07:27:17 AM
Fox: Hmmm... Let's see... regardless of method, I think I still do want to take some of Atrius's Space Manager code... Hmm.....
June 20, 2017, 07:07:27 AM
Fox: say*
June 20, 2017, 07:07:19 AM
Fox: I'd go so far as to see.. even if you are trying to be accurate, there could still be inaccuracies... However, that one was just an example where it was clearly intentional.
June 20, 2017, 07:04:03 AM
Fox: Like*

Affiliates
Temple of Kraden Golden Sunrise
Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.077 seconds with 22 queries.