How to check if Xfire is NOT pressed

[Brick Nash]

Sorry, I'm having a little moment here which I can't seem to solve.

I'm using the Amcaf extension's "Xfire" function to be able to use two buttons in my game. It works fine, but I need to check when one of the buttons is NOT pressed (ie, released) and I can't for the life of me figure it out.

With the regular Fire(1) instruction I just do "If Fire(1)<>-1" or "If Fire(1)=0" and that's fine, but I just realised that with Xfire it seems to just check for when it's on.

There's no "=" or way to manually check the state of the bit. The instruction is just "If Xfire(1,1)". I've tried "If Xfire(1,1)<>-1", but it does nothing.

The section for Xfire in the Amcaf manual is literally just four lines of explanation and no examples of how to use it in certain contexts, so maybe I'm using it wrong, but either way I'm kind of lost.

Thanks.

[Exodous]

Try:

If Not(Xfire(1,1))

[Brick Nash]

Bingo! Thank you.

That's very useful, I must have missed it in the manual. I've been wondering if there was an equivalent of GML's "!" in AMOS Basic, so I guess that's it.

[Dan]

hmm, this works too, i have just tested it with amos for windows (which has the amcaf extension installed)

Do 
   If Xfire(1,1)=-1
      TXT$="ok"
   Else 
      TXT$="nop"
   End If 

   If Xfire(1,0)=0
      TXT1$="nop"
   Else 
      TXT1$="ok"
   End If 

Print TXT$+" / "+TXT1$
Loop

[Brick Nash]

Originally Posted by Dan

hmm, this works too, i have just tested it with amos for windows (which has the amcaf extension installed)

Do 
   If Xfire(1,1)=-1
      TXT$="ok"
   Else 
      TXT$="nop"
   End If 

   If Xfire(1,0)=0
      TXT1$="nop"
   Else 
      TXT1$="ok"
   End If 

Print TXT$+" / "+TXT1$
Loop

That's odd? It didn't work for me at all. Especially weird since I'm using Amos for Windows as well.

I think my version may be ropy though as there is a few glitches with it, such as procedures visually corrupting when include files are active, and I can't switch to Cycle Exact without the CPU nosediving to about 2-4%. That's just loading AMOS up, and it stays that way.

The last one is a concern as I can't test my game at a "real" Amiga speed so I've no idea how efficient my code actually is.

[Dan]

Yes, Amos for Windows is crawling when set to Standard/cycle exact. But it maybe up to the 68040 being selected and aga and etc.

There is a way to make Amos for Windows run-able on kickstart 1.3, by copying some files from the workbench to the A4W folder, but the "Intuition.lib" is crashing the Amos (at least here), so it needs to be removed from the configuration (while amos pro is running) .

[Brick Nash]

Originally Posted by Dan

Yes, Amos for Windows is crawling when set to Standard/cycle exact. But it maybe up to the 68040 being selected and aga and etc.

There is a way to make Amos for Windows run-able on kickstart 1.3, by copying some files from the workbench to the A4W folder, but the "Intuition.lib" is crashing the Amos (at least here), so it needs to be removed from the configuration (while amos pro is running) .

Good to know, thanks. I'll give that a try, but I think I'll be going back to my old setup soon where I was running AMOS from my actual WinUAE HDD setup.

I do like AMOS For Windows a lot for its convenience, and the fact that it has everything pre-installed (extensions/compiler etc.) but it seems a bit flaky in some areas. I shouldn't be be so negative though as I know the developer has passed on, and it has been a great tool so far.