In which I troll Squall some more...

Announce new emulators, discuss which games run best under each emulator, and much much more.

Moderator: General Mods

Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

In which I troll Squall some more...

Post by Gil_Hamilton »

because SOMEONE didn't realize the lock request was a blatant attempt by Squall to ensure he had the last word.
Why do you feel the need to validate yourself AS a retard?.
Its not the control, these games expect a deadzone of 127 and instead see 128 which throws the directions off.
Speaking of retarded, center point != dead zone. Make sure you're using your basic terminology properly before you go calling people retarded.


A dead zone is how far you have to move AWAY from center before the controller is recognized as having moved. A dead zone of 127 or 128 would be painfully awful, as you'd have to move the stick very, very far from center before the game ever realized you touched it.

A center point is... well, the point at which the stick is centered.



And yes, the games WILL start acting flaky as the sticks wear, if they really require EXACT centering behavior to function.
You can't see that a stick with worn springs that doesn't return exactly to center might POSSIBLY return to 128,128 instead of 127,127; 126,125; 125,129; or some other equally loose definition of centered(those are co-ordinate pairs. BOTH axes return a value from 0/1-254/255)?

As I said, it not only can happen, but I have personal experience of mis-centering on a worn gamepad. On an actual PS1 system. No exciting bugs were caused, just Solid Snake deciding he NEEDED to creep very slowly to the right if I took my thumb off the stick because my stick wasn't capable of staying perfectly centered and tilted to the right.


Or do you think these numbers are magically divined by the system and don't originate inside the controller, based on the physical location of the thumbstick at the instant of polling, as represented by the resistance value of a pair of potentiometers connected to the lever?

YES, the controller is relevant. 128,128 is a valid coordinate combination, and any game that views access to this point on the stick as a reason to blow up has fundamental issues and will almost certainly explode during routine gameplay.
No where did you explain why only Up and Left work while down and right don't either, stop trying to look smart because you really aren't.
Oh, that's certainly an odd bug. Offhand, I'd guess there's an overflow or divide-by-zero error in there somewhere once the control hits it's maximum.
Assuming your description of the issue is completely accurate, if the game expects a max value of 254 and receives a 255 reported, some assumptions about the math are suddenly wrong, and things can get exciting. I'm not downloading FF8 to experiment with the menu and see what EXACTLY happens under various circumstances, sorry to disappoint.

I've seen other games on other systems with analog joysticks blow up when they received input outside the expected range, though. Interestingly, a few on the Atari 5200 would generate effects very similar to the FF8 bug as defined. With the exception of they'd work fine until they saw 0, and after that they'd never work right until they were reset.


Your links only support the center point being off by 1,1. But that shouldn't cause such cataclysmic results since this can be replicated by pulling the stick VERY SLIGHTLY off-center, which is highly likely to occur at some point during actual gameplay... Unless the game's menu code is waiting for a return to center for some sort of initialization, in which case wiggling the stick very slightly and precisely off-center should cause the game to straighten up and fly right, at least temporarily. It'd be an interesting edge case if it was the cause.

The issue has already been verified in the source code of other PSemu based plugins.
I never said there wasn't an issue. There clearly is.

I've questioned your full and complete definition of the issue, and consider any game that explodes if it sees an imperfectly centered controller to be poorly programmed.

Everything I've ready says the DualShock sends the full 0-255 range.
And it would be highly insane for the console to throw the least-significant bit away after reading it in.
Which means 1-255 or 0-254 is down to physical constraints, and it's EASILY possible for a worn controller to report the full 0-255 range(as well as center to values other than 127,127).




If you don't get the significance of 0-255... it's the maximum range that can be represented by one byte. The DualShock gamepad reads and reports axis data in 1-byte resolution.
7-bit resolution would be 0-127 across the entire axis, making the center point either 63 or 64, depending on how you slice it.

Discarding the least-significant bit gets you a range of 0-254. It also means you can't see any odd value. Not 1, 255, not 3, not 63, not 127, NO odd number, because you have discarded your 1s digit.
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.

You've halved your resolution AND made the gamepad more difficult to read. But you have a 0-254 range... that's mathematically incompatible with a center point of 127.


As you can guess, I'm INCREDIBLY skeptical that the PS1 discards the least-significant bit. It is perhaps the most insane thing they could do.

It also doesn't fit your description of the issue OR linked sources(I actually give credibility to technical details linked by you, I just doubt your interpretation of them as you've demonstrated several times before that you don't understand what you're reading).

And as I said, 128,128 is a valid co-ordinate under any definition of the DualShock gamepad.




Also note, the code you pasted explicitly contradicts your version of the bug, as it explicitly considers 255, not 254, to be the max range of the axis

Code: Select all

   int value = (((int*)&global.JoyState[pad].lX)[pos] + 0x7F);
   if (value >= 0xC0) value++;
   if (value <     0) value = 0;
   // Don't think this happens, but just in case...
   if (value >  0xFF) value = 0xFF;
   return (u8)value;
FF is the hexadecimal representation for 255, which is represented in binary as 1111 1111
Squall_Leonhart wrote:
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
DirectInput represents all bits, not just powers of 2 in an axis.
KHDownloads
Squall_Leonhart
Trooper
Posts: 369
Joined: Tue Jun 10, 2008 6:19 am
Location: Australia
Contact:

Post by Squall_Leonhart »

If you don't get the significance of 0-255... it's the maximum range that can be represented by one byte. The DualShock gamepad reads and reports axis data in 1-byte resolution.
7-bit resolution would be 0-127 across the entire axis, making the center point either 63 or 64, depending on how you slice it.
Discarding the least-significant bit gets you a range of 0-254. It also means you can't see any odd value. Not 1, 255, not 3, not 63, not 127, NO odd number, because you have discarded your 1s digit.
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
DirectInput represents all bits, not just powers of 2 in an axis.

Code: Select all


//Defaults the axis length to 254
int value = (((int*)&global.JoyState[pad].lX)[pos] + 0x7F); =    if (value >= 0xC0) value++;
   if (value <     0) value = 0;
   // Don't think this happens, but just in case...
 // extends the length to 255
   if (value >  0xFF) value = 0xFF;
   return (u8)value;
I've questioned your full and complete definition of the issue, and consider any game that explodes if it sees an imperfectly centered controller to be poorly programmed.
slightly worn would have jittery movement while centered, the most xbox s types do have a bit of jitter by default which is why xbcd has a default deadzone of 10-15., Jitteryness would not cause Menu's in certain games to behave differently to the world map. (Traversing the world map all axis directions are fine). The issue is limited only to menu's which expect a hardcoded centerpoint value of 127. (Blame Square and capcom if anyone).

Everything I've ready says the DualShock sends the full 0-255 range.
Psemu Pro docs say 1-255.
What your saying is 0-255
Matt and whistler say 0-254, and 0-254 works in all the games tested so far with no broken directions.

somebody is wrong somewhere and matts change works.

but i can see your math now, which i thought was wrong myself.

ah, but the center value is half the range. so 0-254 would be correct because 127 becomes the center.

0 : 127 : 254.

127 would not be the center if you start from 1.
That said, if you use a length of 255 you would need to center at 127.5, which makes it impossible for a axis of 1-255 to center at 128 as then the range would have to be 1-257.

a Logical range of -127 : 0 : +127 is 255bits
a Physical range of 0 - 254 is 255 bits.
Physical Ranges ALWAYS start at 0,
The physical Center of 0-254 is 127.

Now that said, a logical range doesn't have to have the same range from -values to 0, as from 0 to positive values, so you can have a logical range of -512 to +511, most of the time you're going to find both add up though.

The games i mentioned are expecting the device to use a physical center value of 127, and to achieve that on a range of 255bits the highest value is 254 while the lowest is 0.
[img]http://img.photobucket.com/albums/v253/squall_leonhart69r/Final_Fantasy_8/squall_sig1.gif[/img]
[url=http://vba-m.com/]VBA-M Forum[/url], [url=http://www.ngohq.com]NGOHQ[/url]
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

Mind if i grab some popcorn ?

Because
Squall_Leonhart wrote:DirectInput represents all bits, not just powers of 2 in an axis.
is pretty damn up there on the scale.

oh hey, can't forget
a Logical range of -127 : 0 : +127 is 255bits
a Physical range of 0 - 254 is 255 bits.
Physical Ranges ALWAYS start at 0
either.

gotta love those 256 bits NES consoles
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Agozer
16-bit Corpse | Nyoron~
Posts: 3534
Joined: Sun Aug 01, 2004 7:14 pm
Location: Nokia Land

Post by Agozer »

nerd rage overload

I confess that I don't know much about the topic at hand, but I'm willing to learn bits and pieces. So the premise is that Squall is full of it and only aims to show off his supposed, yet faulty knowledge, or what?
whicker: franpa is grammatically correct, and he still gets ripped on?
sweener2001: Grammatically correct this one time? sure. every other time? no. does that give him a right? not really.
Image
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

Agozer wrote:So the premise is that Squall is full of it and only aims to show off his supposed, yet faulty knowledge
More or less
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Post by Gil_Hamilton »

Squall_Leonhart wrote:
If you don't get the significance of 0-255... it's the maximum range that can be represented by one byte. The DualShock gamepad reads and reports axis data in 1-byte resolution.
7-bit resolution would be 0-127 across the entire axis, making the center point either 63 or 64, depending on how you slice it.
Discarding the least-significant bit gets you a range of 0-254. It also means you can't see any odd value. Not 1, 255, not 3, not 63, not 127, NO odd number, because you have discarded your 1s digit.
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
DirectInput represents all bits, not just powers of 2 in an axis.
I'm sorry, we're talking about PLAYSTATION controllers and the PS1 DUALSHOCK interface, right?

Powers of 2 is important because that's how computers count.

Code: Select all


//Defaults the axis length to 254
int value = (((int*)&global.JoyState[pad].lX)[pos] + 0x7F); =    if (value >= 0xC0) value++;
   if (value <     0) value = 0;
   // Don't think this happens, but just in case...
 // extends the length to 255
   if (value >  0xFF) value = 0xFF;
   return (u8)value;
I've questioned your full and complete definition of the issue, and consider any game that explodes if it sees an imperfectly centered controller to be poorly programmed.
slightly worn would have jittery movement while centered, the most xbox s types do have a bit of jitter by default which is why xbcd has a default deadzone of 10-15., Jitteryness would not cause Menu's in certain games to behave differently to the world map. (Traversing the world map all axis directions are fine). The issue is limited only to menu's which expect a hardcoded centerpoint value of 127. (Blame Square and capcom if anyone).
*sigh*

You don't get it. The game can't tell if the stick is centered and reporting the wrong value, or actually physically off-center.
If the game truly requires the stick to return to absolute dead-perfect centered to function properly, then it WILL NOT WORK WITH A REAL STICK THAT FAILS TO PROPERLY CENTER TO 127,127 DUE TO LOOSE SPRINGS.

Everything I've ready says the DualShock sends the full 0-255 range.
Psemu Pro docs say 1-255.
What your saying is 0-255
Matt and whistler say 0-254, and 0-254 works in all the games tested so far with no broken directions.

somebody is wrong somewhere and matts change works.
The only fix you've pasted changes the center value, not the range.


Your own pasted code fix says the range is 0-255. Excuse me, 0x00 to 0xFF.

You should really link and paste references that support your interpretation.


I assume http://code.google.com/p/pcsx2/source/detail?r=2587 is the Matt you're referencing.

He makes no mention of changing the range. Just the center value.
Ah, and I see in the diff of PadSSSPSX.cpp that the changes is the code block you pasted earlier.
So no, Matt DIDN'T change it to 0-254. He changed it to treat 127 instead of 128 as center, and added bounds checking to prevent the reporting of values less than 0 or greater than 255.
The Matt you are referring to, in his code, EXPLICITLY STATES the range is 0-255.


If you need a reminder, it looked like this.


int value = (((int*)&global.JoyState[pad].lX)[pos] + 0x7F);
if (value >= 0xC0) value++;
if (value < 0) value = 0;
// Don't think this happens, but just in case...
if (value > 0xFF) value = 0xFF;
return (u8)value;


The important lines are
if (value < 0) value = 0;
This takes any negative values and replaces them with 0. In other words, it says that this function cannot return a value less than zero, and the axis' minimum range is 0.

and

if (value > 0xFF) value = 0xFF;
This takes any value greater than 0xFF, and replaces it with 0xFF. In other words, it says that this function cannot return a value greater than 0xFF, and the axis' maximum range is 0xFF.


Those are your lower and upper limits. 0 is 0 is 00000000, 0xFF is 255 is 11111111.


Your own source for 0-254 explicitly says 0-255.
Game, set, and match.

but i can see your math now, which i thought was wrong myself.

ah, but the center value is half the range. so 0-254 would be correct because 127 becomes the center.

0 : 127 : 254.

127 would not be the center if you start from 1.
That said, if you use a length of 255 you would need to center at 127.5,
Except 127.5 is not possible. So they choose one side or the other to treat as centered.

You CAN restrict your range if you're excessively anal about your logical representation of the stick, but it gains you nothing, just makes your code far more complex.

a Logical range of -127 : 0 : +127 is 255bits
a Physical range of 0 - 254 is 255 bits.
YOU do not understand computers.
A range of 0 to 254 is 7.something-or-other bits.
As is a range of -127 to +127

EIGHT bits gets you 256 different values.

And by the way, a signed 8-bit integer will have one more negative value than positive value due to the way negatives are represented. -128 to +127 is the signed range for 8 bits.


Edit: And 255 bits gets you a range from 0 to 5.789 * 10^76. That's scientific notation, because I'm not typing a 77-digit number and Windows Calculator didn't display one anyways.
What, you thought I was going to do 2^255 by hand?
Physical Ranges ALWAYS start at 0
Actually, physical ranges start at... about 45 degrees?
Electrical ranges typically start at 0 ohms, with the other end of the range at infinite ohms.
Only logical ranges are bound to the computer's way of counting.
The physical Center of 0-254 is 127.
No, you're into logic now. The 0-255 is after it's been digitized and converted to a 1-byte value.

Now that said, a logical range doesn't have to have the same range from -values to 0, as from 0 to positive values, so you can have a logical range of -512 to +511, most of the time you're going to find both add up though.
Not with a 1-byte resolution you don't.

The games i mentioned are expecting the device to use a physical center value of 127, and to achieve that on a range of 255bits the highest value is 254 while the lowest is 0.
No, to achieve a center point of 127 is to arbitrarily choose one value over another to represent center.




I repeat: Your own source that you're appealing to in an effort to prove 0-254 says the range is 0-255.

And I'll say it again...
MattMenke says
if (value < 0) value = 0;
if (value > 0xFF) value = 0xFF;

And one more time.
You are wrong. You do not understand how computers work.





Edit: some quote-tag mangling.
Squall_Leonhart wrote:
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
DirectInput represents all bits, not just powers of 2 in an axis.
KHDownloads
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

Gil_Hamilton wrote:EIGHT bits gets you 256 different values.

And by the way, a signed 8-bit integer will have one more negative value than positive value due to the way negatives are represented. -128 to +127 is the signed range for 8 bits.
Some salt: only with the oh-so-easy to take for granted 2's complement notation.

If you're a poor sap working on a 1's complement (or a sign/magnitude) environment for some reason, you get only -127 to 127. But you have double the precision on 0, yay !!1!
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
odditude
Official tech support dood
Posts: 2118
Joined: Wed Jan 25, 2006 7:57 am

Post by odditude »

grinvader wrote:If you're a poor sap working on a 1's complement (or a sign/magnitude) environment for some reason, you get only -127 to 127. But you have double the precision on 0, yay !!1!
mmm, reminds me of number formats in assembly class and people going "how can there be a +0 and a -0? it's 0, isn't it..?"

still, that was less painful than the deer-in-headlights stares that IEEE754 elicited...
Why yes, my shift key *IS* broken.
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Post by Gil_Hamilton »

grinvader wrote:
Gil_Hamilton wrote:EIGHT bits gets you 256 different values.

And by the way, a signed 8-bit integer will have one more negative value than positive value due to the way negatives are represented. -128 to +127 is the signed range for 8 bits.
Some salt: only with the oh-so-easy to take for granted 2's complement notation.

If you're a poor sap working on a 1's complement (or a sign/magnitude) environment for some reason, you get only -127 to 127. But you have double the precision on 0, yay !!1!
Are there still any platforms that due that? I thought that was mainly a legacy thing.
Squall_Leonhart wrote:
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
DirectInput represents all bits, not just powers of 2 in an axis.
KHDownloads
Rashidi
Trooper
Posts: 515
Joined: Fri Aug 18, 2006 2:45 pm

Post by Rashidi »

Gil_Hamilton wrote:
grinvader wrote:
Gil_Hamilton wrote:EIGHT bits gets you 256 different values.

And by the way, a signed 8-bit integer will have one more negative value than positive value due to the way negatives are represented. -128 to +127 is the signed range for 8 bits.
Some salt: only with the oh-so-easy to take for granted 2's complement notation.

If you're a poor sap working on a 1's complement (or a sign/magnitude) environment for some reason, you get only -127 to 127. But you have double the precision on 0, yay !!1!
Are there still any platforms that due that? I thought that was mainly a legacy thing.
that reminds me of some electrical engineering class where they supposedly try to make a simple ALU (add & substract only)
using simple gates ( or, and, not, nand, nor, xor, stuff )
and the input was in 1's comploment (yeah, the double +/- 0)

those who failed that were to take make-up exams with similar objective but this time the input was the normal 2's ...
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

Gil_Hamilton wrote:Are there still any platforms that due that? I thought that was mainly a legacy thing.
Pretty much every used intertubes protocol checksum in 1's complement due to bit error ratio or smth... never read the rfc1071.
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Ichinisan
Veteran
Posts: 603
Joined: Wed Jul 28, 2004 8:54 am

Post by Ichinisan »

All this reminds me of the N64.

With the N64, Nintendo used optical sensors instead of potentiometers to make sure to make sure it was 100% accurate and precise (not considering the wear on the mechanical parts). I don't know if there was a cost in resolution, but I know of several examples do demonstrate why it is important.

Third-party controllers used regular potentiometers. I noticed that, in Blast Corps, walking characters would walk BACKWARD when the directional value was beyond the expected range. You could test this by deliberately setting the wrong center position (Hold L+R and press Start while the thumbstick is NOT centered), then push the thumbstick to the extreme opposite site of the new center position.

One of the better-looking 3rd-party N64 controllers was called "The Rock". I don't recall the brand exactly, but I know that the shoulder buttons looked like triggers...so there were three triggers overall. This controller was basically "over-driving" in all directions...so you could moon-walk all over the place in Blast Corps.

More importantly, I noticed that third-party controllers would cause me to RANDOMLY SPIN-OUT IN MARIO KART 64. It's more likely to happen if you're hit by flying debris (bats, coconuts, etc), but it also happens out-of-the-blue for no apparent reason. I eventually concluded that this is because the stick allows you to turn slightly beyond the expected range of motion for a 1st-party N64 pad, and some quirk in the game engine's play control is affected. I was very disappointed to see that Nintendo's Wii Virtual Console version of MK64 has this problem whn using the Wii Classic Controller. I am not sure if it does this when you use a Gamecube controller.

Many PC game controllers have a square range, allowing values that the real console would never receive with an original controller (like 255, 255). If emulators automatically adapt this so that the lower-right corner of the square appears to be within the circular-range expected by the emulated console, you get some inconsistency due to the conversion. Many emulators apply this conversion to all PC input devices, assuming they all have a square range. If you are using a PC controller that is already limited to a circle-range, it gets much worse: Usable range and resolution is lost. It's almost impossible to do the circle-motion slash in Zelda:OoT (the sword spin that doesn't waste magic).

The Adaptoid is the coolest idea for a console adapter, because the optional driver includes an API that allows N64 emulators to talk to a real N64 controller directly. This completely solves the range / precision problem with an original controller and also allows real accessories to work with an emulator. Nearly all PC N64 emus support the Adaptoid API through input plugins. Without the optional software, the adapter converts the circle axis to a square axis...so the lower-right corner of the N64's circle range shows as 255,255 on the gamepad test on the Windows Control Panel.

Someone needs to work on adapters with this type of support for ALL emulated systems! For example: I'm really not interested in an SNES adapter that merely creates a PC joypad; I'm interested in one that allows an emulator to communicate with any SNES controller-port accessory.

With all of the PSX accessories (light-guns, mouses, guitars, dance mats, flight-sticks, steering wheels, vibrators, etc), someone MUST do this for PSX/PS2 controllers!

(If something this does exist and I missed it, please let me know. I've been out of it for a while.)
Need a new sig...
paulguy
Zealot
Posts: 1076
Joined: Sat Jul 02, 2005 2:01 am
Contact:

Post by paulguy »

I could see why the support for such a thing was added for the N64, so people could use their memory cards. Could the Adaptoid be used for really oddball addons like the microphone? I could see this working for stuff like N64 and playstation, but I don't know how well it'd work with the SNES. That stuff is very timing sensitive and something like the super scope wouldn't work too well on modern PCs and emulators, especially since the emulators tend to be a frame or 2 late, and the screen scanning is never synced up to what the game expects it to be. Not sure why there haven't been any such things for the playstation, though I believe the majority of things like dance mats, steering wheels, guitars and whatnot do work with most adapters, though some axes might be assigned weirdly or just not assigned at all on certain adapters... I guess you'd have to do some research beforehand or risk experimentation if you have a strange device. And I believe the vibrator is USB; the linux kernel has a module for it.
Ichinisan
Veteran
Posts: 603
Joined: Wed Jul 28, 2004 8:54 am

Post by Ichinisan »

paulguy wrote:I could see why the support for such a thing was added for the N64, so people could use their memory cards. Could the Adaptoid be used for really oddball addons like the microphone?
I never actually did it, but I believe it worked. I believe it also worked with the 64GB pack. Definitely worked with memory paks and the rumble pak.
paulguy wrote:I could see this working for stuff like N64 and playstation, but I don't know how well it'd work with the SNES. That stuff is very timing sensitive and something like the super scope wouldn't work too well on modern PCs and emulators, especially since the emulators tend to be a frame or 2 late, and the screen scanning is never synced up to what the game expects it to be.
It might still be useful for barcode scanners, mouse controllers, etc.
paulguy wrote:Not sure why there haven't been any such things for the playstation, though I believe the majority of things like dance mats, steering wheels, guitars and whatnot do work with most adapters, though some axes might be assigned weirdly or just not assigned at all on certain adapters... I guess you'd have to do some research beforehand or risk experimentation if you have a strange device. And I believe the vibrator is USB; the linux kernel has a module for it.
Interesting. Because the PS1 didn't have USB ports, I'm sure there are some unusual accessories that need a controller port. Because PS1 emulators use input plug-ins like N64 emulators do, I'm sure that a special adapter with an an API would be adopted by input plugin developers and enthusiasts.
Need a new sig...
paulguy
Zealot
Posts: 1076
Joined: Sat Jul 02, 2005 2:01 am
Contact:

Post by paulguy »

Oh, I didn't know there was a PS1 vibrator... I just knew about the PS2 trance vibrator.

Would be nice to see, and I'm also unsure of why it hasn't been done at least for the more modern consoles.
I.S.T.
Zealot
Posts: 1325
Joined: Tue Nov 27, 2007 7:03 am

Post by I.S.T. »

He was referring to the N64 Rumble Pack. >_>
adventure_of_link
Locksmith of Hyrule
Posts: 3634
Joined: Sun Aug 08, 2004 7:49 am
Location: 255.255.255.255
Contact:

Post by adventure_of_link »

..do they even make adaptoids anymore? :?
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Post by Gil_Hamilton »

Ichinisan wrote:All this reminds me of the N64.

With the N64, Nintendo used optical sensors instead of potentiometers to make sure to make sure it was 100% accurate and precise (not considering the wear on the mechanical parts). I don't know if there was a cost in resolution, but I know of several examples do demonstrate why it is important.

Third-party controllers used regular potentiometers. I noticed that, in Blast Corps, walking characters would walk BACKWARD when the directional value was beyond the expected range. You could test this by deliberately setting the wrong center position (Hold L+R and press Start while the thumbstick is NOT centered), then push the thumbstick to the extreme opposite site of the new center position.

One of the better-looking 3rd-party N64 controllers was called "The Rock". I don't recall the brand exactly, but I know that the shoulder buttons looked like triggers...so there were three triggers overall. This controller was basically "over-driving" in all directions...so you could moon-walk all over the place in Blast Corps.

More importantly, I noticed that third-party controllers would cause me to RANDOMLY SPIN-OUT IN MARIO KART 64. It's more likely to happen if you're hit by flying debris (bats, coconuts, etc), but it also happens out-of-the-blue for no apparent reason. I eventually concluded that this is because the stick allows you to turn slightly beyond the expected range of motion for a 1st-party N64 pad, and some quirk in the game engine's play control is affected.
That's not an accuracy issue. That's pure range over/underflow(*flow errors are awesome), like Squall was insisting was happening on the PS1.

Harder to predict and correct for *flow on the N64 controller since it's a delta instead of a raw position.
Hmmm... does the pad report the raw delta, or convert to position data internally?


On the subject of oddly-designed analog stick assemblies... Sega used Hall effect sensors on the Dreamcast pad.

And the mecahnical wear issues on the N64 weren't inherent to the optical stick. Just Nintendo's specific design.
Pity, really. It IS a good idea, and with a proper mechanical design would offer a MUCH more reliable input device.
Much like moving potentiometer polling from the console to the gamepad did. *glares at his Atari 5200 controllers and their wildly drastic pot variances*
I was very disappointed to see that Nintendo's Wii Virtual Console version of MK64 has this problem whn using the Wii Classic Controller. I am not sure if it does this when you use a Gamecube controller.
Way to go, Nintendo!

Someone needs to work on adapters with this type of support for ALL emulated systems! For example: I'm really not interested in an SNES adapter that merely creates a PC joypad; I'm interested in one that allows an emulator to communicate with any SNES controller-port accessory.
Definitely.
It's not often noticed, but that was a big loss when the emulators alll moved to DirectInput instead of internalized controller drivers and ye olde parallel port adapter support(though in most situations, the convenience of USB controllers outweighed this disadvantage).
With all of the PSX accessories (light-guns, mouses, guitars, dance mats, flight-sticks, steering wheels, vibrators, etc), someone MUST do this for PSX/PS2 controllers!
Not to nitpick, but reduce that to light guns, mice, and guitars.

Dance mats, flight sticks, and steering wheels all appear as (semi+)standard PS* gamepads.

PS1 Steering wheels are usually swappable between digital, DualShock and neGcon mode. PS2 wheels are read as DualShock 2s.

Exception for the PS1 Dual Analog flight stick, which the Dual Analog gamepad emulated(but the DualShock did not). That's not usable. Any other flight stick will read as a DualShock(2).





+PS1 wheels can't be read by adapters in neGcon mode, but can in DualShock mode.
This MAY affect overall functionality, though. The neGcon had analog face buttons for the throttle and brake, and I THINK PS1 wheels in DualShock mode provide digital throttle/brake data instead of mapping to the R-stick axes, but I'm not sure.

(If something this does exist and I missed it, please let me know. I've been out of it for a while.)
As far as I know, it doesn't, except when using DOS and ye olde parallel port adapter.





Edit: And Squall STILL owes me an apology for calling me a retard when I was right and he was spouting pseudo-technical nonsense.
Squall_Leonhart wrote:
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
DirectInput represents all bits, not just powers of 2 in an axis.
KHDownloads
kode54
Zealot
Posts: 1140
Joined: Wed Jul 28, 2004 3:31 am
Contact:

Post by kode54 »

And forget about light guns. Not only do they only work with CRT monitors, but you'd also need a way to ask the video card which pixel it's currently scanning to the monitor. At least I think so.
Rashidi
Trooper
Posts: 515
Joined: Fri Aug 18, 2006 2:45 pm

Post by Rashidi »

Dance mats
that stuff allow {Left}+{Right} and/or {Up}+{Down} to be 'pressed' simultanously, something that more modern gamepads/stick less able to do...
at least that can still be emulated using keyboard, somewhat.
Johan_H
Starzinger Addict
Posts: 998
Joined: Tue Aug 17, 2004 1:14 pm
Location: Sweden
Contact:

Post by Johan_H »

Rashidi wrote:
Dance mats
that stuff allow {Left}+{Right} and/or {Up}+{Down} to be 'pressed' simultanously, something that more modern gamepads/stick less able to do...
at least that can still be emulated using keyboard, somewhat.
Or by breaking the d-pad, worked for one of our PS1 controllers...
kode54
Zealot
Posts: 1140
Joined: Wed Jul 28, 2004 3:31 am
Contact:

Post by kode54 »

That reminds me of a friend I know who modified at least one of his PSX pads by splitting the d-pad into four pieces to allow more precise direction pressing. Great for things like the d-pad combos in Castlevania: SoTN.
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Post by Gil_Hamilton »

kode54 wrote:And forget about light guns. Not only do they only work with CRT monitors, but you'd also need a way to ask the video card which pixel it's currently scanning to the monitor. At least I think so.
Some can fake it. There was a 3rd-party Guncon2 clone that worked with LCDs(and 100Hz displays, LOL PAL).
Squall_Leonhart wrote:
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
DirectInput represents all bits, not just powers of 2 in an axis.
KHDownloads
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

For your amusement, more Squall on things that are broken when made available... if broke, blame user for... being the user: http://www.ngohq.com/news/17390-nvidia- ... n-bug.html
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Post by Gil_Hamilton »

Deathlike2 wrote:For your amusement, more Squall on things that are broken when made available... if broke, blame user for... being the user: http://www.ngohq.com/news/17390-nvidia- ... n-bug.html
Wow.
It's all the user's fault that nVidia released drivers that burn out graphics cards!
Oh, and Blizzard for writing games that burn out graphics cards!



Bizarrely, I found him in a discussion about a beta of a popular instant messaging app(long story short, I HATE the current incarnation of Messenger, and was looking for an older build to downgrade to).

Not NEAR as hilarious, but...
RE:Windows Live Messenger 9.0 Beta Download by squall_leonhart on 2007-11-28 23:36:30

I hope this version errors and corrupts your OS installs

its an early beta not meant for mass usage and has quite a few data loss bugs.

oh wel, i warned you.
I actually used this beta at the time. It was QUITE stable, and exhibited no data loss whatsoever.
Squall_Leonhart wrote:
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
DirectInput represents all bits, not just powers of 2 in an axis.
KHDownloads
Post Reply