Image Map Image Map
Page 13 of 21 FirstFirst ... 391011121314151617 ... LastLast
Results 121 to 130 of 204

Thread: MagiDuck, a DOS / CGA text mode game project

  1. #121
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    4,563
    Blog Entries
    1

    Default

    Quote Originally Posted by Scali View Post
    So in theory you'd only need to determine the worst-case interval, and then divide it by 3 in order to get the left-middle-right intervals.

    Actually no, since sticks can have non-linear properties (especially if they're not calibrated). That's why "proper" joystick calibration routines, if you need the full analog granularity, have you move to one corner, then the opposite corner, then the center. They can then interpolate between the measured values and translate new readings to theoretical "perfect" linear values.

    Quote Originally Posted by Scali View Post
    So you could set up a timer interrupt at the start of a frame, then poll it 3 times, and call it a day.
    Finding the correct 3 times is the difficult part, as it is potentially different on each system. Later joystick interfaces also have a switch on them for different "speeds" (I'm not sure what the switch does).

    Distinctive Software titles (Out Run, Test Drive, Stunts) had a pretty nice analog-to-digital routine; hitting ctrl-J in those programs portrayed what looked like a tic-tac-toe board, and all you had to do was move the stick around to all 9 squares to calibrate. I have no idea what it looked like under the hood; would make for an interested RE project.
    Offering a bounty for:
    - Documentation and original distribution disks for: Panasonic Sr. Partner, Corona PPC-400, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)
    - Any very old/ugly IBM joystick (such as the Franklin JS-123)

  2. #122
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,670

    Default

    Quote Originally Posted by Trixter View Post
    Finding the correct 3 times is the difficult part, as it is potentially different on each system. Later joystick interfaces also have a switch on them for different "speeds" (I'm not sure what the switch does).
    Well yes, 3 would be the theoretical minimum... but there may be a practical value that is 'good' enough? Perhaps 5-10 times or so? To cover any 'nonlinearity'?
    I'm just wondering if there's a 'happy medium' where you'd get less CPU-hogging while still getting enough accuracy.

  3. #123
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    4,563
    Blog Entries
    1

    Default

    There's a tradeoff between firing an interrupt 3 times to take measurements, and just grabbing all of the values until you have them all. Interrupt overhead should be considered.

    MagiDuck doesn't need these tricks since it is locked to 24fps IIRC. But if it were 60, maybe one possible tradeoff is reading the stick at 30Hz instead of 60Hz. Not acceptable for fighting games, but this is an 8088 we're talking about.
    Offering a bounty for:
    - Documentation and original distribution disks for: Panasonic Sr. Partner, Corona PPC-400, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)
    - Any very old/ugly IBM joystick (such as the Franklin JS-123)

  4. #124
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,670

    Default

    Quote Originally Posted by Trixter View Post
    There's a tradeoff between firing an interrupt 3 times to take measurements, and just grabbing all of the values until you have them all. Interrupt overhead should be considered.
    True, but let's say the overhead of an interrupt is about half a scanline. Total joystick polling thing in interrupt, let's say 2 scanlines, roughly (basically you'd just have to record the register value at each interrupt, store them in a table, and evaluate them at the end? So you won't need a lot of logic).
    Your routines needed 24 to 26 scanlines, if I read the screenshot correctly. That would mean you could fire off 12 to 13 interrupts before you break even.

    Quote Originally Posted by Trixter View Post
    MagiDuck doesn't need these tricks
    Not saying it does, I'm just wondering what the fastest/most elegant joystick routine would be, in general.

  5. #125

    Default

    Quote Originally Posted by Trixter View Post
    Later joystick interfaces also have a switch on them for different "speeds" (I'm not sure what the switch does).
    On cheap ones, it swapped out a resistor in parallel. Adding the extra voltage on that resistor sped up the charging speed so the faster computer didn't spend as long reading the stick. Decreased the accuracy of range, but sped up programs calling it. The BETTER ones had two pots in parallel on each axis -- some the switch turned that extra pot on or off, some it switched which pot was used.

    Some later sticks have the lower resistance pots with no switch, and won't work worth a damn on anything less than a 386. Both Thrustmaster and CH Products made a number of these during the "death throws" of the 15 pin stick interface before everyone moved to USB. I have a Wico (the giant bat-handle one) that return ~3..72ish on a 40mhz 386 that I can't even get a meaningful read out of on a 8mhz AT. A real laugh since it has a Y splice cable to also be used as a controller on an Atari 5200.

    On early sticks even from the same maker -- SOMETIMES even in the same sticks you'll find pots of wildly varying resistance ranging from 2.5k up to 15k. Given the usually used whatever was cheapest that week because "joysticks are toys" they'd use units with a binning of as much as 20% variance, so even on (actually more so on) the IBM PC Jr sticks, one axis could be as much as 2k of difference from the other one.

    The design themselves don't exactly contribute to accuracy or consistency either. The potentiometers they use are typically designed for a throw of 270 degrees, but what's the widest throw you've ever seen on joystick? 90 degrees would be overly optimistic, so only a third of the part and it's possible range is even being used. The "trimmer" adjustments on most sticks just changes what part of that 270 degree total the stick's 90 degrees (best case) throw falls into.

    Laughably some other joysticks use an extra two pots inline with the ones in the stick so their "trimmers" just add/remove resistance instead of adjusting the throw.

    Running your test there has to be something REALLY different between my junior and yours. I'm getting ~25% higher center stick readings and 50% higher execution times... While the stick itself can wildly change the values, there shouldn't be that much difference.

    Though your numbers being lower is easier to understand once I really looked at the code... You're only reading two axis (though you call it joystick1axis which is really confusing) instead of all four, and as such can do a shift, adc, add instead of ror, adc, ror, adc, ror, adc, ror, adc...

    Uhm, silly question though -- who's Jordan Knight?

    Also, could you put up the code for that ztimer implementation? I'm assuming that's a flavor of abrash's zen timer -- I'd be interested to see why it "seems" to be working since I've NEVER had it be useful on anything less than a 386 either. (jitter of as much as a twentieth of a second)

    Quote Originally Posted by Scali View Post
    Not saying it does, I'm just wondering what the fastest/most elegant joystick routine would be, in general.
    Given what a cheap-ass lazy KLUDGE the PC joystick interface is (even compared to things like the Coco), I'm not sure that anything you do with it could be called "elegant".

    Though it all comes down to these companies refusing to invest in making ADC's affordable. The +5 to resistor charging a cap approach being the cheapest and laziest, tandy's 6-bit DAC output compared to the reference voltage across the POTs being a marked improvement but still not all that impressive. Well, at least with six bits starting from the top the maximum read time was 6 loops -- "divide and conquer" b-tree style.

    The big problem with using a fixed timer is that it STILL could take a massive range of timer increments, or less than your timer granularity just due to the differences in joystick interface, (what's the cap rating and the charge switchover?), differences in sticks themselves (outlined above), etc, etc...

    On the same 8mhz AT class system across the five different 15 pin sticks I have available here, using my 4 axis read method I get a bottom-right (highest read, lowest resistance) ranging from 42 to 380. There's that much variance JUST in the sticks themselves.

    That said, IF you took the center value reading and figured out how long it took to RUN, then set up interrupts to take 3/5ths that time period, you could probably get a semi-meaningful interrupt driven routine to use it to convert to digital input. Basically testing for 40% over/under with a 20% dead zone.

    ... and you would want a dead zone given how much jitter sticks can have. Good ones will have a jitter on a 386 reading ~300+ of 2... crappy ones can have on a PCJr reading 1..15 a jitter of 3. (or more if you leave the NMI running and keyboard handling kicks in during a stick read)

    But really that's the biggest problem -- the wildly varying values the interface has across different hardware. It's enough for a LOT of game developers to flip the double-bird at the PC joystick interface and go try connecting digital sticks to the parallel port.

    Which BTW, I'm playing with adding support to Paku 2.0 for some of the more common parallel port digital stick interfaces like LinuxDB9c, Linux0802, DirectPad Pro, LPPI, theMaze, etc, etc. Might not make it for this release -- assuming I ever get the blasted thing finished.

    Also playing with making my own interface using a cheap arduino knockoff sitting between the parallel port and the sticks. Use the data bit ports to set which "stick" to read allowing for up to 255 "sticks" of 7 "buttons" each. When the value changes fire the LPT IRQ, to have it map the value into the keyboard or be callable by a software interrupt. That way you don't have to constantly poll it and you won't miss inputs. Could even add buffering to it.

    Of course since nano/newer can act as a usb client device, it could also double-duty as a USB interface.
    Last edited by deathshadow; September 7th, 2015 at 03:16 AM.
    From time to time the accessibility of a website must be refreshed with the blood of owners and designers. It is its natural manure.
    CUTCODEDOWN.COM

  6. #126
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,670

    Default

    Quote Originally Posted by deathshadow View Post
    Uhm, silly question though -- who's Jordan Knight?
    One of the guys from New Kids On The Block

    Quote Originally Posted by deathshadow View Post
    But really that's the biggest problem -- the wildly varying values the interface has across different hardware. It's enough for a LOT of game developers to flip the double-bird at the PC joystick interface and go try connecting digital sticks to the parallel port.
    Actually, I always used digital joysticks in the early days. Most games I played would only use digital input anyway (eg Prince of Persia, Test Drive, Keen), or at least were playable enough with just digital joysticks.
    I grew up on Atari's and Commodore's, so I had a nice collection of trusty digital sticks.
    I bought a digital-to-analog converter from Suzo, so I could connect my Suzo Arcade sticks to PC: http://www.dykodesigns.hostfree.nl/s...c_game_adapter

    The only reasonable analog joystick I've ever used was the Gravis Analog Pro. Sadly it was engineered poorly, so the cables going through the stick didn't have enough freedom. They would often break at the bottom of the stick, because of the extreme angle. I've had to fix them up a few times.

  7. #127
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    4,563
    Blog Entries
    1

    Default

    Quote Originally Posted by deathshadow View Post
    Also, could you put up the code for that ztimer implementation? I'm assuming that's a flavor of abrash's zen timer -- I'd be interested to see why it "seems" to be working since I've NEVER had it be useful on anything less than a 386 either. (jitter of as much as a twentieth of a second)
    Link at the bottom of this article. It converts timer counter values to milliseconds, but there is no loss of resolution in doing so (it multiplies by 10000 then divides by 8381). If jitter is an issue on your system, use the PZ routines instead of the LZ routines, as the LZ routines measure long values but must leave interrupts enabled to do so.

    I'm not sure that anything you do with it could be called "elegant".
    For analog values, I think the most elegant routine that works on every speed system is one that reads timer values. The granularity will be finer on faster systems, but the value range will be the same for a given stick/interface no matter the speed of the system (ie. pop the turbo button on and off while the code is running and you'll still get the same values).

    For digital values, a theoretical "perfect" elegant routine that measures three times a stick cycle is possible, calibrated by asking the user to hold the stick at the upper-left, middle, and lower-right positions and using those values to determine when the measuring interrupt should fire. This feels very much like over-engineering, however. It also complicates using IRQ0/INT8 for other things.
    Offering a bounty for:
    - Documentation and original distribution disks for: Panasonic Sr. Partner, Corona PPC-400, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)
    - Any very old/ugly IBM joystick (such as the Franklin JS-123)

  8. #128
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,670

    Default

    Quote Originally Posted by Trixter View Post
    For digital values, a theoretical "perfect" elegant routine that measures three times a stick cycle is possible, calibrated by asking the user to hold the stick at the upper-left, middle, and lower-right positions and using those values to determine when the measuring interrupt should fire. This feels very much like over-engineering, however. It also complicates using IRQ0/INT8 for other things.
    Well, I wonder if you can exploit the fact that the counter value is latched. That is, if you write a new counter value without resetting the timer, it will finish its countdown first, and will use the new value afterwards.
    This means that you can construct your timers like this:
    Your total screen is 19912 ticks at 60 Hz.
    If you were to do any kind of 'subdivision', say with 4 different intervals, you could do it like this:
    interval1+interval2+interval3+interval4+X = 19912
    You know interval1/2/3/4 (which would follow from your calibration), so you can calc X.
    You can then construct a simple table of counter values, and loop through them.
    When the interrupt for interval1 fires, your counter is already counting down interval2, so, you initialize it to the value for interval3.
    At the next interrupt, you're in interval2, and it is already counting down interval3, you set up interval4, etc.
    This way you should always have your counters add up to 19912 at the last interval, so you're always doing a full frame with no drift.

    I don't think it's that hard to do, and you can still take care of most of your int8-based timing needs (just a simple switch-statement to select which variation of the handler you need to run at each interrupt).

  9. #129

    Default

    Quote Originally Posted by Trixter View Post
    Link at the bottom of [URL="http://trixter.oldskool.org/2013/01/18/optimizing-for-the-8088-and-8086-cpu-part-3-a-case-study-in-speed/"]For analog values, I think the most elegant routine that works on every speed system is one that reads timer values. The granularity will be finer on faster systems, but the value range will be the same for a given stick/interface no matter the speed of the system (ie. pop the turbo button on and off while the code is running and you'll still get the same values).
    I would disagree, BECAUSE there is no "stick/interface" consistency. Defeats the entire point of "flattening it out" with the timer when the same interface on the same timer routines you get as much as 1000% difference in ranges just by plugging in a different joystick -- or even as much as 40% difference between two seemingly identical sticks, or 20% across axis IN THE SAME STICK.

    The differences in caps, varistor and general hardware changes means that there is zero consistency in timing, so tying it to the system timer seems pretty pointless other than the possibility of letting other code run while the stick read is being handled.... which in my experience on the low end would take so high a interrupt frequency as to make it bloated -- which is why if I did go that route I'd set the timer frequency based on 1/5th of how long it takes to read bottom-right.

    I also would NOT use upper-left and lower-right as the triggers for digital as that actually can kind-of suck to have to use the full throw; that's why I'd use something like 2/5ths the center read as a dead zone, and anything outside the dead zone counts as a movement. Assuming the trim was set right in the first place, all you'd need then is to read center position. You want to make sure center is center, either make a calibration routine or use a third party one. I still love jtuner.exe that came with EA's LHX.

    Side note, that link you provided seems to send every browser other than firefox off to never-never land here -- I suspect it's that "follow" scripttardery as I can only access that page in other browsers with scripting disabled. NOT that said page scores well on accessibility marks, but it's turdpress so that's pretty much a given...
    From time to time the accessibility of a website must be refreshed with the blood of owners and designers. It is its natural manure.
    CUTCODEDOWN.COM

  10. #130
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    4,563
    Blog Entries
    1

    Default

    Quote Originally Posted by deathshadow View Post
    I would disagree, BECAUSE there is no "stick/interface" consistency. Defeats the entire point of "flattening it out" with the timer when the same interface on the same timer routines you get as much as 1000% difference in ranges just by plugging in a different joystick -- or even as much as 40% difference between two seemingly identical sticks, or 20% across axis IN THE SAME STICK.
    You misunderstood me. What I was saying was that a read-the-timer approach will return the same range of values for the same stick+interface no matter which computer they are installed into, assuming the interface is not affected by system speed. Tight loop/counter routines have higher granularity and less jitter, but their values are sensitive to how many loop iterations can be performed before the stick values return.

    I also would NOT use upper-left and lower-right as the triggers for digital as that actually can kind-of suck to have to use the full throw; that's why I'd use something like 2/5ths the center read as a dead zone, and anything outside the dead zone counts as a movement.
    I concur.

    Side note, that link you provided seems to send every browser other than firefox off to never-never land here
    I just tested both the link and the actual file download at that link with Chrome and IE 11 and it works fine. File is an FTP link; maybe you have a custom ftp:// handler in your other browsers? That tripped up someone else who had a file download extension installed.
    Offering a bounty for:
    - Documentation and original distribution disks for: Panasonic Sr. Partner, Corona PPC-400, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)
    - Any very old/ugly IBM joystick (such as the Franklin JS-123)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •