Oh, then I misunderstood your question. Just download the zips, extract them and send the appvars to your calc. In your source, use the #Axiom( command with the name of the axiom in the parenthesis to make the libary usable. You can have up to 5 of them at the same time, each can provide up to 32 commands.
Yeah, I know the method, but I don't see how to apply it maybe I'll do it, but much later, since there are many widgets simpler to code (and mostly I still haven't done the mouse() command )
Ok, sure If I knew how to make axioms I'd give it a try myself.
How, that's way too difficult I really don't know how to do an input in ASM.
Oh, well... input has been a highly requested feature for a long time and it'll be awesome if someone finally makes that. Here is my basic idea how it could work:
Get/Check for key presses
Use a LUT to determine what the corresponding character is; skip when key not legal
Enough space in the box? (index < width/4?)
Write the character/token to an array, increment the index
Print the character at cursor position, move cursor 4 pixels to the right
Case of "DEL":
Array index != 0?
Move cursor left 4 pixels, decrement index
Print 3 empty spaces at cursor position
Case of "ENTER":
Array index != 0?
Text-mode: Copy the #index bytes from the array to the address given.
Number-mode: subtract '0' from each digit, sum them up while multiplying with 10 (makes a number out of the digits) and write to the address given.
How about a text-box function which lets the user input text or numbers and displays it (if not to difficult) TextBox(addr,X,Y,width,enable/mode) The enable/mode is like an alpha-toggle; 0=doesn't respond to any key presses, 1=number input, 2=letter input Auto-stop when the box is full and - of course - DEL as backspace. Returns a number (when mode was 1) or a pointer to the string (when mode was 2)
I don't think there is a list with all of them, but on Quigibo's axiom request thread there are some axioms listed (not up-to-date). The last one isn't needed anymore though, that feature has been implemented to axe.
Ok, I was skimming the code and found some stuff (idk if it is related to the problem, but I thought of pointing it out) I couldn't find the main mistake though.
:If K=15 :Goto DIE:End :If K=33 :0→L:Else:End :If K=34 :1→L:Else:End :If K=26 :2→L:Else:End :If K=16 :3→L:Else:End You could also use a LUT and the inData( Command.
Z isn't used anywhere else than here, so that can also do weird behaviour:
Display anything related to the stuff that isn't working right as debugging data
Try to split the code in several files, for example one with routines, one with the menu screen etc. That will clean it upü a bit and makes it easier to locate/jump to errors.
Here is a line clipping routine for the bottom of the screen. I bet you can optimize it, that's just some ugly prototype I came up with using the similar triangles formula.
Ok, to clear thinks up a bit, here is how the stuff works:
I have a 168 byte save file, which contains the data of the map (scaled down to 1/4 because of resolution with 2x2 pixels; 156b), the spawn points of the players (4b) and the key setup (8b). How the resizing works can be found here.
The data is extracted to L3, top and bottom lines are added with another Fill( function at the very beginning. The backbuffer is used for collisions. It isn't at all change during the game. The bullets, the players and the power-ups are displayed only on L6, but they check collisions only with the constant stuff on L3. That makes it possible to walk over grenades and pass other players, as well as shooting "through" power-ups. Bullets won't pxl-test whether they hit a player, that's done with a simple subtraction and a comparison to the threshold for both X and Y. Pxl-test is only used on the backbuffer. In every frame, L3 is copied to L6 and all the other stuff "ors" over that on L6. No ClrDraw / DispGraphClrDraw to avoid another bcall().
Btw, you don't need to subtract two extra bytes when you are jumping backwards, you just need to add the size of the instruction when jumping forward. At least not when assembling on a computer. I think if you were writing hex code, you'd be right (for relative jumps, at least), as a hex value of $00 would jump to the next instruction. However, the assembler starts at the start of the instruction (that is, at the first byte of the instruction), so jr $ would cause an infinite loop. Jr $-9 would jump to the instruction nine bytes before (in your case, the address held by the label double).
EDIT: DeepThought: For djnz/jr, would a value like -9 really trip it up? I think you might end up jumping to the wrong place because the calculator calculates relative jumps differently from the assembler. Wouldn't the assembler just load $F7 (even if it gets interpreted as $FFF7, the assembler might truncate it down to $F7) after the djnz/jr byte (i don't know what the hex codes are), essentially jumping to $-7 (2 bytes after double, aka the 2nd byte of the "rr l"?
I'm now using a compiler, so I don't care that much anymore. Afaik you have to write the number of bytes you jump in the source, and in the hex 2 is automatically subtracted (doesn't matter if forward or backward) by the compiler. If you don't have a compiler, you have to subtract 2 by hand.
Example: jr $1 would skip one byte. jr $-5 would jump to byte 3 before "jr". jr $-2 would make it stuck in an endless loop.
If I were you, I'd check out Builderboy's recent contest entry. You might not understand the code, but there's a pathfinder that calculates the significance of nodes based on a dynamically generated tilemap. PM'ing him might be good if you want to go through with this, but it will be fairly challenging
I saw the project a while ago. Never thought of it that way. I might ask him.
The only problem I see of using 8x8 tiles is that it is a shooting game, and it might be difficult to see where the enemy is if you can't see far, which will be the case with 8x8 tiles. What you could do is draw everything in an appvar and use Runer's Pixelmapping to have fast scrolling and pixel based detection.
That's exactly what I need for this, thanks
I wouldn't do the tilemap thing anyways, since then I had to completely rewrite everything. But before I include something like this, I going for the AI first:
Show Posts
I learned with it.
)
Great job! But when I was thinking about the name, iI thought about a totally other game genre ^^