Kodewerx

_________________

Being required to learn Java for a Comp Sci MAJOR is like being required to shit on a lawnmower to be an astronaut.

Dude I would LOVE an excuse to take a dump on a lawn mower D:

_________________

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. <_< >_>

_________________
143
HyperNova Software is now live (but may take a few tries to load) currently down; check out my PSP/DS/Game Boy/Windows/Linux homebrew, ROM hacks, and Gameshark codes!

This is easier than writing an assembler.

So far the only things I've noticed that need fixing are:


Also, I don't like the tabbing at the end of this:


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.

_________________

Renegade already assembles directly into GS code format. Using a C compiler is far less efficient than straight assembly, any way.

_________________
I have to return some video tapes.

Feed me a stray cat.

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.

_________________

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?

_________________
I have to return some video tapes.

Feed me a stray cat.

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. >.>

_________________

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.

_________________
I have to return some video tapes.

Feed me a stray cat.

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.

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...

_________________
143
HyperNova Software is now live (but may take a few tries to load) currently down; check out my PSP/DS/Game Boy/Windows/Linux homebrew, ROM hacks, and Gameshark codes!

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.

_________________

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.

_________________
I have to return some video tapes.

Feed me a stray cat.

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...

_________________

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.)

_________________
I have to return some video tapes.

Feed me a stray cat.