terrible idea for a gimmick hacking tool
-
@foone you need to target specifically armv4t. Most assemblers will target armv7a/armhf or possibly armv6k/armel. (Yes I know that armv7a ≠ armhf and armv6k ≠ armel, but usually an assembler or compiler will default to one pair or the other.)
-
@foone alternatively, I can probably just write some mini hacks
-
@endrift nah I got it, I'm using arm-none-eabi-as.exe from devkitpro with -march=armv4t -mthumb
-
It's amazing how much stupid automation you can develop when the alternative is manually editing 240 sprites
-
I wish I could script emulators worth a damn. They all seem to approach scripting from an almost antagonistic direction, like scripting is evil or something
-
but I'm doing the second best thing to scripting: INJECTING ARM MACHINE CODE!
-
@foone I know bizhawk started from a "scripting should be good" pov but it was kinda the first one to do it as a first class citizen so maybe went about it dumb? idk
Fun Fact: the core VERGE creators were also the original BizHawk creators (although everyone from the original team has moved on)
-
@grue oh neat! I didn't know that.
Anyway it makes sense, because bizhawk has moved on from being good. OOOOOOOOHHH!
-
My current hack changes the background color, skips an unskippable 1:30 cut scene, and I froze all sprites at animation frame zero.
But it's not enough!
-
maybe I'll move my process to native mGBA. I've been using bizhawk so far for TAS reasons, but my "TAS" is just "press A/B/Start a couple times until you get to the dialogue"
-
I can replace that with my old standby... a fake keyboard!
-
though I may just jam a crappy pseudo-TAS into my lua script. easier than getting a fake keyboard, especially since I physically cannot get to my fake keyboards right now
-
@foone mGBA has lua scripting now that can do that. It can even take screenshots for you automatically!
-
@endrift I know! I'm currently working on coding this
-
-
@foone obviously this means you need to make more (fake) keyboards
-
-
best way to make a TAS:
if frame == 730 or frame == 816 or frame == 930 or frame == 1090 then
press_a()
end -
now I need an algorithm to push these numbers smaller while still getting the same result.
like, play the rom, run this, take screenshot at frame 2000. then try lowering one by 5%, re-run, see if we get the same screenshot. -
why do things manually that'll take maybe 5 minutes when you could spend an hour writing automation to do it for you in 30 minutes?