I have the key to One Eyed Willy

Wasp · Post by **Wasp** » Thu Mar 24, 2016 4:20 pm

I was able to get a commit between R4 and R5 to build and run (after some artwork workarounds). Unfortunately, I didn't pay attention to which commit I was building so I'm going back as far as possible. This will get me to the commit that brought the problem and I'll leave it to you guru's to fix it.

Thanks again for your attention...this has "bugged" us js users for years.

Terran · Post by **Terran** » Thu Mar 24, 2016 5:24 pm

use a mouse

Wasp · Post by **Wasp** » Thu Mar 24, 2016 6:45 pm

You're the only reason I'm still chasing this bug.

Wasp · Post by **Wasp** » Fri Mar 25, 2016 2:05 pm

KGJV wrote:QUOTE (KGJV @ Mar 24 2016, 11:32 AM) ok so as of today, we don't have yet the source of latest version (in term of commit number) that doesn't have the problem. This is what you're trying to find.

I can't help much on this front because I only have VS 2012 and VS 2015 so I can't build older commits between R4 & R5. I'll try anyway if I can find some time.

Meanwhile, I dug some old notes and compiled a short document highlighting important parts of Alleg code: the main loop(s) and where the js values are read from the hardware and where they're used.
it's here: https://docs.google.com/document/d/1jYc ... sp=sharing

short explanation: At each loop , the engine gets the input values (js, mouse, kb, etc ) from the hardware with UpdateInput(). The game udpates its logic with UpdateFrame. The values are passed from one to another using a 'stream' (JoystickInputStreamImpl for instance).

I can explain it more if it's not clear. By examining code changes (commits) between R4 & R5 around these parts of the code , we might find something relevant to the issue. But it's better first to find the latest commit without the issue.

Thanks again,

Seriously, I don't think it has anything to do with the JS. It is just that by using a JS, you can see that the x and y axis behavior is out of whack. It is as though the precision in the stick was removed.

Anyhoo, I'm unable to replicate my bastard build I did the other night. I think I have my include / lib screwed up. Can you tell me what SDK would be used back at commits 190ish and in what order I should list them in VS?

Thanks

KGJV · Post by **KGJV** » Fri Mar 25, 2016 4:04 pm

Wasp wrote:QUOTE (Wasp @ Mar 25 2016, 03:05 PM) Can you tell me what SDK would be used back at commits 190ish and in what order I should list them in VS?

I don't quite remember much of these...

IIRC I've never installed any external SDK except ofc for DirectX. Usually the Windows SDK installed along side VS is enough.

Some years ago, we had a dispute with ppk about atlmfc that I wanted to include in the source or host on the alleg site but he was afraid of © issues with MS... you can find details and info (and drama) in this topic. Since the link to my altmfc was censored, you can get it here : https://mega.nz/#!jMIxBAaC!O3foaok7 ... imKP49S-wI (just click download with your browser),quickly, it might not last...

Wasp wrote:QUOTE (Wasp @ Mar 25 2016, 03:05 PM) Seriously, I don't think it has anything to do with the JS. It is just that by using a JS, you can see that the x and y axis behavior is out of whack. It is as though the precision in the stick was removed.

yeah but examining/following the js code might also help us find the bug/issue.

Wasp · Post by **Wasp** » Sat Mar 26, 2016 1:56 am

snagged the download. Thanks.

I found out that my bastard build was with the R5 distributed version that I downloaded long ago when I grabbed everything in tag. I'm able to build that R5 so I'm going to start from the point of R5 distribution and work backwards toward R4 until I can spot the offending code. I fear I may have to put together a win32 machine if I need to go back to the first commits of R5.

Thanks again for all the help. Glad to see that you guys are still around after all of these years.

Wasp · Post by **Wasp** » Wed Mar 30, 2016 5:20 pm

At last, I am able to build commit 189. Only took a week too!

Now by invoking the tried and true method of "Higher / Lower" as demonstrated on The Price Is Right (US game show), I should be able to zero in quickly on the culprit.

Wasp · Post by **Wasp** » Fri Apr 08, 2016 3:31 pm

BackTrack, Kage, could this be it?... Commit 316

Can't tell you what a chore it was to create all these builds,...but as I kept narrowing in on it, I finally found some builds (316-323) that would crash as soon as I moved the mouse on the main screen after launch. IF I moved the mouse very very slowly, it would not crash. When moving the mouse over a windowed game screen, it felt as if the game was fighting windows for mouse control and then the game would crash (freeze) and windows maintained mouse control (won the battle?). So, moving the mouse slowly after launch, I was able to hit the training button and then I could move the mouse at full speed... however, it felt wonky and laggy, as did the joystick when playing. Build 315 does NOT exhibit this crashing from mouse movement or wonky(lag) joystick behavior.

I think I was able to build commit 330 and play without the crashing however, that too seemed to exhibit the same wonky behavior. To me, and this is just a pre-verification observation (disclaimer)

, Build 315 was the last one that behaves correctly.

KGJV · Post by **KGJV** » Fri Apr 08, 2016 5:59 pm

That's odd, the changes in commit 316 are small and can't really explain the behavoir differences...unless there is a nasty side effect somewhere.

Wasp · Post by **Wasp** » Fri Apr 08, 2016 6:08 pm

yeah!..

why would this affect a mouse?...or rather, why would the faster mouse movement on the main screen cause it to lock up yet, when in the training main screen, fast mouse movement didn't lock things up?

UPDATE: It appears that moving the mouse over the spinning 3d image in the main menu, is crashing the client. Gimme some time, I'll get this sorted with more info...