Project Artemis

[Lazy Bastard]

Sure, please do. And, let me know which game this works for (or I suppose I could modify it to hook the appropriate syscall for whatever game I'm trying to use it for)...

[Gtlcpimp]

Yes, computers only do what they are told. But the issue here is that the computer is being told what to do by the game and the homebrew app, at the same time, rapidly.

Let us know when your source is "ready"; it could help the project considerably.

The reason why I say it's not "ready" at the moment is because it is very very touchy. It requires the .ELF to stay completely on memory when the game is executing (which is easily taken care of by putting it really low or really high in RAM), but for some reason if it crosses a certain general size or a lot of functions it will screw up the in-game debugging abilities. I can get it working nicely for a single game, but when I put in a function or two that allows it to work on multiple games it completely messes up the in-game debugger. I'm still trying to get it to be stable so then the .ELF can have all the stuff in it that it needs and still be fully functional for debug use in-game. I can slap together a quick little source that just prints "Hello" in the middle of the screen and upload that for ya if you want to work on it or take a look at how it works.

[Lazy Bastard]

Yes, computers only do what they are told. But the issue here is that the computer is being told what to do by the game and the homebrew app, at the same time, rapidly.

Let us know when your source is "ready"; it could help the project considerably.

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

[Parasyte]

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

[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]

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.

[Lazy Bastard]

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

[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

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

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

[misfire]

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

[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

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

[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