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).
orcaloverbri9, on Jul 21 2005, 06:59 AM, said:
That's not entirely true. For instance, while ATI makes, say, a 9600 for Windows computers (PCI or AGP), as well as one for Macs (possibly even seperate ones for seperate models), you will find that other than power and VRAM, they are very different.
However, just because the new Macs will be x86, doesn't mean they'll have AGP, PCI, PC, PS/2, Serial, etc. support - on the contrary, I'd be very surprised if they did. This is the main reason Windows would need modifying to run: unrecognized hardware input. View Post
The only different between video cards on Macs and PCs are the software on the video card itself.
The Real Darth Bob, on Jul 23 2005, 01:28 PM, said:
They'll definitely have PCI. Although AGP is being phased out by Intel and the Graphics Card manufacturers so you'd only see that on a couple of the earliest MacIntels. However, Windows doesn't need PS/2 or Serial to run, and since the only real motherboard difference I can see (beside ports Apple with have Firewire, and no PS/2) is somesort of ROM to keep OS X only on Macs.
Hmm...I suppose I was a bit too generic. By PCI, I meant the standard card slot used for graphics cards, cound cards, etc. commonly found on Windows computers, not the actual interface itself, but it makes all the difference to anyone but the most advanced users.
Quote
The only different between video cards on Macs and PCs are the software on the video card itself
I'm inclined to disagree. Software aside, I'm pretty sure you can't take an FX5200 out of a Dell and install it on a G5 without some difficulty. Yes, it probably is PCI, but the hardware interface matters too, not just the software interface.
EDIT: Hmm...taking a look at the back of a G5, it appears I may be wrong, but eh. Whether standard PCI cards would work anyhow or not, don't be surprised if Apple chooses a new hardware architecture to get more money.
This post has been edited by orcaloverbri9 : 24 July 2005 - 04:45 AM
orcaloverbri9, on Jul 24 2005, 04:38 AM, said:
Hmm...I suppose I was a bit too generic. By PCI, I meant the standard card slot used for graphics cards, cound cards, etc. commonly found on Windows computers, not the actual interface itself, but it makes all the difference to anyone but the most advanced users. I'm inclined to disagree. Software aside, I'm pretty sure you can't take an FX5200 out of a Dell and install it on a G5 without some difficulty. Yes, it probably is PCI, but the hardware interface matters too, not just the software interface.
EDIT: Hmm...taking a look at the back of a G5, it appears I may be wrong, but eh. Whether standard PCI cards would work anyhow or not, don't be surprised if Apple chooses a new hardware architecture to get more money. View Post
You are aware that people will buy PC video cards and flash them with Mac software (that has drivers in OS X), right?
Soviet mikee, on Jul 24 2005, 08:43 PM, said:
You are aware that people will buy PC video cards and flash them with Mac software (that has drivers in OS X), right? View Post
Not many users have that level of expertise. Myself, a user and repairer of computers for 20 years, will not touch with a bargepole most of the flashing and modification routines to get some of the newer cards to work.
There won't be classic? Sh*t, practically all my programs run on that (all my games that are not Nova, that is :p)
Now I won't have Riven, Warcraft 2 or Asteroids... I bet I can switch to WC3 without too much troble, and I am sure asteroids will be OS Xed, but Riven was an old game and will not be updatd, and it is really cool (no action, but those of you who have played it get what I mean, and those of you who have played myst, it is the sequal and really 100s of times better)
This post has been edited by FedKiller : 25 July 2005 - 12:00 PM
FedKiller, on Jul 25 2005, 08:55 AM, said:
Now I won't have Riven, Warcraft 2 or Asteroids... I bet I can switch to WC3 without too much troble, and I am sure asteroids will be OS Xed, but Riven was an old game and will not be updatd, and it is really cool (no action, but those of you who have played it get what I mean, and those of you who have played myst, it is the sequal and really 100s of times better) View Post
Yeah, I get what you mean, but only sort of. I love all the Myst games, but I really didn't like Riven. Try Exile or Revelation, both are for osx. Revelation require's a hefty graphics card (and hardrive), though. But it comes with Exile in the case.
Luckily this won't hurt me much, as I usually use MissionComputer. And I really only play the occasional Classic game.
...ponders...
HOLY CRAP I WON'T HAVE MECHANISTO :mad:
FedKiller, on Jul 25 2005, 04:55 PM, said:
There's always realMyst and Myst III, IV, and V (at least there will be V by the time we have Intel Macs). It's a great series but these are the type of games which you generally don't play more than once, unless you missed something the first time. Or you could simply not through away your old computer and you'll be fine
nuku, on Jul 25 2005, 06:01 PM, said:
HOLY CRAP I WON'T HAVE MECHANISTO :mad: View Post
That's why if you get an MacIntel you don't throw up the old one.
Hey, where the heck are we people? Just Tech? Just Games? This is the EVDC for God's sake!
...the EVDC, but does that mean we have to go do it in a corner too?
Yes. Getcher ass in that damn corner, boy.
Since I have posted ViewRLE for beta-testing on the Nova board my programming skills are free again (feedback on ViewRLE so far: zero; I can assume there isn't any problem then...), so I investigated Rezilla's source code for the few problems we have noticed: - I found the reason for Rezilla's refusal to open locked files: the C++ code was only checking for one "file is locked" MacOS error code (namely, -61), which is indeed the one sent if you try to open a file from read-only media for writing (if you try to open a file on a CD-ROM with Rezilla, it will ask you if you want to retry in read-only mode), but another error code (-54) is sent if the file is locked by the user, which means in this case Rezilla doesn't offer to retry in read-only mode (I tested the codes returned by the OS with ViewRLE). I mailed the author about this issue and he answered this was indeed the right solution, - I investigated the crash I had found, it is apparently due to an access to NULL following a C++ dynamic cast on the pointer, my limited debugging means did not allow me to push the question further, I mailed what I found to the author so that he can continue the investigation, - I SOLVED the problem of flags going up one menu item, which ain't easy when one can't compile the code (doing so still requires you to own CodeWarrior, even if you can now compile with gcc you need Metrowerks' PowerPlant library that comes only with CW). I'll spare you the details, just know that I found a suspicious +1 too many in the source code, and to fix it I directly hacked the executable thanks to my knowledge of PowerPC assembly and HexEdit's PowerPC disassembly feature. I ran the hacked copy and this behavior disappeared, I mailed this info to the author. Also, he told me that he would modify the CASE to accept hexadecimal too (makes sense, especially for WORV)
EDIT: just in case you want to test that 13374 fix for yourself (or you want to make people believe you're an 13373 h4x0r ), take Rezilla 1.0.7 (a different version won't work since the byte to modify won't be at the same offset), make a copy of it, open the executable RezillaCopy.app/Contents/MacOS/Rezilla with HexEdit, and modify the byte at offset 0x0D1BBF from 0x01 to 0x00 (if you want to be sure it's the right one, it's surrounded by A0 5F 00 90 7C 7D 1B 78 38 9F 00 94 3B C2 00 01 <- this one to change to 00 38 61 00 48 3B E0 00 00 38 A0 00 00 48 04 E8 55). Make sure you don't shift the remainder of the file, its size should remain 0x253AFC! (end of edit)
The author also told me he downloaded Nova to investigate the last two bugs (of course, it's no longer an issue for the latter...). So, we're going somewhere people! Don't expect fixes too soon: in the latest version he said the next, numbered 1.1.0, would include the plug-in architecture, but he told me this would take time as he hasn't settled in the plug-in interface yet and Real Life ™ is keeping him busy. In the meantime, I'm studying the ResEdit plug-in interface (to know what to change in NovaTools) and CFPlugin (on which Rezilla's plug-in interface will be based). I'm not releasing other new templates, I'm waiting for the bugs to be fixed first (wouldn't really make sense to use buggy templates...), but I'm experimenting with some stuff (keyed sections) and it is promising.
This post has been edited by Zacha Pedro : 26 November 2005 - 03:25 PM
Some news...
Almost in time for the first Intel Macs (which came sooner than I thought they would, I was expecting Steve at MacWorld to present the models that would ship in february-march, at best), I have made significant advances. Just be aware that it ate away all my weekend time.
First, I have tested keyed sections. It's great! You can have the different descriptions and formats of ModVal for each oütf ModType. No longer one has to guess what to put for a cloak or cloak scanner, you have explicit fields as in Mission Computer. The UI is a bit of a problem (not that I can do much about it...), that is you set the key value (here, the value of ModType) once and cannot change it afterwards; to do this there is no other way other than creating a new resource with a different value and delete the old one. This is not much of a problem for oütf since you usually already know what your oütf should do, and even if you need to change it (or need to change ModVal 2 or 3 to do something else than "nothing", to add a feature to the outfit), there is not much else in an oütf resource so this is not really time consuming to create a new one and copy the old data.
But that I had already done a few days ago. Yesterday, on the other hand, I have been able to compile Rezilla myself. As you may know, it uses CodeWarrior and its PowerPlant library. I have been able to download an evaluation copy of CodeWarrior to get the PowerPlant library, so then I tried to compile Rezilla with ProjectBuilder/gcc. The author had already successfully compiled with XCode/gcc, but he only provides project files for XCode 1.5 and 2, not PB, so I had to recreate the project (with all the files that were to be included, set up of options, of prefix headers, or targets). It took some time. But eventually I have been able to compile the code (a few issues with resources remained, but I solved this by copying the resource files from the distribution, into my build, until I find a better solution).
What does this mean? Well, this means that I can test modifications to the code to see if that would indeed solve the bugs. I had already solved one, but it was obviously a hack. I am pleased to report that today I have solved all three of the bugs mentioned above (the reason for the crash and the fix are pretty involved). I have right now a build of Rezilla that does not have any of them. Before you ask me to send it to you, know that it isn't that easy. First, I am not 100% sure everything needed is in the project, there may be some resource, or worse, code, missing, which would likely crash the app when they get called. Second, I'd like to ask the author before spreading custom builds around (even if it's open-source, this is best practise). Third, there are some problems involved with the PowerPlant library; I only have an evaluation version of CodeWarrior, and I'm pretty sure it doesn't allow me to use the lib as I desire. I think it is their intention at Metrowerks/Freescale to open-source it when they'll drop CodeWarrior for good (right now, they sell it at bargain price without support, though everything is relative when one talks about "bargain price", and I have no intent to spend the money on something I'll have little use of) by not selling it any more, so they likely wouldn't really mind, but this is the kind of risk I'm not willing to take. I may still do it once I've cleared the way, though, watch this space.
At any rate, I'll send the changes back to Rezilla's author so that he can integrate them in the next version (hopefully soon...). Now that these bugs are out of the way, I'll work on crafting more templates, though they won't really be useful with your buggy Rezilla. As a tease however you can get the new oütf one (which shouldn't give any issue other than flags going up, and even that you can fix). It's pretty enormous (for a template of course, it's only 20kb) since it has four times (for the four ModTypes and ModVals) 50 or so descriptions and fields for as many ModTypes, so be careful when you view it or edit it, Rezilla will be pretty slow at times. I binned and zipped it thanks to orca, for it to survive the mighty perils of the 'Net. Just put it in (~)/Library/Application Support/Rezilla/ (or copy and paste the TMPL resource to the resource file already there), quit Rezilla, and relaunch it.
outfTMPL.bin.zip (2.75K) Number of downloads: 56
"Modval is obviously ignored" The cloak editor is very nice indeed. Though maybe say things like "(max 15)" instead of "(4 bits)" and "Deactivate when hit" instead of "Deactivation when hit flag". The fixed modtypes is a bit of a bummer. Maybe you could have a second primitive template which you could open the outf with if you needed to change it.
Guy, on Jan 15 2006, 09:34 PM, said:
"Modval is obviously ignored" The cloak editor is very nice indeed. Though maybe say things like "(max 15)" instead of "(4 bits)" and "Deactivate when hit" instead of "Deactivation when hit flag". The fixed modtypes is a bit of a bummer. Maybe you could have a second primitive template which you could open the outf with if you needed to change it. View Post
I can't do anything about "4 bits" either, it's added by Rezilla. I like the idea of the second template, it would just need to get a different name (so as not to conflict) and you would explicitely select it with "Edit as...". In fact you can use the original ResEdit template for that purpose. I'll include a slightly modified version of it (with CASE popups to help the user) with a different name (which one?) in the completed templates distribution.
By the way, some advice for people willing to do Rezilla templates. You have to do them in Rezilla since ResEdit won't accept to save TMPL resources with tags it doesn't know about. But Rezilla is a little buggy when it comes to edit resources with a variable number of fields (I reported it but not talked about it here since it doesn't affect us directly, all our custom resources are of fixed size, except dësc but only the text length changes) such as TMPL: when you add new fields to the TMPL resource, if you add them at two different places in one editing session, this corrupts the resource (from what I've been able to gather it seems it messes up the numbering of text fields, which means the data doesn't end up in the right place when gathering it from the editable text fields), and you don't realise it until you close the resource window and reopen it. So my advice is to add a few consecutive fields, save, close the window , reopen the resource, fill in the new fields, save and close the window (can't harm), as you're at it save the file, reopen the resource and repeat. Closing the window is important to revert back to a pristine state as far as field insertion is concerned.
Another thing is the following: you cannot copy-and-paste groups of fields. Do you think I retyped the 50 or so descriptions and fields for all four ModTypes (minus weapon and ammo for ModType 2-4), which would be more than 800 tags? Of course not, I already got crazy enough doing the first 50, especially as after doing this huge work I realised that, when editing the resource, Rezilla doesn't remind you of which ModType it is (weapon/cargo expansion/ammo/etc), it just shows the number, so I had to add 50 comments, one to each, with the ModType name! So in fact, after completing the first 50 keyed sections, I opened the resource in the hex editor (something I had already done before to salvage usable data from a TMPL corrupted due to bug above), and copied and pasted (with care) the data, in place for the other ModTypes. It might be useful to you to sometimes do things in the hex editor, though you should be careful - if you don't know what you're doing, edit a copy or don't do this at all, as you could lose your previous hard work.
Of course, this does not concern people who simply use the templates, they use them and everything will be well. But if you want to do templates yourself, then the info above can be useful.
Zacha Pedro, on Jan 16 2006, 04:40 PM, said:
You have to do them in Rezilla since ResEdit won't accept to save TMPL resources with tags it doesn't know about. But Rezilla is a little buggy when it comes to edit resources with a variable number of fields such as TMPL...
I've always wondered about that - I got so pissed off at Rezilla while testing TMPLs that I deleted it. Multiple times.
Perhaps we need a new TMPL editor?
This post has been edited by orcaloverbri9 : 17 January 2006 - 01:58 PM
Zacha Pedro, on Jan 16 2006, 10:40 AM, said:
I'll include a slightly modified version of it (with CASE popups to help the user) with a different name (which one?) in the completed templates distribution. View Post
Hm, tricky to create a descriptive name with only 4 characters. I suppose you could just use outf without the umlaut.
orcaloverbri9, on Jan 17 2006, 06:58 PM, said:
Perhaps we need a new TMPL editor? View Post
Editing TMPL resources HAS to be done in a template-based editor, for many reasons: - if you're writing templates, then you should be able to use a template-based editor. - it validates the template driver (though not perfectly in the present case...), if it doesn't work well then it'll be noticed real quick by the author when editing the TMPL resources - and, more generally, you eat your own haggis, whoever you are.
So, that rules any out any fancy graphical editor anyone might be thinking about. Now, if this Rezilla bug really pisses you, then you might be able to use EVONE for TMPL editing. But, by carefully following the procedure I described above, I have been able to create a monster of an oütf template (in fact, it's while I was doing this template that I came up with the procedure I described!), hex copying has only been done at the end. So, while you need to be careful, you should be able to do serious stuff with it. Remember: be paranoid. It's low on the priority of stuff to investigate and (now) debug, since it doesn't affect the end user and we can work around it, but I'd like to do it if I get the time.
You know I've got to wonder something, so excuse me if I'm noobishly technically challenge but umm... What are the chances of being able to run an emulater within an emulator, meaning, running Classics Environment in Rosetta, is that even possible?
Coraxus, on Jan 20 2006, 08:42 AM, said:
<snip> View Post
It'd be possible if Apple thought people still generally use old programs. But Rosetta won't have support for Classic, which is why Zacha is so mind-bendingly awesome for doing this for the rest of the community.