call ** == $CD
Just put that hex in the program followed by the hex equate of the subroutine so:
[shameless plug] http://future_history.freehostia.com/Files/Resources/program%20readmes/Axe/Commands.htm#Sym [/shameless plug]

Code: [Select]

...code...
Asm(CD####)
...code...I believe this works.

Thank you, Eeems. I'll remember that, and I'll be forever greatful.

One thing I also read in the whitepaper is since CALCnet2.2 uses interrupts, it does not like GetCSC as a scan code, instead providing its own subroutine for getting keys. However, the keys are debounced, which is probably not what I want. What method does Axe use for the direct Getkey method (getkey(XX))? If it uses GetCSC, how would I read the input directly?

Oh - and I also read the Axe documentation and noticed that the direct getkey command had been changed so that it could use a variable and not just a constant. If, of course, this doesn't mean it's using GetCSC, I could let players remap the keys to whatever they want. How does that sound?

One thing to remember is that the variable key detection will make the game a bit slower (and larger)

Scanning the keys yourself is actually much faster than GetCSC.  But obviously scanning all the keys is always going to be slower than scanning a single key.

:Lbl KEY
:For(A,1,56)
:ReturnIf getkey(A)
:End
:Return 0
Calling this subroutine will give A the value of the current key being pressed or 0 if nothing is pressed.

Oh, and the actual slowdown for variable key detection is so small compared to Dispgraph or sprite drawing that I would consider it negligible.  It isn't much bigger either since it only needs to add the subroutine to the program once.

Scanning the keys yourself is actually much faster than GetCSC.  But obviously scanning all the keys is always going to be slower than scanning a single key.

Code: [Select]

:Lbl KEY
:For(A,1,56)
:ReturnIf getkey(A)
:End
:Return 0
Calling this subroutine will give A the value of the current key being pressed or 0 if nothing is pressed.

Oh, and the actual slowdown for variable key detection is so small compared to Dispgraph or sprite drawing that I would consider it negligible.  It isn't much bigger either since it only needs to add the subroutine to the program once.

This is actually useful stuff, Quigibo. But the reason I was asking about this is because I use the getKey(XX) method to get the key input for the player (download the game and look). I wanted to know if I could still do that, and apparently I can. You (somewhat indirectly) answered my question. This is cool code, anyway. Thanks, Quigibo!

EDIT: Yes, and I do plan to use custom keys for the game, eventually. I know that people have different opinions about what keys should drop and what keys should rotate (I've seen several games where UP drops, and some games where UP rotates). I personally prefer UP as my drop key, but I know that other people think differently, so I'll allow players to redefine their keys.

Hey guys! I have a new version of Eitrix: 0.3.1!

The big new thing is Attacks: effects that mess up your block configurations. Every frame, there is a 1 in 256 chance that you will recieve an Attack on your screen.

However, the real reason that I wanted to post now is that I wanted to get some optimizations before I added CALCnet2.2. These are the things that need fixed:
- The game becomes incredibly slow when more blocks are added to the grid
- The title screen does not like to show up when compiled with Axe 0.4.7
- The game freezes when run with Doors CS 7.1

Please look at this code and tell me what you find!

EDIT: I just made a change to the game code that made the game a whole heck-of-a-lot faster. It uses an appvar to keep a rendered copy of the grid, and the grid is only rerendered when it is changed. This makes the game that much faster (except when specials are active). I'll post this update soon, after I fix the key timers to be more sane.

Yes, it was. However, since I want to migrate all of the player grid information to L3 to make way for CALCnet2.2, I couldn't use that as my rendered image. Thus, Eitrix steals 768 bytes of usermem, in the form of an appvar named EITWORK. However, Eitrix goes a lot faster, except when specials are underway.

Additionally, I'm in the middle of configuring the game so that an automatic interrupt triggers keypress timing, rather than the frame count, as I had originally been doing. It's almost done, so I'm going to try to post tomorrow morning.

FINALLY! EITRIX VERSION 0.4 IS AVAILABLE!

These are the new features:

• Attack Items: Two special attacks that will randomly hit you
• A whole lot faster!
  
  • Goes off of interrupts, so that the speed will remain constant AND can be controlled by MirageOS keyhooks
  • Creates an 800 byte Appvar called EITWORK
• Added a MirageOS icon

Please play and tell me what you think! Also, I did find a few bugs in the code, so if anyone would like to check them out and fix them, please do.

I am very sad to announce that I am now abandoning CALCnet2.2 integration. I just cannot get a robust engine to work, so I am going to abandon it until somebody else writes a robust solution. I am not abandoning the entire project, however. As of now, I am coding more special attacks, and am going to work out a head-to-head mode with Axe's built in linking commands. I'm still not giving up on Eitrix, but it will not be the massively multiplayer game that it was originally planned to be.