PC still playing Amiga catchup

[alexatkin]

Going on about how you could still bang the metal in Win98 is amusing, seeing as that was the single reason why it was such an unstable OS.

Personally, I do not want to go back to the days where I fire up a game, it crashes, and I have to hit the reboot button because said game had taken control from the OS so there was no way for the system to recover from that state.  Or even if the game did not crash, often it would have corrupted the OS environment so I still had to reboot before I could do anything else.

Now compared to today, you can usually recover from any crashed state because games are using standard API OS calls so the OS knows what it needs to cleanup.  You may still get some memory leaks, but at least you aren't forced to immediately reboot in order to continue using the computer.

Lets face it, even games consoles do not bang the hardware anymore for the most part.  They have an OS all their own, they multi-task and have to play nice.  Even then there are still stability issues because they run as close to the metal as possible on APIs.
Oh and they also still get to optimise and improve their gaming engines (yet another API).  Imagine the love if their engine had to bang the hardware directly, not to mention the complexity of porting it to other systems.

As has already been said.  The greatest thing about APIs is how you can write a game on the PC and easily port it to Xbox 360.  Even then there are quite enough optimisations you can do for that specific hardware, even though you are still writing for APIs.  There would be no use at all for banging the hardware as developers do not have the time/money to waste tweaking their code to that degree.

[persia]

I was surprised to see how easy it was to move my OS X apps to iPhone, different processor, completely different hardware and just a bit of screen real estate redesign and it's done.  I lived through the bang the hardware age once, thank Ahura Mazda it's gone!

[amigaksi]

That is not what available documentation from Commodore suggests.

I don't see any reason why hardware could not be extended with 256 palette registers using different locations rather than overloading the same 32 registers.

[amigaksi]

The Amiga had only two major iterations in its entire life - OCS and AGA. Comparing that to the evolution of the PC from 1988-2009 is ridiculous!
...

You have a problem understanding me.  Your argument does not show that they cannot have hardware compatibility.

>Your original claim was that the Amiga was superior due to an alledged ability to detect button presses faster then a PC. Your only "evidence" to that effect has been torn to shreds. So yes, as it stands, your hypothesis is as yet unproven. You have since then tried to move the argument to API vs hardware banging.

No, the joystick argument is over-- Amiga won hands down; it can't be torn to shreds until people stop selling gameport based joysticks and 99% of the people adopt nonexistent USB 3.0.  List of my points is given in post #275.  Now we are talking which has better implementation of hardware for real-time tasks.  Amiga has API and hardware level compatibility.  PCs have moved away from that since early 90s are going toward the inferior solely API-based method.

>You have not shown that DirectX/OpenGL/OpenCL/Cuda/X are flawed.

That was not my argument, but there are bugs since they are up to version 10.0 DirectX or something around that number.

>Nor have you shown proof that having API's reduce people's creativity either btw.

Creativity is limited by the choices you have.  If you have a C64 and want to use colors, your creativity to paint a picture is limited by 16 colors from palette of 16.  If you have an Amiga and want to use colors, you can paint the C64 pictures as well as make pictures not doable on C64.  Similarly, having just API is restrictive but having both API and hardware level compatibility opens up a lot more possibilities.

>No, it might be marginally slower in some ways, however, going the hardware banging route is slow as well - in terms of development for starters, not to mention the very real issue you have completely dodged with regard making sure that multiple programs interact in a friendly way without them.

I never said APIs should be removed and only hardware level programming should be done.  But having that option gives you more possibilities with the machine.

>And I see you dodged the question on what commonly used desktop program could not be made in an OS friendly fashion. I wonder why that was :rolleyes:

I gave you a better answer than 3.  If you just want three, my floppy simulation is IMPOSSIBLE to do with API calls; I have this DOS program that does echo effects on DMAd data going to audio card in real-time-- that would be affected using API calls.  I have a joystick recorder which would have problems if it relied only API calls.

[amigaksi]

Not to mention that banging the metal with a multitasking OS is generally a bad idea.

Amiga seems tons of games that go directly to hardware and still have a multitasking OS. It's wonderful that some systems allow you to take over the hardware and use all of it for your application-- you really get to use what you paid for and it works in general not just for your Amiga.

[amigaksi]

All this harping on about API's being slow and metal banging being faster:

1) Metal banging is fun but fails the moment the metal changes, even slightly
...

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

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

[amigaksi]

Define this lost of computation power. Large API inefficiencies is debunked by Fold@Home GPU2 CUDA example.

Suppose you want to use mode 640*480*16 paletted mode and read palette register #3 and swap with palette register #15.  I can do that with a few IN/OUTs using standard VGA registers or doing MOVE.Ws to $DFF186/$DFF19E on Amiga or a few LDA/STA on 8-bit computers.  Let's see your API calls to do that.  Since you seem to be pretty up to date with all the latest video cards and hype of APIs and video cards are frequently updated and are using best possible technology-- let's see how efficient their APIs are.

[amigaksi]

I still remember TSR SoundBlaster emulators.

If you boot DOS in REAL mode and directly access sound blaster registers, there are no TSRs running nor anything else and your IOPL=0 so nothing is trapping your using the ports.  If such an application works, you know it's hardware compatible with Soundblaster.

[amigaksi]

Going on about how you could still bang the metal in Win98 is amusing, seeing as that was the single reason why it was such an unstable OS.

Personally, I do not want to go back to the days where I fire up a game, it crashes, and I have to hit the reboot button because said game had taken control from the OS so there was no way for the system to recover from that state.  Or even if the game did not crash, often it would have corrupted the OS environment so I still had to reboot before I could do anything else.

Now compared to today, you can usually recover from any crashed state because games are using standard API OS calls so the OS knows what it needs to cleanup.  You may still get some memory leaks, but at least you aren't forced to immediately reboot in order to continue using the computer.

Lets face it, even games consoles do not bang the hardware anymore for the most part.  They have an OS all their own, they multi-task and have to play nice.  Even then there are still stability issues because they run as close to the metal as possible on APIs.
Oh and they also still get to optimise and improve their gaming engines (yet another API).  Imagine the love if their engine had to bang the hardware directly, not to mention the complexity of porting it to other systems.

As has already been said.  The greatest thing about APIs is how you can write a game on the PC and easily port it to Xbox 360.  Even then there are quite enough optimisations you can do for that specific hardware, even though you are still writing for APIs.  There would be no use at all for banging the hardware as developers do not have the time/money to waste tweaking their code to that degree.

I have games on Amiga which take over the system and also come back to OS without it crashing so it's doable.  Also, I myself take over Windows 98SE OS and write directly to VGA memory and then restore the OS as if nothing happened.  In fact, there's a built in function in Windows 98SE although undocumented that lets you take over video registers.

Tweaking is unrelated to using hardware registers.

[ElPolloDiabl]

Windows XP seems to relinquish resources on my 512MB (don't ask why it is so low, also notice I used the big B as in Byte) laptop, allowing me to play The Sims 2. No complaint there.

In fact Windows XP seems very well behaved at most things. The complaints usually come from 3rd party items,
a) Crapping files all over the place and 'not' cleaning them up at uninstall.
b) Accessing the hard drive at random times or not efficiently resulting in a 'slow down'.
I could also complain about Media Player and IE, but I'm not forced to use them.

[the_leander]

You have a problem understanding me.  Your argument does not show that they cannot have hardware compatibility.

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.

The hardware of today is so different to the hardware of the XT that to maintain "hardware compatability" would be utterly pointless, in many cases the hardware functions have been completely replaced by other technologies.

No, the joystick argument is over-- Amiga won hands down;

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.

PCs have moved away from that since early 90s are going toward the inferior solely API-based method.

PC's are far too numerous in terms of variation to support anything else. Had the Amiga moved to more comodity type hardware in a similar vein to the Mac, the same would likely have had to have been done. C=, for all their faults saw the writing on the wall, which is why when you bought a shiny new A4000 or A1200, you didn't get a whole bunch of circuit diagrams to help the hardware bangers like you did with the A500, further, they improved APIs based on feedback from programmers. They pushed developers to develop for the OS, not the hardware.

>You have not shown that DirectX/OpenGL/OpenCL/Cuda/X are flawed.

That was not my argument, but there are bugs since they are up to version 10.0 DirectX or something around that number.

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.

>Nor have you shown proof that having API's reduce people's creativity either btw.

Creativity is limited by the choices you have.

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

API and hardware level compatibility opens up a lot more possibilities.

Only if everything else is using the exact same setup as your own or you are working only for yourself!! To anyone else with different hardware, the only thing you've opened is likely to be a pack of headache tablets when the poor sap who has the misfortune of using your software finds out that it's been hardcoded for something he doesn't own instead of using the OS's APIs

>And I see you dodged the question on what commonly used desktop program could not be made in an OS friendly fashion. I wonder why that was :rolleyes:

I gave you a better answer than 3.

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

Your claim (and that's all it is, as you provided no evidence to support your suposition) that it's better is meaningless. Untill you can provide real world data to show that APIs slow down feedback to such an extent that there is a noticeable lag between what you do and what happens on screen AND prove that it's not down to sloppy game engine coding, it will remain a baseless claim.

(and that's ignoring the whole issue of having to provide custom support for hundreds, if not thousands different controllers and many different interfaces etc etc)

 If you just want three, my floppy simulation is IMPOSSIBLE to do with API calls; I have this DOS program that does echo effects on DMAd data going to audio card in real-time-- that would be affected using API calls.  I have a joystick recorder which would have problems if it relied only API calls.

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.

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.

[the_leander]

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

And as hardware evolves and things are simply dropped as they become obsolete, you end up right right where we are now in terms of hardware, only, you'll have to wait a lot longer to get here because of that added requirement, not to mention the veritable rats nest of kludges you'll have to add to the mix to get there.

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.

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.

[ElPolloDiabl]

:madashell:

Hi Wayne,

I think it is time to lock the thread. Them mushrooms will be sprouting anytime now. [Takes iodine pill]

[warpdesign]

Creativity is limited by the choices you have. If you have a C64 and want to use colors, your creativity to paint a picture is limited by 16 colors from palette of 16. If you have an Amiga and want to use colors, you can paint the C64 pictures as well as make pictures not doable on C64. Similarly, having just API is restrictive but having both API and hardware level compatibility opens up a lot more possibilities.

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

[Karlos]

>You have not shown that DirectX/OpenGL/OpenCL/Cuda/X are flawed.

That was not my argument, but there are bugs since they are up to version 10.0 DirectX or something around that number.

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:

[alexatkin]

I have games on Amiga which take over the system and also come back to OS without it crashing so it's doable.  Also, I myself take over Windows 98SE OS and write directly to VGA memory and then restore the OS as if nothing happened.  In fact, there's a built in function in Windows 98SE although undocumented that lets you take over video registers.

Tweaking is unrelated to using hardware registers.

But you seem to be missing the obvious.  Code is so complicated these days (and hardware banging would not reduce that) that bugs will remain and said bugs cause MUCH greater problems if you are hardware banging than if you are using OS calls and other APIs.

Also, the reason for different versions of Direct X is again partly related to a need to NOT be fully backwards compatible, as its too complicated and actually reduces efficiency in the API.  

Often a newer version will remove older functions, because if you for example coding for Direct X 10 there are more efficient ways to do things and than calling some Direct X 9 function.  Also, developers often need a push to encourage use of the newer versions as if they don't use it, theres no point in the card supporting it.

Microsoft made a particular point for example of saying Direct X 10 was written specifically to take advantage of Windows Vista, with Direct X 9 still being included for backwards compatibility.  They are however, I believe, seperate libraries as a lot of changes in Direct X 10 involved more efficient ways of doing things that would not necessarily work well with some Direct X 9 API calls.

We can even use this example on HTML.  Certain tags get deprecated on newer versions to encourage the use of more efficient/clean/powerful ways of rendering a page layout.  If that did not happen, we would have an aweful mess of HTML 1 code with CSS.  In fact, to some degree that does happen but it would be a whole lot worse if they had not mandated that you cannot do certain things if you are aiming for HTML 3 compliance for example.

So basically, backwards compatibility while being useful is not always a good thing if it means you mixing/matching different ways of doing something.  Yes I know, HTML is not the same as banging registers but the reasons why its not a good idea are very similar.  The more different ways you can achieve the same thing, the more complicated the code and more likely you cause bugs and/or tread on other software causing instability.  You yourself pointed out that with an API you cannot be sure what calling a function is ACTUALLY doing.  Therefore is it logical to allow you do hardware banging, when you might be interfering with the code the API is executing?  

Doing hardware banging and API calls at the same time is just asking for trouble.
Doing just hardware banging is time comsuming to code, not useful for most people.  
So here we are today, mandating ONLY API calls be used.  Because its the safest more stable (and legible) way to code.

You also seemed to miss a point I made earlier.  We are not arguing that the PC is as good at precise timing as the Amiga, we know it isn't.  But the PC is intended to be an all purpose machine not for precise timing.  If you want strict timing you would use a more suitable machine, an embedded board of some kind or, guess what, the Amiga.  It does not mean the PC is "catching up", its the opposite, as the PC no longer NEEDS that functionality for what people use it for.