Kodewerx https://www.kodewerx.org/forum/ |
|
MIPS Parse https://www.kodewerx.org/forum/viewtopic.php?f=11&t=6161 |
Page 1 of 1 |
Author: | Hextator [ Sun Sep 28, 2008 6:27 pm ] |
Post subject: | MIPS Parse |
This application turns MIPS compiler output into Renegade compatible input. So anyway, I'm learning Java (lol Comp Sci major), and thought "I need this crappy output from my MIPS compiler to be converted to something I can use...what better excuse to learn more nuances of this shiny new language than write the converter in it?" It's very beta (like everything I release) Edit: mostly complete, but since it's Java, it's also very multi-platform! Yay! I think there might be binaries for other platforms of the mips-gcc compiler I found, too, so any platform that can run Renegade could benefit (if you want to call it "benefiting"). Source and compilers. * Cue snide comment from Para |
Author: | jleemero [ Sun Sep 28, 2008 6:30 pm ] |
Post subject: | Re: MIPS Parse |
Being required to learn Java for a Comp Sci MAJOR is like being required to shit on a lawnmower to be an astronaut. |
Author: | Hextator [ Sun Sep 28, 2008 6:57 pm ] |
Post subject: | |
Dude I would LOVE an excuse to take a dump on a lawn mower D: |
Author: | HyperHacker [ Tue Sep 30, 2008 9:05 pm ] |
Post subject: | Re: MIPS Parse |
Biofuel? You could shit in one. Maybe you could adapt this to strip all comments and labels that would confuse Renegade? It trips over them sometimes. Or maybe you could make an R4300 assembler. <_< >_> |
Author: | Hextator [ Wed Oct 01, 2008 8:57 am ] |
Post subject: | |
This is easier than writing an assembler. So far the only things I've noticed that need fixing are: Code: LHU T2, $80175B66 ; ADDU T1, T2, $FFFFFE0C ; LA A2, $FFF20000 (A3) ; Also, I don't like the tabbing at the end of this: Code: SLTI A3, T0, $01F4 ; I may run into some more issues along the way, but even as it is now, the output is easily mended. I have to go through it anyway to make human optimizations. If I were to write an assembler that looked for the optimizations the compiler leaves, the time it would take to do so would be counter productive. |
Author: | Parasyte [ Sat Oct 04, 2008 8:58 am ] |
Post subject: | Re: MIPS Parse |
Renegade already assembles directly into GS code format. Using a C compiler is far less efficient than straight assembly, any way. |
Author: | Hextator [ Sat Oct 04, 2008 9:23 am ] |
Post subject: | |
I've seen otherwise. This is for taking the resulting MIPS of the compilation of high level languages and turning it into something usable by Renegade or a ROM hack. So far it has saved me lots of coding time. Not only that, but the resulting MIPS code is forced to have good whitespace. ![]() When you can trade the time you'd waste getting a head ache over coding something more complex than usual in assembly for one or two unnecessary ORI's floating about your code and the ability to write it in C++ in a minute or so, I'd say you have an efficient alternative. Edit: Now has more error messages for help using the program correctly. Also has optimizations and better handling of things it didn't manage so well earlier. |
Author: | Parasyte [ Sun Oct 05, 2008 2:40 pm ] |
Post subject: | Re: MIPS Parse |
How have you seen otherwise? A good number of the assembly hacks Viper did exploit the fact that compiled high level languages are far less efficient than straight assembly. A general example is optimizing the poorly compiled assembly to create enough room to insert your own code. So if you had to hand-enter a rather large code, would you rather have saved a few seconds writing it in C, or saved a few minutes typing it with a controller? |
Author: | Hextator [ Sun Oct 05, 2008 5:02 pm ] |
Post subject: | |
No one hand-enters codes these days. Besides, if I give an option, that makes it an option, not a standard or the only way to do something. If you don't like it, ignore it. I on the other hand am happy saving lots of minutes at the cost of a few extra opcodes that are just going to be copy pasta'd anyway. Let's not forget; this is useful for ROHM acks as well. Edit: I think I figured it out. I'm too good at Halo and it drives you nuts. Is that it? ...what? That's why Lemma is always grumpy at me. >.> |
Author: | Parasyte [ Mon Oct 06, 2008 4:30 pm ] |
Post subject: | Re: MIPS Parse |
You're just oversensitive and take every piece of constructive criticism as offensive. Even if it's only slightly offensive, but mostly humorous. Of course, I could counter your argument by saying "well! you know you could always just ignore me." But that wouldn't help me to accomplish my goal of helping you produce something truly worthwhile. At least your intentions are good. |
Author: | King Rhyono [ Mon Oct 06, 2008 4:48 pm ] |
Post subject: | Re: MIPS Parse |
I love the shit you spew Zeld. <3 See, not constructive at all, he'll love it. Para's attempts to make him make worthwhile things is just silly. |
Author: | HyperHacker [ Mon Oct 06, 2008 6:49 pm ] |
Post subject: | Re: MIPS Parse |
I'd be worried about those extra opcodes pushing your already long codes further toward the limits of code handlers. I think the real GS only allows about 100 lines. You could circumvent this by dumping your code into unused areas, that won't be cleared by the game, using F1 codes, since they'll only execute at bootup. I do remain sceptical, especially having seen the shit Nintendo's compiler produces (unnecessary register transfers, NOPs, etc), that a C++ compiler can produce assembly anywhere near as efficient as hand-written code, and in this field efficiency is very important. If you really have gone through the code with a fine-toothed comb and found almost no cases where it could be more efficient, then I guess I owe a high-five to the guys who wrote that compiler. I wonder about the feasibility of a program that will go through your assembly and look for common optimization failures, maybe even fixing them automatically. I imagine they'd be fairly easy to spot, since it would make the same mistake every time. Now, in a ROM hack of a game that falls well under the 64MB ROM size limit, and has plenty of RAM available (particularly 4MB games), optimization is not such a huge issue, but you still have to be careful your code doesn't slow the game down. An interesting side note: recreating the game's structures in C++ like this is one of the first steps toward decompiling it back to source code... N64 games may be fucking huge, but most of that is data, and having been written in C/C++ using a common devkit, they may be easier to decompile than NES or SNES games. I've often wondered about how much of SM64 or MK64 is actually code... |
Author: | Hextator [ Mon Oct 06, 2008 8:24 pm ] |
Post subject: | |
As far as a ROM hack goes, this "system" works fine - I'd be comfortable throwing code I write in C++ straight into a ROM. As for using it for Gameshark codes, it probably has more optimization failures than any of you would tolerate, but next to my already long code I see little difference. It'd be kind of fun to use a code of mine on a real N64, but that's not happening any time soon. So, in the mean time, I'll just abuse Renegade's processing power. Applying this all to modern systems like the DS is feasible, too. Look at my aim bot code. It's f'huge and works fine, with plenty of room for other codes. In the past, yeah, optimization was a necessity. Now, I would think speed is more important. |
Author: | Parasyte [ Fri Oct 10, 2008 5:12 pm ] |
Post subject: | Re: MIPS Parse |
Several months back, I studied the N64 GS Pro's code handler generator and code parser. I documented this effort and discovered a lot of information which has been previously unknown, including a few new code types, and the upper limit of F1 codes allowed. Sadly! It is not in my development backups, so that means it's still on my Windows C: drive. (Which has been disconnected since that machine died months ago ... but data on the disk is still intact.) I also had some other documentation that I wrote for other cheat device code handlers. Especially with PAR for SNES, and the differences between versions. |
Author: | Hextator [ Fri Oct 10, 2008 7:18 pm ] |
Post subject: | |
All 3 of mu N64 Gamesharks no longer work. Figures I wouldn't have a cheat device now that I can make codes. Of course, they all stopped working years ago... Incidentally, I think they were discontinued years ago, too. Dandy. ...not that it isn't easier to just emulate the damn things... |
Author: | Parasyte [ Thu Oct 16, 2008 7:32 pm ] |
Post subject: | Re: MIPS Parse |
HyperHacker wrote: I'd be worried about those extra opcodes pushing your already long codes further toward the limits of code handlers. I think the real GS only allows about 100 lines. You could circumvent this by dumping your code into unused areas, that won't be cleared by the game, using F1 codes, since they'll only execute at bootup. Only 50 F0/F1 code types are allowed. (The documentation I mentioned earlier was never saved to my HDDs, apparently. But the info did make it into EnHacklopedia. See N64 GS Code Types.) |
Page 1 of 1 | All times are UTC - 8 hours [ DST ] |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |