PC still playing Amiga catchup

[amigaksi]

As an example, Gravis Ultrasound Max uses TSR Soundblaster emulation. GF1 chip is missing the AdLib-compatible OPL2 circuitry.

You lost track of the point.  There are SB cards that are backward compatible on hardware level.  I proved it by running in REAL DOS mode.

[amigaksi]

By the very nature of evolution within computer hardware, at some point you have to let go of hardware compatability or you are forced to produce ever more drastic hacks in order to maintain it. At some point the value of creating these hacks for infinatesimal improvements, not to mention newer concepts within computing make this a no go. It is far easier to produce an API to bridge basic support (such as VESA) then to build it into hardware.
...

Sorry you missed the point of how VGA is backward compatible on hardware level with EGA/CGA.

>You cannot say that given that you made no effort to test that the data you were recieving wasn't infact signal noise, indeed your "proof" was and is as it stands utter garbage. You were given a solution that would test it one way or the other. I have yet to see you put your hypothesis to an actual test yet. Simply repeating "it's better" over and over does not make it so.

You missed that point as well then.  I gave you LOGICAL statements how you can have millisecond readings which you NEVER replied to.  Just declaring it "garbage" does not change reality.  You are as biased as they come.  It's faster EVEN IF YOU DON'T SAMPLE AT 1KHZ.

>There is always likely to be bugs in software, but that is not the same as a flaw in an API and you should damn well know that! Also, DirectX now supports a great many things that it didn't in the past, the reason for version changes was to allow for the addition of newer capabilities, bug fixes have nothing to do with the DX version number.

I said it's not my argument but I know there are bugs in implementation of the API where certain video cards don't work the same for the same function.

>Correct. But also wrong. You are also limited by your own abilities. Doing things your way means extra work and hassle for everyone else.

Yes, you are limited by your abilities, but you are more restricted with just an API rather than both API and hardware level compatibilities.

>...software finds out that it's been hardcoded for something he doesn't own instead of using the OS's APIs

You are caught in a cyclical reasoning loop.  We are claiming it's better to have hardware compatibility.  Given that, you can do both-- API and hardware level programming.  You are now claiming, suppose he doesn't own that piece of hardware.  Well, that assumes it's not hardware compatible.

>No, you really didn't. Making baseless claims does not constitute an answer.

I gave a general answer-- any application employing time-critical loops.

>Which part of Commonly used desktop program was not clear? Joystick recorders and floppy drive simulators do not constitute anything like commonly used, I doubt even within development circles they're used all that often.

It's commonly used for me.  That's subjective really to say "commonly used".  And why does it matter-- it's an application that can be written only if you have hardware compatibility.

>Secondly with regard to your alledged DOS program, prove that a modern day OS using an OS friendly program that allowed for realtime effects couldn't do as well if not better. I mean real proof.

Only if the real-time effect you are trying to do is supported by an API call.  But as I stated before, you can manipulate I/O ports in so many ways and not all of them will have APi equivalents.

[amigaksi]

...
You are failing (actually, I suspect wilfully ignoring) the fact that to access even a large subset of the full capability of for instance a modern GPU in a reasonable timeframe the only way to do it is with an API. Also, I/O has improved a great deal in computing. The only remaining bottleneck is optical and hard drives, with the latter being slowly overtaken by SSD's that are an order of magnitude faster.

I don't see the argument why you MUST have an API access only.  And if hardware compatibility can help make things more efficient, why not spend the time.  I/O has improved but not as much as processor speeds.  And I gave the example of palette changes which (if you go time them) you will find they are not that much faster than amiga changing palette.  This is just one example.

[amigaksi]

True... But on the Amiga the hardware, bandwitch, etc... directly limits your creativity
You want to do C64 like graphics (looking in the PAST), you can, sure. But what about 3D ? Yes, you can be creative and want to do some nice beautiful 3D...

You want to do real-time HD raytracing on the PC, fine. You want to render crysis like graphics, fine.

You want to do something like that on the Amiga. You cannot. No matter you use an API or hardware banging code,... You simply cannot. Because the PC took over the Amiga since years. And there's no way it will change.

The PC wins. Over. Next thread...

You just expressed your emotional fanaticism of PCs without even addressing the point.  It's better for PCs to have both APIs and hardware level compatibility than just API access.  You have less options with just API access.  Now given you just have APi access vs. an Amiga which has both, for certain real-time applications, Amiga does better.

[amigaksi]

What happens to Deluxe Music if Protracker "hitting the metal" Paula’s audio hardware? Who will arbitrate the hardware access?

I was making the point that certain applications go directly to hardware yet don't effect the multitasking OS.  They return and OS is still stable as it was.  Even the examples of audio playback in Compute! magazines are directly writing to hardware registers rather than making APi calls.

[Karlos]

I don't see the argument why you MUST have an API access only.  And if hardware compatibility can help make things more efficient, why not spend the time.  I/O has improved but not as much as processor speeds.

And what sort of "hardware access" stanards do you propose for modern GPU's? You're thinking is so yesteryear with rgards this branch of hardware than you seemingly fail to note that modern graphics hardware has all but completely evolved away from fixed function pipelines into turing complete programmable devices.

Do you, in all honesty, even have the faintest notion how modern graphics hardware works?

And I gave the example of palette changes which (if you go time them) you will find they are not that much faster than amiga changing palette.  This is just one example.

From the above statement, clearly not. I could program a "pallete change" for my GPU that simultaneously sets every colour register in parallel in a couple of shader clock cycles.

However, palette changes are a thing of the past for modern hardware. I haven't used a indexed colour mode for more than a few hours (usually when retgrogaming) in almost 10 years, even on the Amiga.

[the_leander]

Sorry you missed the point of how VGA is backward compatible on hardware level with EGA/CGA.

>You cannot say that given that you made no effort to test that the data you were recieving wasn't infact signal noise, indeed your "proof" was and is as it stands utter garbage. You were given a solution that would test it one way or the other. I have yet to see you put your hypothesis to an actual test yet. Simply repeating "it's better" over and over does not make it so.

You missed that point as well then.  I gave you LOGICAL statements how you can have millisecond readings which you NEVER replied to.  Just declaring it "garbage" does not change reality.  You are as biased as they come.  It's faster EVEN IF YOU DON'T SAMPLE AT 1KHZ.

You have not yet proven that the Amigas joystick port is capable of actually being able to support anything like that rate.

>There is always likely to be bugs in software, but that is not the same as a flaw in an API and you should damn well know that! Also, DirectX now supports a great many things that it didn't in the past, the reason for version changes was to allow for the addition of newer capabilities, bug fixes have nothing to do with the DX version number.

I said it's not my argument but I know there are bugs in implementation of the API where certain video cards don't work the same for the same function.

That is not the same though as what you said originally, is it? In fact it's nothing like what you said originally.

>Correct. But also wrong. You are also limited by your own abilities. Doing things your way means extra work and hassle for everyone else.

Yes, you are limited by your abilities, but you are more restricted with just an API rather than both API and hardware level compatibilities.

You've said this time and time again. Prove it.

>...software finds out that it's been hardcoded for something he doesn't own instead of using the OS's APIs

You are caught in a cyclical reasoning loop.  We are claiming it's better to have hardware compatibility.  Given that, you can do both-- API and hardware level programming.  You are now claiming, suppose he doesn't own that piece of hardware.  Well, that assumes it's not hardware compatible.

Excuse me? I've said from the beginning that banging the hardware on the modern desktop PC is an exersise in stupidity for many of the reasons given here already. You have completely dismissed them, instead prefering to go on about a dream world where every componant on a PC, regardless of what it actually does, retains some form of hardware legacy compatability. Do not try to turn this around because you've been called on your BS.

>Which part of Commonly used desktop program was not clear? Joystick recorders and floppy drive simulators do not constitute anything like commonly used, I doubt even within development circles they're used all that often.

It's commonly used for me.  That's subjective really to say "commonly used".  And why does it matter-- it's an application that can be written only if you have hardware compatibility.

No it isn't. Unless you're trying to play some kind of pathetic game of semantics. "Commonly used desktop programs" is quite clear in of itself. But if you want to be a pedant, fine.

Show proof that there is not some commonly (by commonly, I mean greater than 50% of the computer using population use it on a regular basis) used desktop (by which I mean a desktop computer still within its design specifications lifetime IE within 6 years of this post) application.

Clear enough now?

Only if the real-time effect you are trying to do is supported by an API call.

That is a given. I note that you still managed to dodge the point again however.

  But as I stated before, you can manipulate I/O ports in so many ways and not all of them will have APi equivalents.

Yes, and how many of those ways can be done without it having a detrimental effect on other processes. Further how can you maintain compatability across the huge differences between computers?

[Hammer]

But if the hardware compatibility is required for newer hardware, then metal won't change registers or affect previous software.

Tell that to 68K vs ColdFire.

>2) Any loss of processor cycles involved in going down the API route is more than made up for in the fact that systems employing API access to devices tend to be running on CPU's orders of magnitude faster than the 68K.

>Cycle for cycle, direct hardware access wins, but when your API is running on a machine that can execute billions of instructions per second, worrying about a function call that might execute a few dozen instructions to get the job done is quite simply nothing short of laughable.

Thanks-- some people can't even accept that direct hardware access wins everytime.  The point about processors being much faster is fine, but I/O instructions haven't sped up like processors have.

On GPUs and at a given transistor budget, maximising math unit count takes precedence i.e. maximising compute wavefront. The host CPU can handle driver JIT re-complier workload.

[Hammer]

I was making the point that certain applications go directly to hardware yet don't effect the multitasking OS.  They return and OS is still stable as it was.  Even the examples of audio playback in Compute! magazines are directly writing to hardware registers rather than making APi calls.

They'll break if the application misbehaves i.e. results in guru-mediation.

[Hammer]

You just expressed your emotional fanaticism of PCs without even addressing the point.  It's better for PCs to have both APIs and hardware level compatibility than just API access.  You have less options with just API access.  Now given you just have APi access vs. an Amiga which has both, for certain real-time applications, Amiga does better.

On the PC, there’s nothing stoping you using kernel space.

[Hammer]

You lost track of the point.  There are SB cards that are backward compatible on hardware level.  I proved it by running in REAL DOS mode.

DOS TSRs and device drivers(e.g. CD-ROM) also run in real mode. Anyway, my SoundBlaster X-Fi USB2.0 is not SB16 backward compatible in REAL DOS mode.

[persia]

Yeah, yeah, we all know about reading joystick bounce, but I can't think of a practical application for it.  

It makes sense to hardware control a bi-plane, it does not make the same sense in an A380.  

You just expressed your emotional fanaticism of PCs without even addressing the point.  It's better for PCs to have both APIs and hardware level compatibility than just API access.  You have less options with just API access.  Now given you just have APi access vs. an Amiga which has both, for certain real-time applications, Amiga does better.

[Hammer]

Sorry you missed the point of how VGA is backward compatible on hardware level with EGA/CGA.

>You cannot say that given that you made no effort to test that the data you were recieving wasn't infact signal noise, indeed your "proof" was and is as it stands utter garbage. You were given a solution that would test it one way or the other. I have yet to see you put your hypothesis to an actual test yet. Simply repeating "it's better" over and over does not make it so.

You missed that point as well then.  I gave you LOGICAL statements how you can have millisecond readings which you NEVER replied to.  Just declaring it "garbage" does not change reality.  You are as biased as they come.  It's faster EVEN IF YOU DON'T SAMPLE AT 1KHZ.

>There is always likely to be bugs in software, but that is not the same as a flaw in an API and you should damn well know that! Also, DirectX now supports a great many things that it didn't in the past, the reason for version changes was to allow for the addition of newer capabilities, bug fixes have nothing to do with the DX version number.

I said it's not my argument but I know there are bugs in implementation of the API where certain video cards don't work the same for the same function.

That’s an implementation issue. The product should be following the reference renderer.

>Correct. But also wrong. You are also limited by your own abilities. Doing things your way means extra work and hassle for everyone else.

Yes, you are limited by your abilities, but you are more restricted with just an API rather than both API and hardware level compatibilities.

You made the same mistake as PS3 fanboys. OpenGL can be expanded via vendor specific extensions. You are welcome to implement your own OpenGL driver.
Make sure you target AmigaOS 4.x.

Using Oblivion (PC edition) game’s example, ATI’s chuck patch enables HDR FP+AA via driver level patch i.e. it overcomes Direct3D 9c's limitations.

"Hitting the metal" doesn't change NVIDIA RSX's hardware limitation e.g.
1. Limited vertex resource. NVIDIA G80 fixes this feature.
2. Lack of HDR FP render targets + hardware AA. NVIDIA G80 fixes this feature.
3. Lack of geometry shader instructions. NVIDIA G80 fixes this feature.
4. Lack of Early-Z hardware features. NVIDIA G80 fixes this feature.
5. Avoiding pixel shader stalls during texture fetch. NVIDIA G80 fixes this feature.
6. Limited shader branch support. NVIDIA G80 fixes this feature.
7. Lack of Giga-Thread hardware features. NVIDIA G80 fixes this feature.

NVIDIA's G7x and RSX hardware functionality basically follows Direct3D 9c limitations.

[Hammer]

Hi,
@Karlos

Yea we were all suckered into buying VISTA for DX10, then after it came out, they upgraded it to 10.1 which threw a lot of the new amazing cards out, causing bugs in their coding. Case in point nvidia 8800 cards. So really you are using DX10.1, I could look back in my Max PC mags to put down all the details but very few people know about that.

Current CUDA GPUs can enable some DX10.1 features via NVAPI. Best example is FarCry2 PC.

"FarCry 2 reads from a multisampled depth buffer to speed up antialiasing performance. This feature is fully implemented on GeForce GPUs via NVAPI. Radeon GPUs implement an equivalent path via DirectX 10.1. There is no image quality or performance difference between the two implementations."

[amigaksi]

Let me get this straight. Something must be buggy since it exists in a high version number?

It's true that there are bugs in all versions of DX, like there are in any software (and hardware), but this isn't the reason it's up to V10. It's up to V10 due to the inclusion of more and more features.

You only have to look at the featureset of a typical DX10 game compared to one that'll work on DX3 to know that :lol:

In general they do fix bugs as versions keep going up and up, but in one sense you can consider adding more functions a type of flaw as well since that means original was missing things that are now present.

Some even divide up the number of the version into some major function change or bug fixes...

[smerf]

Current CUDA GPUs can enable some DX10.1 features via NVAPI. Best example is FarCry2 PC.

"FarCry 2 reads from a multisampled depth buffer to speed up antialiasing performance. This feature is fully implemented on GeForce GPUs via NVAPI. Radeon GPUs implement an equivalent path via DirectX 10.1. There is no image quality or performance difference between the two implementations."

Hi,

@Hammer,

Know what you mean, I was really ticked at MS when I read about the new 10.1. There was a big billiwac by both nvidia and MS on this. Both companies are still fighting about who was right or wrong on this. All i have to say is that a lot of people spent a lot of money (like I did) for nvidia 8800 graphic cards that were now not up to date because of MS changes in their coding. One of the major things I noticed was when playing fallout 3 in SLI mode, I had to disable SLI while playing fallout 3 because of 10.1 programming errors. SLI worked great using windows aero but tended to crash and cause screen distortions while playing this game. I usually crashed 3 times a night while playing until I learned to disable the SLI mode. I paid a lot of money to get SLI in order to have the faster frame rates, but MS frapped me up there. I HATE MS and their buggy bloated OS that you have to pay money for. By the way I had the same problem playing far cry in SLI, but when I played it on Linux using cedega, it played without any crashes or problems.

smerf