Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
As I posted on the other ARES X topic, I'd love to head this project. I would at least like to know what is going on, if somebody else steps up and takes command. This is really, really freaking awesome, redsteven. Please contact me with news when you get it.
I'll need more than just quick batches; I need to know what kind of "special needs" the Ares data files need before I export them. I tried opening them in ResEdit and got 1s and 0s. I have all the necessary tools (I have a Windows machine networked directly into the Mac) I just need help from someone who knows what to do, like Edwards or Guy.
Now, I know we don't want to get ahead of ourselves, but.... I just wanted to post this stuff here so I don't forget about it later lol. In Nathan's email he made a reference to an Apple utility called "More Files", so i'm placing a link to it here. The apple support document for MoreFiles was last updated in 2003. It references "File Manager," so I'm placing a link to that here too. The File manager support document was last updated in 2007. Could be worse
I suggest you all head towards #ares on Ambrosia's IRC server. It would make real-time help more convenient.
EDIT scratch that, it needs a keyword.
This post has been edited by zamzx zik : 21 October 2008 - 10:13 PM
If I recall correctly, there was a time when #ares didn't require a key, and then it was relatively quiet.
...what's going on in there?
How about using #aresx? I just checked it out and it's open...
Well things have certainly been moving around here in the last day or so... Way to go guys
I have all the gear from my Ares plug building days. OS 9 etc. All mothballed and ready to go. I'm also runniig Photoshop CS3 so if anyone has any problems converting anything to anything ask and I'll help. I know a lot about the image end of things and nothing about coding!
I'll crack open Ares over the weekend and see what I can find inside it.
Let's not let this latest initiative die out!
Hey guys, Nathan Lamont pointed out that I left out some uh... rather important information. My apologies : \
From an email by Nathan on 10/17:
Quote
In any case, I don't want to waste my time unless there's interest by persons willing and able, so here's what I propose: I have a task that a person porting Ares might need to complete anyway, of some interest to me. If this task is completed, I will, at least find a way to make the source code to Ares available, provided there are no objections from Ambrosia.
The task is converting Ares' ancient sprite resources into PNGs.
I have put some files here: http://biggerplanet....sprite-code.zip
If there is someone who is genuinely interested in porting Ares to Mac OS X, they should be able to use the code there to decipher the 'SMIV' resource type, which represents the Ares sprite graphics. Each SMIV resource contains one or more frames of a sprite, typically a single ship rendered at multiple angles. If, for each SMIV resource, I am provided a png with each sprite in that resource laid out in an even grid, against an alpha background, without help from me, I will consider that enough skill and interest to make the rest of the source code available.
@redsteven, on Oct 22 2008, 06:14 AM, said in ARES X:
If what he's saying there is what I think he's saying, this will be harder than 10 people equipped with Adobe CS3 can deal with - it appears that these files are prototypes that Nathan Lamont made himself. That being said, I found these old Ambrosia topics on SMIVs: <1>, <2>, <3>, <4>, <5>.
It appears that some people were attempting to crack the format, but were unsuccessful in doing so.
If somebody could save me the time of downloading Ares, sticking it on an old Mac, and installing it and just give me all the Ares files, that'd be outstanding. Otherwise, it'll be a while before I can do that, and I won't be able to look at this SMIV format.
@adam_0, on Oct 22 2008, 10:09 AM, said in ARES X:
Well, since the linked file contains code that does just that, it might be a bit easier this time around.
@redsteven, on Oct 22 2008, 09:14 AM, said in ARES X:
Am i allowed to compete? after EV Nova * is easy.
@rudy, on Oct 22 2008, 03:44 PM, said in ARES X:
I'm not totally sure what you mean by that... Is * supposed to be "Ares?"
And there's really no competition here. It's a cooperative effort to do something awesome
Very much yes!
@adam_0, on Oct 22 2008, 09:09 AM, said in ARES X:
I just sent an email with a zipped version of the Ares Data folder to the email address in your profile.
But those files will be useless unless we figure out how to use that uncompiled SMIV decoder. I looked in the folder, and wasn't greated by a nice, friendly application.
I went through those five topics mentioning SMIV, and found a post mentioning putting that code into Quickdraw. Que?
This isn't something we can brute force do by hand using some image converter and Photoshop, Nathan put this to us as a test to see if we are truly worth his time. You can't trick him by handing him a file with a png of the sprites.
These files are C files. The .C means that is a C programming class file. That file will have the code for 'handling the sprites.' The .H is a library-type file in C. It has common declarations and constant values that get used a lot.
So, the guess is that the SMIV resource is the code wrapper that he made up to keep track of where on the sprite the different views are, and where on the sprite the weapons are fired from.
Therefore, what we really need is a C programmer who can take these files and and create the code wrapper which will then fetch the png files (that we convert) for the ships.
If we can do that, then Nathan will continue to help us - and only that. Sorry, but no brute force will win this one.
Having said that, I am not saying we give up. There are at least a dozen of us here, right? One of use has to have a friend who knows C. All the C I did was way back in the day, and I don't have the time to really re-teach myself. I can try, but it will take me some time - so if someone else knows C, that would be super.
-eveningtoast.
Alright, so our main mission now is to find someone who has at least basic knowledge of C
Glad to see so many people interested so far
I'm a fan of Ares (I bought it ages ago, it was great fun), and I know some C (but I'm by no means a programmer).
This code LOOKS like its the code that handled drawing things on the screen from the data files. Which means it is (somewhere) pulling data out of the resource files. Which means it SHOULD be possible to make it "run" and read all the sprite resources and dump them to a "screen" which is in fact a bitmap grid, which can then be saved as a file, and converted to a png (the bmp -> png should be trivial).
I've got no idea how OS9 handled multiple resources by IDs or whatever in a single file. For all I know the code that I think is picking which sprite to load is in fact directly accessing a memory mapped mirror of the game's sprite data.
As it is, I have no idea what the vast majority of the code does, its literally completely void of useful comments (ok, that's a line, there's a line here and there), given much of it I can take a wild guess based on the function names, and not be too far off--but that's hardly helpful for getting it to work. There's alot of other stuff there, and code pulled in from includes, and at lease one large block of assembly that may/may not be remotely meaningful to a non-ppc chip.
I don't have a machine that can run OS9 (ok, that's a lie, I have several, most of them are broken or missing too many pieces to turn on--or they're running linux). I don't know if its possible, but it MIGHT be useful to somehow get gdb to run on the ares game itself and attempt to see if we can track how things are being called. Though, the only time I've had that work was on very simple things, and only in a capacity to verify something I already suspected.
Someone might want to look a bit harder at how the code is displaying stuff to screen (if it is) it is most certainly accessing positioning and scaling graphics, I strongly doubt nathan would have given us code that didn't at LEAST read/decode the stuff we're after.
For starters, I assume that IF the sprites are stored (however SMIV stores them) in a grid like EV's PICTs; which actually I think they have to be, because I think some of the carriers had sprites that weren't exactly top down--unless they're 3dmodels, which they aren't, then it would likely be most productive to figure out how to get a SINGLE position (IE like the straight-up index position zero in EV in the upper left corner) non-animated image out of ANY SINGLE sprite into SOME other image format, I think BMPs would work well for this, and worry about generating pngs/masks/whatever afterwards.
From being able to pull out a single image, it should be (far less complicated) to procedurally pull out every other and reconstruct whatever we want from them.
At any rate, until someone (that isn't me--not that I wouldn't try, but I don't have time these days) can figure out how to access resources in an OS9-type program file, everything else is speculation.
Somebody should also figure out what the compile environment on OS9 is/was like, IE, what headers belong to the compiler, what/where they are/comefrom/do. I personally have no idea.
Sorry this is so long-winded circular and probably ~51% wrong, I also think I repeated myself numerous times, oh well--Like I said, its a guess based on a first pass go-over of the code, no prior knolage of what it does.
I should also say NOW that I'm not currently able to commit to helping on anything in a serious capacity. In the kind of capacity where I can jump in do something and vanish without warning I'll gladly help when/where I can.
-TLTMAA
@tolazytomakeanaccount, on Oct 22 2008, 05:58 PM, said in ARES X:
There's alot of other stuff there, and code pulled in from includes, and at lease one large block of assembly that may/may not be remotely meaningful to a non-ppc chip.
Actually, looking at the compiler commands around it, it's meaningless to a PPC chip, too- that's apparently 68K assembly, and the C version of it is the function immediately preceding it. Which is good, as assembly is a pain to read (although that's actually the best-documented code he gave us, so it may well be worth reading through anyway).
I kind of wish I had the time to spend working on this, as it looks like an interesting challenge, but unfortunately I have too much stuff to do this semester (I'm just taking a short break from staring at rocks through a microscope for hours on end right now).
- Edwards
@edwards, on Oct 22 2008, 09:44 PM, said in ARES X:
I've got the code compiling, i did have to stub out 10 functions that may or may not be needed in order to accomplish NL's task. I also threw together some code to generate the png files, its rough and doesn't do any of the simple calculations for determining how big to make the context based on how many sprites there are and their dimensions. /me now goes to sleep so he can fix Defcon and relax by working on EV Nova tomorrow.