PC still playing Amiga catchup

[alexatkin]

To be fair, the PS3 also has a weaker GPU and a worse memory scheme than the Xbox 360. I see these to be more of a problem. Especially since Sony does have tools available to get you to use the SPU's relatively well even if you don't know how to (API's even ).

Actually there is a lot of argument that the memory is more efficient and that clever coding of the SPEs can make up for the limitations of the GPU and even surpass the 360s one.  

Personally, even if true I see that as a cop out.  Surely the point of a good games console is to make the developers job as easy as possible.  

It also cannot alter the fact that the Xbox 360 could use almost all its memory for textures if the software only needed a tiny amount for its use, and vice versa.  Plus there are a lot of the functions the PS3 has (voice chat in-game, custom soundtracks, etc) that were tagged on after launch and require a LOT more memory taken away from the games than the Xbox, as the Xbox had those functions built-in to the OS and optimised for its allocated memory space since day one. But we digress off topic now.

[alexatkin]

I was referring to direction, deceleration and acceleration on the classic digital joystick.

Indeed.  It may be more accurate to sample quicker, but if someone presses left then right, then lets go of the joystick entirely, all within a screen redraw - your game does not need to know that.  In fact if your game DID react to that action it would seem like the game is not responding correctly to user input, as far as the person at the controls was concerned.

This cannot be compared to audio where you are trying to replicate an analog signal by digital means, so naturally the more detail you can record the better.  Whereas you do not need to record exactly what the persons hands are doing to sufficiently replicate what the game needs to know to react fast enough for it to appear seamless to a human being.  

Maybe if we 1kHz refresh rates on our TV/monitors we could perceive the difference (even if we cannot outright see every single frame itself) but we do not.  Its just logical that if you have a 60Hz screen update then that is the absolute fastest you need to update your game state and so the fastest you need to capture joystick input.

All your game needs to know is the state of the joystick right at the moment it needs to take action based on that input.  You are only going to take action once per screen redraw or again, it will appear to the user that the game is reacting oddly to user input.

In fact, most games may react even slower.  I remember distinctly that some games seem too sensitive to user input and could have done with making sure you are pressing the same button for several screen redraws before reacting.  Its all about synchronising the game response with the users reaction time.

So again, the polling speed of the Amiga joyport is no more useful for gaming than USB1.  Alas a PC keyboard seems pretty slow to react but its still "fast enough" for most games, to the point that home-made MAME cabinets using PCs just have a little keyboard emulator circuit wired up to the joystick and buttons.

[alexatkin]

Erm, that's a bit of a silly way to put it. Really big files aren't going to fit comfortably into memory either. Chances are they'll get paged out to hard disk anyway.



That really depends on your filesystem. Using your Amiga's RAM disk to save disk fragmentation is all well and good but you're ultimately just fragmenting the memory instead. Which isn't a great idea. With 256MB of ram, I've been unable to run an application needing 32MB without a reboot due to this issue.



Use /tmp for your dumping ground and use tmpwatch. Problem solved.



Sure, that's handy sometimes.

Incidentally, you do realise that RAM disks are available on other operating systems, right?

For example:



Et voila, a 16MiB ram disk. It's actually more like RAD, in that it's fixed size, but like RAM: it's entirely volatile.

I actually shoved 8GB of RAM into my Linux box and stuck /tmp into tmpfs as well as commonly used users tmp directories.  Its very handly and there is still plenty of RAM left for normal caching.  For example the first login to KDE is quite slow, the second login is lightening fast.

You also forgot to mention that tmpfs has a fixed size but not a fixed size in memory.  It only uses as much RAM as its contents and if it gets full it pages itself to disk.

Though, how did we end up on this subject anyway?  It doesn't have any bearing on the thread that I can see.

[alexatkin]

I totally gave up on KDE with 4.x *shudder*

Unfortunately every time I try to give up on KDE I find none of the alternatively do everything I want.

KDE4 has a lot of good features, its just REALLY bloated and unstable.  My login regularly suddenly crashes, that very rarely happened with KDE3 and doesn't generally happen with KDE4 under light use - but who wants a 3.2Ghz Core 2 Duo with 8GB RAM for "light use"?

I have been half tempted to just run AmiWM, would have loved it had it continued development but its plain ugly by todays standards and lacking in functionality.  Even Gnome is missing some things I use on a day to day basis that KDE has, sadly.

[alexatkin]

Using Microsoft Habu gaming mouse (powered by Razer), I was able reach less than 1.0 ms e.g. 0.041 ms, 0.004 ms.

For a mouse that is totally relevant.  A mouse can detect your movements down to a really really small degree.  If you are playing a FPS and precisely controlling your movement it is perfectly possible that you might want to turn around quicker than the screen refresh rate can achieve smoothly, in fact its pretty much guaranteed.  

A digital joystick on the other hand is something you can only make decisions on what direction you need to press based on the last screen refresh, so capturing any quicker is of no use.  How is it useful to know if you pressed left then right between screen refreshes when it only needs to know what you are doing right before it updates the screen?

If you were pressing left, then quickly shifted to right but the screen refreshed right before the joystick registered right, then that should naturally count as you pushing nothing.  It knowing more information would not make any difference, the value right at the moment the game logic needs it is what you want.  Its not like you are going to be changing the game several time between refreshes as then the game would seem out of your control as you can only react to what you can see and hear, and those events would be triggered on the refresh.

So seriously, if you were refreshing the joystick port so fast you could register that you pressed left, then nothing, then right - how exactly does that help the game?  It just makes everything more complicated.  Your game does not need to know what you were pressing a few ms ago.

[alexatkin]

The highest audio  tone that can be captured is very slightly less than one-half the sampling rate of an analog-to-digital convertor.
So the 22khz rate will not save sounds much above 10kHz and will result in music missing the highest harmonics,whereas 44(actually 44.1kHz) sampling will save all the sounds even the best human ears can hear,that is up to 22kHz.Most people  lose the hearing of higher pitched sounds as the person ages,especially if exposed to lots of loud sounds.

But how anyone can compare sampling a digital joystick to sampling analog audio, is beyond me.

With audio, its quite obvious that capturing as much accuracy as possible, especially during mixing/mastering, is useful.  The more accurate data you have, the more accurately you will be mixing it.  So that once you drop it back down to 44.1 or 48Khz, you are getting a better approximation.  Thats just plain maths, the more precision the better the more accurate the result.

Now a digital Joystick?  Nobody has yet explained how being able to tell what happened to the joystick between screen refreshes actually has any bearing at all on a game.  Yes sampling quicker is more accurate, nobody every denied that.  But accuracy is only any good when its actually useful.

A mouse its useful to sample quicker, the electronics can counteract any questionable result that way (especially led/laser mice, you could get a rogue reflection from dust, a crack, poor mouse mat) and most of all - there will be less lag from the mouse itself.

Just look at LCD TVs.  The biggest lag on an LCD TV is not the pixel response time, its how quickly the TV can process the signal and actually tell those pixels to change.  That is one reason why a cheap TV and an expensive one often can be really different, even if they are using the same LCD panel.

So yeah, the Amiga joystick port is fast, and it might be useful if you are using it for some custom purpose rather than a joystick.  But then if you are going that direction why use such old technology when you could just use a modern PIC using far far less electricity.  I mean its a silly argument as there are things the Minimig can do that neither the Amiga nor PC can do, but that does not mean PC is trying to catch up to it.

[alexatkin]

Yeah, you can build customized hardware on PC or Amiga or Minimig, but we were talking about using standard PC (what most people have out there).  So that if you wrote a game, you can estimate that joystick reading will take 1.8 microseconds or something like that.

But your whole argument is that the PC does NOT have the necessary standard hardware and that the Amiga does, so it is better.  Therefore you cannot argue against customised hardware as according to you, its the only way the PC can compare to the Amiga.

I fail to see how any of this applies to modern game programming.  Your whole argument has been that the Amiga joyport is good because it can do things that are completely useless for game programming.  Why would a game need to record EXACT joystick actions?  It doesn't.  If it was any use, PCs would still be able to do it.  Games consoles use Bluetooth and other variable latency inputs which are perfectly fine for gaming.  Arguing that having lower latency, being able to probe them quicker, would actually be of any benefit at all, is silly.

No, there's no multitasking needed if application runs going directly to hardware.  Application can take over the timer interrupt that OS is using for multitasking so OS won't be multitasking.  As I stated, see Amiga as an example of a computer that does this.  OS supports multitasking applications but it also supports single tasking applications that can use hardware fully to get the task done most efficiently.

Now you are talking about single tasking?  Guess what, even games consoles are multitasking, multi-threaded computers.  Surely the kind of hardware banging you are talking about makes even DMA really tricky - how would you ever pull those textures in?  The whole point of modern programming is you have different helper threads which can deal with various parts of your game, be written by different developers, but all interact with each other for the end product.  So again, I fail to see how your arguments have any bearing in reality.