No XP/DirectX10 work around possible with pcsx2?

[boogerthe2nd]

-Mac's are made for the hardware they use. That's why they use it more efficient. For example:
A 2Ghz Dual Core of a Mac is equvivalent to a 3Ghz Intel Dual Core
(that's how they convinced me)

That reads like typical marketing BS (no offense). Macs have been using Intel CPUs since 2006. A 2Ghz C2D in a Mac won't automagically gain 50% processing power over to a 2Ghz C2D in a PC. If any improvements are made, it has to be in the software department.

[Shadow Lady]

Testing an OS is a good idea for sure. I'm not that much into formating discs, but at least I know that I have to format the whole disc if I want to make a new partition.

Uh this is not true?

[KrazyTrumpeter05]

-Mac's are made for the hardware they use. That's why they use it more efficient. For example:
A 2Ghz Dual Core of a Mac is equvivalent to a 3Ghz Intel Dual Core
(that's how they convinced me)

That reads like typical marketing BS (no offense). Macs have been using Intel CPUs since 2006. A 2Ghz C2D in a Mac won't automagically gain 50% processing power over to a 2Ghz C2D in a PC. If any improvements are made, it has to be in the software department.

That, and Mac is known for underclocking their hardware for "stability".

Oh, and they only just released an update to their OS that let them make proper use of dual cores and 64 bit processor tech.

[Bauzi]

-Mac's are made for the hardware they use. That's why they use it more efficient. For example:
A 2Ghz Dual Core of a Mac is equvivalent to a 3Ghz Intel Dual Core
(that's how they convinced me)

That reads like typical marketing BS (no offense). Macs have been using Intel CPUs since 2006. A 2Ghz C2D in a Mac won't automagically gain 50% processing power over to a 2Ghz C2D in a PC. If any improvements are made, it has to be in the software department.

I can't disagree on that. You know where I heard about it? In a 3 hour long introduction to Mac software/hardware chourse.

There shouldn't be anything that isn't possible on a PC in terms of editing and effects. When it comes to 3D effects than the PC has great opportunities that a Mac hasn't (some programs like XSI).

I think Pros usualy don't really need Avisynth for filtering. I need it for filtering and processing DVD footage. A Pro gets the RAW material for working with it or makes the footage by himself with a camera. I guess they wouldn't need it that often.

On a PC you can use Avisynth everywhere as long as you can load in an avi file with Pismont File Mount System and a plug in. It eats quite a lot of RAM, but it works if you switch your working material (MJPEG and such...) with these high quality material for a final lossless encode. Oh well I could also convert my material into lossless video in the first place for working too...


People have Macs because of the usability, fancy design and because it's different. I dislike nothing more than people who just have a Mac to be different and look down on the "poor/lame mainstream" PC users =/


@Shadow... eh?
So I can split an already existing partition into two? Oh!

[boogerthe2nd]

You can use something like EASUS Partition Manager (which is freeware) to create another partition from your existing partition. You basically shrink your current partition and create a new partition using the free space that you end up with.

In Vista and Windows 7, you won't need any other software, you can do it using Disk Management under Control Panel > Administrator Tools > Computer Management.

[ph34rme]

Ok, I'm not trying to be deliberately obtuse here, but what exactly are the benefits of using a Mac, over using a PC with Avisynth, Virtualdub, Sony Vegas, and lots of other free open source video software ?

None. Mac's haven't had an edge in any practical sense in like 10 yrs or more.

Back in the old days Macs tended to come with a lot more ram than PCs, so it made them better for video and photo editing. And the even older days Macs had add-on hardware for improving video and photo editing.

But none of that's been applicable to the market in a decade.

Actually, that was only part of the equation. The other was that up until the "Intel Macs" Apple computers used RISC processing instead of your standard Intel CISC process design. This made it more complicated to code applications for, but made each CPU cycle optimally efficient, essentially, yes, making a 2Ghz Mac equivalent to a much faster PC.

A good example would be the 800Mhz Macs from back in the day that were as good or better than equivalent 1.3-1.5Ghz PCs (although it's a subjective matter in some ways, obviously it depends on total HW configurations, not just the CPU).

However, this came with the drawback of PC software not working on Macs and Mac software not working on PCs.

Now there's little excuse for PC software to not be at least somewhat portable to Mac, as Macs and PCs are now both on an x86 architecture.

(Anyone, feel free to correct anything in this post, I'm drawing from memory, so some of what I said here could be off, but I'm pretty sure I recall correctly about the RISC vs. CISC issues).

[echosierra]

(Anyone, feel free to correct anything in this post, I'm drawing from memory, so some of what I said here could be off, but I'm pretty sure I recall correctly about the RISC vs. CISC issues).

You're right that the difference in architecture made it impossible to run Windows apps without a recompile (at the very least, not to mention the API/ABI differences).

But trying to compare the speeds isn't productive at all. There's just too many things different to make a useful comparison; the architectures are just too different.

CISC's traditionally are designed to have many instructions to handle many different kinds of operations, taking up multiple clock cycles before moving on. RISC is (traditionally) designed with a much smaller instruction set that (usually) all complete in a single clock, reducing the needed complexity of other parts of the hardware design.

So to compare them you'd need code that's computationally equivalent across both and see which completes faster. But you can't choose code that plays to both architecture's strengths simultaneously, and inevitably one will be gimped.

Why am I writing this? I don't know, something about comparing clock frequencies or somesuch. Point is, don't do it across architectures. Hell, even different iterations of the same architecture aren't equivalent; a 3.0Ghz P4 gets smoked by a 3Ghz C2D or C2Q and they are both x86!

[Air]

A good example would be the 800Mhz Macs from back in the day that were as good or better than equivalent 1.3-1.5Ghz PCs (although it's a subjective matter in some ways, obviously it depends on total HW configurations, not just the CPU).

Eh, not really. I mean it's possible the PowerPCs had some advantage in some specific conditions. Namely the PPC has a MIPS-style branching system, which means it didn't have the 50-some cycle penalty on missed branches that PCs had -- of course if multimedia apps needed branching then I'd see the benefit. But typically multimedia is almost entirely free of branches (which is why it's idea stuff for the specialized linear execution pipelines of video card GPUs), so it doesn't make sense that the fast branching was a benefit in the context of a Mac.

I'm pretty convinced the performance benefits of the Mac were four fold:

* More ram (as I mentioned before)
* Faster ram (Macs pioneered DIMMs nearly 2 yrs before PCs, leaving PCs stuck with the much slower SIMM for a time)
* A general inability to install "useful" background tasks (lack of selection)
* A very basic operating system with no real multitasking or error handling ability.

The last one isn't to be downplayed. Pre-OS/X, Macs ran an operating system that was mostly just a window manager on top of a thinly veiled DOS (if you looked past the visual prettiness, it had more in common with Windows 2.0 than anything else [yes -- 2.0, not 3.0]).

That extremely low overhead was really beneficial on machines in the pre -1ghz era especially, when memory protection, exception handling, and protected-mode context switches were fairly costly. And it was also important because few programmers knew how to optimize for the new pre-emptive multi-tasking / multi-threaded environments, so software written for Windows at the time tended to use more ram and system resources than was necessary due to technical misunderstandings.

So yeah the Macs were faster, though usually not without matching drawbacks in other areas (which, depending on user, may or may not have been drawbacks worth quantifying).

[djricekcn]

Mac in film and graphic design isn't industry standard
Final Cut Studio 2 isn't an industry standard either, in fact, the industry standard is using Adobe and Final Cut together.

If by Industry Standard = majority average in the industry.

[Air]

CISC's traditionally are designed to have many instructions to handle many different kinds of operations, taking up multiple clock cycles before moving on. RISC is (traditionally) designed with a much smaller instruction set that (usually) all complete in a single clock, reducing the needed complexity of other parts of the hardware design.

Just for the record: Yeah if you're comparing the pre-2k macs and PCs, this mostly applies. Modern RISC/CISC comparisons are even less relevant though. Both designs typically have hundreds of instructions these days, many of which being very complicated compound activities. Modern day RISC vs. CISC today basically boils down to 2 differences:

* RISC CPUs use a uniform instruction word size. All instructions are 4 or 8 bytes, in theory making the instruction decoder simpler. CISC CPUs use a variable length instruction, 1-16 bytes, to describe instructions.

* RISC CPUs typically don't have an "addressing unit", which allows complicated inline address operands. So an intel operand like [ArrayPointer + eax+ecx*4] is one instruction on our PCs, but would be like 5 instructions on a MIPS or PowerPC.

The RISC design was a really good one 15-some years ago, before L1 caches became standard issue. The L1 cache however prefers the more compact code of a CISC cpu. Furthermore, at one time the decoding logic was the costly part of a chip, but these days it's hardly even relevant. Now days the main problem in most chips is the code/data fetch rate, which is a bytes-per-cycle rate. This, again, favors CISC design over RISC.

So if you wonder why Intel and Co haven't been more interested in getting away from CISC, that's why. There no longer strong evidence that RISC design is beneficial to the current set of technological bottlenecks.