PC still playing Amiga catchup

[Hammer]

Hi,

Not only that but while your computer is sleeping the power supply keeps running and a fan in the power supply stays on pulling through air, this draw through pulls in dust, but that just brings another market to the PC world, compressed air to blow the dust out of their many heat sink fans, and air ducts.

smerf

My laptop's sleep mode shuts down the fan.

[Hammer]

I asked you to reply to post #275; you did not but are now expressing your opinion again.

>Well, arguments as stupid as "you may poll the joystick port 1000 times a second, the PC cannot". Well, it's certainly *true*. But it is so useless that no one in the entire Amiga's existence ever mentionned or used it. No one but you...

The people who don't understand the argument are stupid.  Doing a MOVE.W $DFF00A,D0 is superior to polling an analog joystick (period) via port 201h or via USB.  Then I gave an example of River raid where 1Khz sampling can be used (and I did use it in a "Replay" mode) and this sampling is UNDOABLE on a gameport.

>That was my two cents. You can keep on posting detailed reports on how you can poll the Amiga joystick port faster than anything else, but this won't change anything to that...

You haven't shown PC doing faster joystick port input so we can move on to the next advantage Amiga has over PC.

I prefer my Xbox 360 controller (for Windows) over standard classic Amiga digital joysticks i.e. four standard analogue controls (e.g. LT, LT, RS, LS) and vibration feedback.

[Hammer]

Hi,

@Karlos,

I know I am a little late on this one, but this is very noticeable in Windows, on somethings it multi tasks really great on, on some things you might as well walk away from the PC until it gets done, like when I am playing fallout 3, the machine sometimes slows to a crawl, then I go to my main screen and usually Winblows is updating, very aggrevating, especially when your at a really good part in the game and then it reboots to install updates,

Which Windows?

MS Window offers options in regards to Windows updates.  I haven't encountered a slow down, while playing Fallout3 on Vista SP2.

Spec
ASUS G1SN 15.4" laptop.
CPU: Intel Core 2 Duo T7500 2.2Ghz, 4 MB L2 Cache, 800 FSB.
MEM: 4 GB PC5300 with dual channel mode.
GPU: NVIDIA Geforce 9500M GS with 512MB VRAM and Forceware 185.70 driver.
HD: 2.5" 500GB with NCQ.
OS: Windows Vista Ultimate SP2 32bit.

Playing Fallout3 at 1280x720p/800p and high details.

[Hammer]

(SNIP)
>Yes, because the concept of kernel mode drivers exists in every operating system available for the PC...

At hardware level programming, the PCs are the same but nowadays you HAVE to go through APIs for much of the hardware.

Software abstraction layer enables the PC to adapt and not being stuck with a boat anchor.

>Data existing is not in itself an indicator that it is important to the end user. As pointed out, the sub-ms state changes are results of switch bouncing. Just because there are millions of magazines in the world doesn't mean that I am missing out stuff that is important to me by not reading them all.

You fell for that speculation that it's a result of switch-bouncing; nonetheless, I wasn't talking about sub-ms.  I answered this in another message.

>Not in a computer game, when the screen redraw is sometimes the only feedback you get.  

User can cause motion via joystick that is faster than refresh rate; he does not have to depend on feedback from display to make moves on the joystick.

>No, it's not bullcrap. YOU HAVE YET TO SHOW ME A GAME THAT USES AND BENEFITS FROM 1 kHz JOYSTICK SAMPLING. That's still true, as it has been since I first pointed it out. As far as I know, there are VERY few games in the River Raid era where even the game logic (all the moving, AI decisions, counting of score etc) operates faster than the screen update.

It's better to understand the LOGIC that millisecond state changes are there and not result of noise.  Also, try to understand that noise is also considered input to machine.

>If you'd ever used joysticks for other things than measuring the time between state changes, you'd know that the values that the joysticks are precise enough, and no, while they are not usually exact they give you more precise control over direction than four on/off switches. You'd also know that in most games that utilize the analog sticks, the walking/turning speed/direction correlates exactly enough to the input.

I know that most games don't need analog sticks and it's a waste of time in reading such sticks for PCs since they end up using some threshold to make them act like digital joysticks do.

Besides the analogue LS/RS/RT/LT, the Xbox 360 controller includes a digital PAD/LB/RB/X/Y/A/B. In most PC FPS and RTS, a mouse and keyboard combo is the preferred method.

Most console-to-PC game ports(e.g. Games For Windows) includes support for the Xbox 360 controller.
 

>If digital sticks with one button were superior for controllability, their market wouldn't have died out in the early 90s.

That's speculation.  They still exist and are being marketed.  You can market "garbage" and sell more of it than something valuable and more useful.  Marketing has NOTHING to do with the product being superior/inferior.

I recall Street Fighter II Amiga port didn't capture the arcade feeling i.e. the 1 button joystick standard is one of these issues.

PS; waiting for Street Fighter IV PC edition.

>No, that was not what I was claiming. I said that developers are trying to move further away from hardware, which is why there are abstractions like drivers and APIs. If you think that the average software developer has as much use of accessing the hardware as before you are wrong.

I am saying it's more optimal to have both available.  APIs and hardware access, but PCs are now getting more and more restricted to APIs so Amiga wins in this catagory.

IF there's a direct hardware access, what happens to the security objects?

[Hammer]

Moi, knock Fallout 3? Why my dear fellow, I have completed it twice and clocked over 250 hours in there in total

I have the first two DLC packs but I don't have Broken Steel yet. Needed to wean myself off the addiction a bit



It's not that bad. The lack of real time shadows means it runs a lot faster than some titles. If you want something that really pounds your hardware, run Crysis with all the detail jacked up. I dread to think how intensive it's lighting engine is alone.

In CryEngine3 switched to deferred rendering for lights i.e. followed Killzone2.

[Hammer]

Have you seen typical driver sets for things like graphics cards these days?

Thanks to direct support for CUDA, PhysX, OpenGL1.0 - 3.0, Direct X (up to v10), Pure Video etc, the drivers for my card alone weigh in at around 100 MB, not including tweaking tools.

The linux drivers aren't much smaller.

NVIDIA drivers includes NVAPI i.e. it enables some of Direct3D 10.1 *like* features on current CUDA processors e.g. FarCry2 PC.

[Hammer]

Someone just gave me an XBOX for $4.  I guess it's not 360, but probably same controllers.

They are not the same controllers.

 Controllers are fancy looking, but they are still analog and confusing due to so many buttons.  Perhaps, they were trying to replace the keyboard with the joystick.  Tried a few games and still ended up doing eenie, meenie, minie moe...I guess they forgot to put in a help button.

If you can handle a PC keyboard, you should be able to handle a well known gaming controller.

Vibration feedback-- is that the propellors that come out of the joystick when player does something wrong and attack the user like Maximillian in the movie Black Hole?

Refer to steering feedback on real life car.

[Hammer]

As I said, you can have both APIs and hardware level compatibility.

In Windows NT, there are only two I/O privilege levels used i.e. level 0 & level 3. Usermode programs runs in privilege level 3. All usermode programs should talk to a device driver that arbitrates access i.e. to minimise conflicts.

 For PCs, that's a big problem nowadays.

Define this "big problem nowadays." in terms of numbers.  One could write a kernel mode driver for I/O level 0 access. Most PC games talks to DirectInput or xInput APIs i.e. userland programmers do not have worry about specific implementations i.e. makes development easier.  

Refer to ease of development with Xbox 360 vs PS3's "design to be hard development".

IF STI(CELL) has been proper GPU vendor, they would have abstracted SPEs and RSX in similar ways to Direct3D9’s split vertex (a type of stream processor) and pixel shader (a type of stream processor).

IF you notice with PC GPU(a type of stream co-processor array) market, they annually change their micro-architecture i.e. they went from SIMD(Geforce 4 TI), VLIW (Geforce FX), SIMD (Geforce 6/7),  SIMT(Geforce , MIMT**(Geforce GT300). “Hitting the metal”  requires userland software rewrites.

**Rumoured to be MIMT.

>Most console-to-PC game ports(e.g. Games For Windows) includes support for the Xbox 360 controller.
 
Which port are you referring to as the "console-to-PC" game port?

Mostly from Xbox 360 targets (i.e. games installed on my laptop) for example, Fallout3, Devil May Cry, Dynasty Warriors 6, Burnout Paradise IUB, Far Cry2, GRID Race Driver, Gears Of War, Mirror's Edge,  Tom Clancy's H.A.W.X., The Last Remnant, Two Worlds (V1.5), Assassin's Creed, Dead Space, Lost Planet, Turning Point (Fall Of Liberty).  Any console/PC games that supports XInput API (i.e. Games For Windows and Xbox 360).

>I recall Street Fighter II Amiga port didn't capture the arcade feeling i.e. the 1 button joystick standard is one of these issues.

Majority of games don't require the analogicity (can be done with digital joysticks) and don't require 10+ buttons.  They just have to be programmed to use one or two buttons.  Amiga joystick port can handle up to 3 buttons if you use the POTs as buttons as well, but it's easier to use a game with lesser buttons.

The Xbox 360 controller assumes lack of PC keyboard access. Note that, the mouse is one form of analogue control.

On Xbox 360 controller
LS = analogue direction e.g. I use it in Grid, Burnout Paradise, H.A.W.X.
RS = analogue POV (changes user's view) e.g. I use it in Grid, Burnout Paradise, H.A.W.K. digital PAD = digital direction
LT = analogue trigger e.g. deceleration.
RT = analogue trigger e.g. acceleration.
LB = digital trigger e.g. E-Brake.
RB = digital trigger.
Y,X,B,A = digital buttons.
Start = start game button.
Back = back button.

In real world controls, analogue controls reigns supreme.

Anyway, AmigaOne, SAM and Peg supports USB type devices.

[Hammer]

Hmno, with some games, digital control is just better, and those well known gaming controllers don't handle that very well, and mostly ends up as a secondary 'analog' controller, or for the use to change weapons, or browsing through inventory.
And with arcade games, use a digital arcade controller (IIRC there's one available, with connectors for quite some gameconsoles and computers). It's just better.

Both PS3 and Xbox 360 controllers must support all type of games at minimal cost.

[Hammer]

Yeah, that's the rule.  But if the at ring0 you had standardized hardware, you can write more efficient code.

Userland programmers should not worry about the implementation i.e. plumbing work.

If those implementations were standardized like 8253 example I gave or even VGA standard modes, you can have more efficient code.  On Amiga, writing to OCS registers works for all OCS/ECS/AGA amigas.

A boat anchor.

Hitting the metal can be done and product enhanced.  I still use same I/O ports and memory address of A000:0000 for VGA access on ISA-based VGA cards, VESA-based VGA cards, PCI-based VGA cards, and AGA-based VGA cards.  So they improved the video cards and yet maintained backward compatibility at hardware level.

These legacy modes have no bearing on vendor specfic NVIDIA CUDA’s (Geforce 8 and above) and AMD CAL’s (Radeon HD) capabilities.

Notice X86's performance improvements while keeping legacy compatibility vs GPU's performance improvements. To maximise performance, GPUs usually take a clean design approach i.e. applying the latest micro-architecture paradigm on a given transistor count.  

Note that modern X86 translates(amounts to hardware accelerated emulator) CISC instructions to RISCy instruction and hides their expanded micro-architecture registers(i.e. register renaming hardware).

Let's use Geforce 8 micro-architecture as an example.

G80's processing elements has the following specs
[MT IU]
[SP][SP]
[SP][SP]
[SP][SP]
[SP][SP]
[Share memory]

8 scalar threads processors(SP)
32 GFLOPS peak at 1.35Ghz
8192 32bit registers (32K).
- 512KByte total register file space.
768 thread active threads in total.
16KByte on-chip memory
- shared amongst threads of a block
- supports thread communication

1. Geforce 8600 GT/8700M GT/9500M GS/9600M/9650M GT has four of these processing elements i.e. 32 SPs with 32768 32bit registers.

2. Geforce 9600 GSO has eight of these processing elements i.e. 96 SPs with 98304 registers i.e. these values are stored next to actual execution cores.

Notice the register count differences between examples 1 and 2.

>The Xbox 360 controller assumes lack of PC keyboard access. Note that, the mouse is one form of analogue control.

But mouse is usually read as digital data so it's more exact than reading an analog value which tends to fluctuate between various values.

I was referring to variable of movement compared to on-off nature of a digital joystick. Anyway, my mouse has an optical scanner i.e. it has a DPI resolution and it doesn't have a mouse ball. It has A-to-D conversion.

>In real world controls, analogue controls reigns supreme.

I wasn't speaking from marketing point of view-- but one of ease of use and learning in a majority of games.

I wasn't referring to marketing point of view i.e. refer to real world cars. Xbox 360's RS's replicates (player's POV)'s head movement changes.

[Hammer]

They speed up processors and functionality while maintaining compatibility;

Intel and AMD didn't give you(and anyone else) access to X86’s RISCy micro-architecture instruction set.

they sped up VGA and functionality while maintaining compatibility; Creative Labs made all those Sound Blaster cards while maintaining backward compatibility.

Standards breaks when vendors can't copy/clone another vendor’s specific features e.g. NVIDIA CUDA vs AMD CAL. DirectX11's compute shader and OpenCL attempts to standardise GpGPU.

[Hammer]

I already answered this.  VGA went through an evolution where it kept backward compatibility at the hardware level.

>Anyone writing software tied to specific hardware in this day and age would be fired on the spot in any large software firm. And with good reason.

Might does not make right.  So big companies are following some API standard that does not mean it's the most efficient method.

From GPU's POV, maintaining a CPU style legacy may not be efficient for the transistor budget. For example, GPU's allocates their transistor budgets to math units.

Also, I don't think NVIDIA would share thier GPU ISAs with anyone else.

>Do you have even the slightest concept of how much things have advanced in the last twenty years in terms of audio and video? You have API's there to abstract these changes and to be fair, DirectX is a pretty damn efficient way of doing things. It's unlikely that you could learn the hardware of a modern GPU these days well enough to improve over what is already available in a reasonable timeframe. To be clear, even mid range GPUs are more complex then every chip on any Amiga ever created in their totality.

Take any software using those APIs, and I can write a more efficient software going directly to the hardware.

Close sourced NVIDIA and ATI driver packages include JIT re-complier engine. You are welcome to write Radeon drivers that would beat the offical Radeon drivers.

AMD and NVIDIA offers "close-to-metal" with thier GPUs, but they are vendor specfic. With PS3, NVIDIA provides LibCGM thin-layer.

>Come back when you get a clue.

You have no clue that it's better to have hardware level compatibility as well as APIs.

>Err, Microsofts tools are among the best on any platform bar none. You want to learn how to produce modern games, you use their tools. It's actually one of the few things they really did get right.

I prefer the simpler digital joysticks over analog joysticks w/various interfaces and 10+ buttons.  As I have experienced and seen many others, people have a harder time dealing with the complexities of extra buttons and analogicity for every game.  Wasn't it Microsoft that implemented a GUI and mouse to make things SIMPLER.  How about a mouse with 10+ buttons.  Actually, I saw one of these and it's terrible trying to even move the mouse around without pressing some button accidently and having something weird happen.

Pre-programmed macros on MS gaming mouse while playing with Xbox 360 players in Gears Of War(via Xbox Live) is an advantage.

I use an 8 button gaming mouse e.g. able to change sensitivity on-the-fly (two buttons), change weapons, use alternate weapons fire, use health packs and 'etc'.

[Hammer]

Actually, even VGA standard bandwidth and chipsets varied but they used the same I/O ports and memory map areas.  I have timed various VGA graphics cards using standard graphics modes (these are older PCI cards) and the Matrox had one of the highest bandwidths (> 2X over ATI), but they were accessed the same way.

PC graphics card comes with a BIOS(firmware).

>Close sourced NVIDIA and ATI driver packages include JIT re-complier engine. You are welcome to write Radeon drivers that would beat the offical Radeon drivers.

Even amongst Radeon cards, they don't use the same I/O ports.  

Which makes “hitting the metal” unfeasible for userland programs. Also, refer to AMD/ATI Radeon's AtomBIOS.

>AMD and NVIDIA offers "close-to-metal" with thier GPUs, but they are vendor specfic. With PS3, NVIDIA provides LibCGM thin-layer.

It's "thin-layer" may be worth it if it's not vendor specific.

In the real world, they are vendor specfic.

>Pre-programmed macros on MS gaming mouse while playing with Xbox 360 players in Gears Of War(via Xbox Live) is an advantage.

>I use an 8 button gaming mouse e.g. able to change sensitivity on-the-fly (two buttons), change weapons, use alternate weapons fire, use health packs and 'etc'.

I still find the simple one/two button-based games fun and easy.  I played this 3D game on playstation where you had to pick up objects but the interface is highly complicated and you miss the object many times and when you are under attack, you have to first set position then move or press one of the buttons to attack back.  By the time you figure it all out, game's over.

There’s a move towards motion controls.

[Hammer]

On the contrary, when Creative had to go from ISA sound cards to PCI ones they had a HELLOVA time making them backwards compatible.  There is also an endless list of "soundblaster emulation" cards which never worked right as because they were "hardware compatible" they couldnt fix it.  However if you use a higher level API and software drivers you can easily patch any compatibility problems later.

My god, I was upgrading in that era when they went from ISA to PCI for sound cards, half the time games wouldn't work properly.  Oh and lets not forget, soundblaster emulation on PCI sound cards is done in SOFTWARE, at least partially.  I believe its something to do with having to emulate the ISA chipset timings which is also why it did not work properly.

The switch to Direct X brilliant as you very very rarely get this sort of problem anymore, it just works.  Kinda breaks your whole argument that backwards compatibility is easy.

Now when talking graphics cards things get even worse as they are so much more complicated.  Do you REALLY think its cost effective to include legacy modes in every single new card you release?  

As for VESA, as I understand it that is still an API but it was mostly supported via the graphics card BIOS which is the only real difference between hardware and software support anyway.  That said, DOS games would always come with software VESA as many graphics cards lacked support, or supported the wrong specification.  So the whole VESA introduction could just have easily been done with software drivers anyway except as people were using DOS (Win95 was not yet a large enough install base to support exclusively) it was easier to keep it in the graphics card BIOS.  The instant enough people were using Win95 over pure DOS though they made the jump, as it was so much easier to support.  If keeping things in hardware was as good as you say, why was it so hard to get DOS games working properly compared to once they made the jump to Windows?
The overhead can't be that bad either as games still improved when we jumped to Windows instead of DOS, despite the fact by your argument the extra power in the PC should have been stolen in API inefficiencies.

And blimey, how large do you think the graphics card BIOS would need to be in order to have backwards compatibility for ALL GPU functions?  How often would it need to be patched to fix bugs?  Quite frankly, its just not practical and you damn well know it.  Using VESA as an argument just seems plain silly, given the above that early VESA was supported via software drivers - very much like how modern drivers support Direct3D today.

Nobody is saying that 100% accurate backwards compatibility would be a bad thing.  I'm sure there are a few benefits from a developers point of view (for a few very rare unusual applications), but you have to live in reality.  There is no PC standard which says your sound/graphics card must talk in this language (apart from VESA and old VGA standards), with these memory addresses, etc.  There is also the little thing of evolution to think of.  If you write a strict standard you are stuck with it, forever.  However with an API if you find more efficient ways of doing stuff at the hardware level, the only restriction is rewriting the software driver.  This is not a whole lot different to how it works at the hardware level except the risk/cost of doing it hardware level is insane (hard to fix once in production, huge BIOS to handle the translation).  And no, directly pushing bits around the GPU directly is simply insanity.  It was fine for Amiga because the chipset was relatively simple, but a modern graphics card GPU is going to be many times more complex than a whole Amiga so claiming that you should have the same hardware access is just plain silly.

Likewise when two competing companies make a graphics card with new functions, how on earth do you propose they would make them compatible with each other without an API?  You can't develop the standard that far in advance of the actual hardware development because you are keeping your cards close to your chest to beat the competition to market with the latest features.

Again, of course a hardware level API like VESA is handy if you want to bang the hardware more directly and save yourself some CPU cycles.  However nobody outside of an insane asylum is going to want that level of control.  Nobody actually NEEDS that level of control.

I still remember TSR SoundBlaster emulators.

[Hammer]

"On the contrary" to what?  Did you like misread or skip some posts?  Sound cards are NOT backward compatible.  I stated an example where some Sound Blaster cards are backward compatible at the hardware level and they can be accessed directly with more efficiency.  I was stating that if they were all like that, that is better.  API restricts your access to hardware for what the function performs and it's inefficient.

Refer to http://developer.nvidia.com/object/nvapi.html

"NVAPI is NVIDIA's core software development kit that allows direct access to NVIDIA GPUs and drivers on all windows platforms. NVAPI provides support for categories of operations that range beyond the scope of those found in familiar graphics APIs such as DirectX and OpenGL."

NVAPI = NVIDIA API. A vendor specfic APIs.

NVAPI was use to enable the current CUDA's Direct3D 10.1 supported features with FarCry2.



FarCry2 is an example of "The way its meant to be played" game.

LibCGM doesn't solve HDR FP + hardware AA problem with NVIDIA's RSX, nor it will solve pixel shader's stalls during texture operations.

>My god, I was upgrading in that era when they went from ISA to PCI for sound cards, half the time games wouldn't work properly.  Oh and lets not forget, soundblaster emulation on PCI sound cards is done in SOFTWARE, at least partially.  I believe its something to do with having to emulate the ISA chipset timings which is also why it did not work properly.

That's your speculation.  Some Soundblaster audio cards ISA and PCI versions of them are hardware compatible.  I can set use I/O locations 220h..22Fh and DMA/IRQs directly.  It's not being done in software as I explained before.

Refer to TSR Soundblaster emulation.

>The switch to Direct X brilliant as you very very rarely get this sort of problem anymore, it just works.  Kinda breaks your whole argument that backwards compatibility is easy.

No it doesn't break the argument, since you never understood the argument according to what you wrote.  APIs restricts your access to the hardware and is less efficient than directly writing to hardware registers if there is backward hardware compatibility.

There's nothing stopping you making a RING 0 program.

I said, "it's not as bad" meaning you can use it along with direct hardware access.  Since setting a mode is nonstandard, you can call it to set a graphics mode and then use direct I/O.  More later if needed.

For custom display modes, you either modify the INF(with NVIDIA's case) or

Part of NVIDIA's control panel (I use 185.70 beta)

or play with NVAPI.