| Main > Lightguns |
| GUN4IR - The Ultimate 4 Points Lightgun System |
| << < (209/227) > >> |
| JayBee:
--- Quote from: RandyT on October 16, 2022, 09:12:32 am --- --- Quote from: JayBee on October 16, 2022, 02:44:02 am ---That is something no other lightguns in the market can achieve at the moment, especially not with levels of accuracy also beating CRT guns ;) But you don't need to believe me on that, I'm preparing some videos to show that off, since I'm getting tired of people getting skeptical when I talk about my system performances :lol --- End quote --- I'd definitely be interested in seeing a video backing up that claim :). I have a dedicated 36" CRT and a PS2 with GunCons connected to it via RGB. Speed and accuracy are at least "arcade quality" with this setup, but it's limited to the PS libraries. FWIW, my interest in all of this is to turn that into a "gun system" which is capable of playing all of the light gun games with one gun and the same speed and accuracy as a GC2. So, I'd be a happy camper if that is truly the case, and the minimum distance wasn't further than the 5 or so feet away I normally play from it. --- End quote --- Haven't had time to work on the vids lately, and not sure I will have time soon, so I made a quick side by side comparison of the native guncon 1 (connected with SNAX on the mister fpga, so as native as on a real ps1) vs the usb gun4ir, on a ps1 guncon game calibration screen. I let you draw the conclusions you want with it ;) |
| RandyT:
--- Quote from: JayBee on December 28, 2022, 12:15:55 pm ---I let you draw the conclusions you want with it ;) --- End quote --- My conclusion is that your system is as fast as a stabilized (i.e. over-sampled) cursor in the calibration screen. ;) Unfortunately, no other conclusion can be really be drawn when using that screen as a basis for comparison. For purposes of calibration, the console averages the heck out of the cursor position data to find the mean position, as this will likely be a relatively stable representation of where the gun is actually pointing when not being averaged during the course of normal play. That way, any deviation which occurs will be small and usually within the pre-defined hit-box set up in the game code. If the code is acting on, for example, 50 of the GC's samples and only 10 of yours (not saying this is the case) you will not see it here. In other words, that screen is a poor test for the purposes you most likely had in mind and probably doesn't demonstrate what you think it does. :) |
| JayBee:
--- Quote from: RandyT on December 30, 2022, 01:09:29 pm --- --- Quote from: JayBee on December 28, 2022, 12:15:55 pm ---I let you draw the conclusions you want with it ;) --- End quote --- My conclusion is that your system is as fast as a stabilized (i.e. over-sampled) cursor in the calibration screen. ;) Unfortunately, no other conclusion can be really be drawn when using that screen as a basis for comparison. For purposes of calibration, the console averages the heck out of the cursor position data to find the mean position, as this will likely be a relatively stable representation of where the gun is actually pointing when not being averaged during the course of normal play. That way, any deviation which occurs will be small and usually within the pre-defined hit-box set up in the game code. If the code is acting on, for example, 50 of the GC's samples and only 10 of yours (not saying this is the case) you will not see it here. In other words, that screen is a poor test for the purposes you most likely had in mind and probably doesn't demonstrate what you think it does. :) --- End quote --- No, that means the latency of my gun system, with a PS1 60Hz game (in that case PS1 NTSC Point Blank), is as good as the original native PS1 gun connected to the native PS1 port (not USB). The aim smoothing isn't working at all in the way you think it works ;) The in-game sample logic is always the same no matter the gun here. In this setup, the game sees both guns as guncons and so treat them equally. One is a real native guncon with native direct ps1 connection, and the other uses a conversion from gun4ir usb data to guncon ps1 protocol. In that calibration screen, on similar motion, the total added latency by the smoothing will always be the same on every gun. For instance if you average the aim over a constant sample of 4 frames, then the added latency on equal motions will always be equal, allowing you to compare each of the guns on equal ground over the course of a few motions. It's very basic math. It doesn't magically change the smoothing sample depending on the gun like you believe, ps1 wasn't that modern and has no way to differentiate the guns here :lol I even used a music metronome for that video to reproduce the same matching rythm, trajectory and speed of motion with both gun. So in short if a gun had more latency than the other one, it WOULD be very visible. And this video is in no way to show the aim accuracy, as the accuracy was already shown extensively in the previous videos. The only reason I use that calibration screen is because it's the only one that has native IN GAME crosshair tracking with constant (non variable) aim smoothing/latency, that allows me to have precise comparison of the motion latency between guns. But I though all that was pretty obvious and everyone understood it. I don't know exactly what I did to you or why you decided to be so anti gun4ir, but it is very clear now that no matter how good my proofs are, you won't believe them and will always find convoluted excuses not to. So I'm done losing my time trying :dunno If you have something against me or my system, stop fooling around with the passive agressitivy, be brave and say what you have to say right to my face, here or in pm ;) Assume your point of view whatever it is. Meanwhile, believe whatever you want about it. You do you bud :cheers: |
| RandyT:
Not sure if it's intentional, but it seems like you totally missed what I wrote. I'm not sure how it's possible, because I even took the time to explain it. No-one ever implied that the code treated one gun different from another. Just the opposite, in fact. The calibration screens average a bunch of samples before displaying a position on the screen, which is the reason why the cursor lags behind the gun position when it's moving. Therefore, it cannot show how fast EITHER system is. With that screen, we know that it is acting on every authentic sample from the real GC, because it is programmed to work at the limits of that technology. In the case of emulated controls, the sample rate of the code will be the same, but the rate at which that data changes in whatever temporary buffer in which it is stored, cannot be discerned. i.e. if a non-GC gun is used, it just plucks data from the buffer at the rate it is expected to have been updated, and if it is unchanged due to a difference in actual reporting rate from the device, it doesn't care. It will happily collect duplicate reports and average them into the position. How much or if any differences will be visible is extremely dependent upon the speed at which the gun is moving, the number of samples taken and the amount of deviation in each respective group of samples. i.e. variables which are virtually impossible to control. No-one is implying that your system doesn't do what you claim. But I am stating as a matter of fact that the method you are attempting to use to demonstrate that claim, is terribly flawed. But if this test is the one you used to come to your conclusion, you may wish to find a different method, because this one is incapable of showing you what you appear to want it to. But in the end, there's no need to make grandiose claims or worry about backing them up. Either the system works well-enough or it doesn't. Everything in-between is academic. Attempting to villainize someone who points out discrepancies in what is a technical discussion seems equally unnecessary. |
| JayBee:
--- Quote from: RandyT on December 31, 2022, 11:05:43 am ---Not sure if it's intentional, but it seems like you totally missed what I wrote. I'm not sure how it's possible, because I even took the time to explain it. No-one ever implied that the code treated one gun different from another. Just the opposite, in fact. --- End quote --- Oh I read everything carefully, english isn't my native language obviously but you don't write anything hardly difficult to understand. Somehow you continiously miss the point and lose youself in pointless overthinking/overanalysing. You misunderstand how that tech and how the MiSTer FPGA input handling work, or what I am showing here. --- Quote from: RandyT on December 31, 2022, 11:05:43 am ---The calibration screens average a bunch of samples before displaying a position on the screen, which is the reason why the cursor lags behind the gun position when it's moving. --- End quote --- No kidding, sherlock. --- Quote from: RandyT on December 31, 2022, 11:05:43 am --- Therefore, it cannot show how fast EITHER system is. With that screen, we know that it is acting on every authentic sample from the real GC, because it is programmed to work at the limits of that technology. --- End quote --- Yes, it doesn't measure how fast either of the gun are, it shows the latency difference, on a big enough sample with similar enough gun motion to be significative, with the limit of the tech in mind. --- Quote from: RandyT on December 31, 2022, 11:05:43 am --- In the case of emulated controls, the sample rate of the code will be the same, but the rate at which that data changes in whatever temporary buffer in which it is stored, cannot be discerned. i.e. if a non-GC gun is used, it just plucks data from the buffer at the rate it is expected to have been updated, and if it is unchanged due to a difference in actual reporting rate from the device, it doesn't care. It will happily collect duplicate reports and average them into the position. --- End quote --- The sample rate of the emulated controls is totally irrelevent here. The PS1 reads the guncon input only once a frame obviously, so in the best case scenario, the gun4ir itself + conversion of the HID data to the guncon data will take less than that and there will be no difference with the original guncon. And in the worst case it's slower than a frame, missing the mark and adding one (or more) frame of latency compared to the guncon. --- Quote from: RandyT on December 31, 2022, 11:05:43 am ---How much or if any differences will be visible is extremely dependent upon the speed at which the gun is moving, the number of samples taken and the amount of deviation in each respective group of samples. i.e. variables which are virtually impossible to control. --- End quote --- Again, duh. You completely ignored the part where I explained my methodology. Oh sure it's not super ultra precise to the 10th of ms or 2mm motion between each gun, but it doesn't need to be, the motion is similar enough to be usable. As I explained if the gun input + conversion isn't fast enough it will add one or more frames of latency, 16ms each, even with the smoothing. No matter the minor differences of speed and acceleration between each gun motion, any difference that big would be very visible on the vid I show here, despite the small duration of the vid (trying to avoid harming epileptic people with long vid of blinking lights). Just take any as many points of reference in the video as you want and see how many 60Hz frame it takes for each gun crosshair to reach the passing position of the gun aim. It's all a balance between precision of the test, and what we want to show, while keeping it simple and readable. --- Quote from: RandyT on December 31, 2022, 11:05:43 am ---No-one is implying that your system doesn't do what you claim. --- End quote --- You did, more than a few times, in your usual way ;) --- Quote from: RandyT on December 31, 2022, 11:05:43 am ---But I am stating as a matter of fact that the method you are attempting to use to demonstrate that claim, is terribly flawed. But if this test is the one you used to come to your conclusion, you may wish to find a different method, because this one is incapable of showing you what you appear to want it to. --- End quote --- No "matter of fact" here, just your own opinion, that has absolutely no more value than anybody else. Having a good english semantic and claiming you know your stuff doesn't make you right. You don't seem to have any real interest in using my system, or contributing to it, so I have no clue what's your issue with me and my work and why you keep going at it like that :dunno Anyway it's my thread so obviously I feel obligated to answer, but man what a massive waste of time. --- Quote from: RandyT on December 31, 2022, 11:05:43 am ---But in the end, there's no need to make grandiose claims or worry about backing them up. Either the system works well-enough or it doesn't. Everything in-between is academic. --- End quote --- No grandiose claim here, just doing my job to inform my users. By saying everything in between is academic, or that backing up the claims isn't useful, you are basically saying the users are too stupid to want to know the real specs and performance of the product. I don't know about you, but that isn't how I treat my users. If I did we both know my system wouldn't be as popular as it is now. |
| Navigation |
| Message Index |
| Next page |
| Previous page |