Project Artemis

[Lazy Bastard]

Artemis now has a BountySource.com account: https://artemis.bountysource.com/

This will allow us to lay out goals (or "milestones", as I refer to them), and to reward developers with cash for their efforts, per milestone.

Thanks goes out to Parasyte, for pointing BountySource (and the concept behind it) out in response to my mentioning a reward system of some sort.

Anyway, go create an account (it takes about 1/3 the time it took you to register at these forums), and join the project. I'll begin adding tasks ASAP, and deciding on rewards for specific tasks.

[Lazy Bastard]

I'm only popping my head in because I want to get down an idea before I forget it overnight: Artemis should have the ability to restart the PS2, triggered by a button combination. This is quite a useful function for hackers (not having to manually restart the PS2), and is also just a nice function in general (Square has implemented it in their games quite a bit in the past, usually responding to the button combination L1+L2+R1+R2+Select+Start). The combination should be user-customizable.

Another option would be to make Restart PS2 a choice within the in-game GUI, so as to minimize button combinations that are in use (Artemis itself will be called by a button function, after all, and it's not easy to establish button combinations that definitely won't be used within a game).

[MIR]

I agree. i found that when i am running the Action Replay or the Gameshark the reset button on the console itself deactivates and becomes useless (except for the 10 second power down).

[misfire]

Artemis now has a BountySource.com account: https://artemis.bountysource.com/

This will allow us to lay out goals (or "milestones", as I refer to them), and to reward developers with cash for their efforts, per milestone.

Thanks goes out to Parasyte, for pointing BountySource (and the concept behind it) out in response to my mentioning a reward system of some sort.

Anyway, go create an account (it takes about 1/3 the time it took you to register at these forums), and join the project. I'll begin adding tasks ASAP, and deciding on rewards for specific tasks.

FYI, the sources can be checked out this way:

$ svn co https://svn.bountysource.com/artemis

[Lazy Bastard]

Yes, thanks for putting that out. I'd actually recommend using

svn export https://svn.bountysource.com/artemis

...to avoid grabbing all those SVN files/folders, which are generally of no use (as far as I can tell).

[Parasyte]

The SVN metadata has its uses. For example, when running commands such as svn diff -- just so SVN knows where the project was checked out from, and it can perform the diff on the requested revision (typically HEAD). In a distributed revision control system (git, hg, ...) the metadata is ESSENTIAL for these sorts of operations, because the entire revision history lives within it; there is no concept of "asking the server what revision X looked like."

But then again, using svn export is fine... Why bother using the revision control system if you're just bypassing it, anyway? :P

[misfire]

I agree with Parasyte. The SVN metadata also allows developers to easily commit changes from inside an IDE, e.g. NetBeans.

[Lazy Bastard]

Ah, I see. I figured it was something along those lines. But, it doesn't store data from all prior versions, does it (it would have to contain all prior versions)? Hence, it's only useful for diff, as far as I can see.

[Parasyte]

That's fairly close... But as I said, git/hg do include all prior versions in their metadata. That's the "big thing" which separates centralized revision control systems (cvs, svn, ...) from distributed (git, hg, ...) ones.

[Gtlcpimp]

With all of you guys working towards putting "Artemis" into action, whats the progress on it so far? I recently picked up one of my old projects that attempted to force on-screen drawing in the middle of game-play on any game, and worked out a few errors. I have managed to fix it and force on-screen drawing during game-play, but seem to be limited to certain methods of drawing. I am still working on a way to force re-initializing the controller in order to have a full debug interface while in-game, along with forcing the read / write of files while in game. Here pretty soon I will upload an example .ELF file to show you guys what I'm talking about. Has "Artemis" reached in-game on-screen debugging yet?

Edit: After recent testing, I have found that the original game's "Joker Address" is still updated upon controller input, so I now have a true full debug interface while in-game

[Lazy Bastard]

Interesting. That's actually one of the milestones to-be-accomplished in Artemis. Mind sharing your source?

[Parasyte]

I'm fairly surprised that any program which makes system calls (not to mention being written in C) in the middle of a game's execution doesn't cause a great deal of headaches. You have to be careful with that sort of thing, especially if the calls you are making are not thread-safe.

One example is interrupting file IO operations by making your own file IO calls in the middle of some file IO sequence requested by the game. If such calls are not thread-safe, many subsequent calls by the game could fail; and then everything explodes.

I had many difficult situations like this on GameCube. Even though the system calls themselves were thread-safe, they did not account for other processes accessing the hardware at the same time (thus, changing the hardware state). The only way I could mitigate the problems was attempting to restore hardware to the state before GCNrd began screwing with it.

And then again ... I was working at a much lower level, closer to ring-0. There was no operating system between GCNrd and the GCN to manage things like that; it was GCNrd between the game and the GCN.

But anyway, still surprising.

[Gtlcpimp]

It's not ready for a source to be publicly released, but here is a quick video I took of it while using it on "SOCOM: Combined Assault".


http://www.youtube.com/watch?v=EPXUgznS-Tc

It seems to be extremely touchy when adding a function to the source, and over limited on the graphics....

I'm fairly surprised that any program which makes system calls (not to mention being written in C) in the middle of a game's execution doesn't cause a great deal of headaches. You have to be careful with that sort of thing, especially if the calls you are making are not thread-safe.

One example is interrupting file IO operations by making your own file IO calls in the middle of some file IO sequence requested by the game. If such calls are not thread-safe, many subsequent calls by the game could fail; and then everything explodes.

I had many difficult situations like this on GameCube. Even though the system calls themselves were thread-safe, they did not account for other processes accessing the hardware at the same time (thus, changing the hardware state). The only way I could mitigate the problems was attempting to restore hardware to the state before GCNrd began screwing with it.

And then again ... I was working at a much lower level, closer to ring-0. There was no operating system between GCNrd and the GCN to manage things like that; it was GCNrd between the game and the GCN.

But anyway, still surprising.

When it comes to the PS2 and the System Calls or what not, I simply say screw it, preserve everything I can and do it anyway
As long as everything is returned back to normal state before returning to the game, no harm can be done right? Think about it...

[Parasyte]

Sure! Assuming it is actually possible to return things to their original state...

[Gtlcpimp]

Anything is possible. The PS2 is simply a computer, and computers can only do what you tell them to do. It's not going to corrupt vital game information unless you tell it to.