Woo, a real worm! Anyway, make sure that you run the nostub programs correctly (get rid of the worm portion from the executing copy before executing so all addresses are correct) I might duplicate this at some point... Sounds like a fun coding exercise.
Yeah I had no trouble there. I did have some trouble remembering that I can't run overwritten code, tho
Yeah it was interesting. Started out trying to make it attach to the end... that was a nightmare Btw, If you like, the attached appvar above is the source. (from Mimas. I can't get it to convert properly to .asm)
that's fun. I'll have to infect someone's calc with that. after a while, does it not let you even run the worm program?
After a while of not giving the program new no-stub programs to infect, it will not run the 'host' program if it still fails to infect a new program.
Actually all of my testing is done with a (slightly modified ) copy of prgmSTARSHIP (the one included with Axe) and it runs perfectly!
(no idea why wabbit doesn't like this... all I use is B_CALLs Enough_Mem and Insert_Mem, as well as Asm_data_ptr1 and manual scanning of the VAT...)
As for uninstalling: backup your programs before installing. All changes are made directly to the source programs. (you may notice the program size jumps by about 300 bytes) The only thing it checks for is a prefix of
ld a,a/or a
, which tells it to keep looking. So, uninstalling could cause some problems...
Finally, you can own your own little virtual pet on your calculator! (itsa worm!) Not only can you feed it, but if you don't feed it, it'll die! (and rise from the grave to haunt your children and their children!)
Asm(prgmWORMY) has a little (< .5 screen) tutorial on how to care for your new pet.
Okay I'll admit I was bored
Spoiler For didja kno that worms are bugs?:
1: Its a little bug that attaches itself to the first unarchived nostub asm program it finds 2: Then the next, and so on. (1 each time you run an 'infected' program) 3: When it runs out of programs to 'eat', it starts complaining about you not 'feeding' it. (but it'll still let you run the program) 4: After a while of this, it will no longer let you run nostub asm programs until you 'feed' it.
I always feel most of my time debugging Axe/Basic code is spent scrolling all the way to the bottom of the program. (especially when dealing with errors in graphing vars)
How about something that searches for a label or certain short token-string and immediately jumps to it in the program editor? (none of that scrolling like a basic error gives, takes too long in some programs )
(maybe this could go in with a variable scanner? or maybe as a key hook only functional in the program editor? remembering the position in the program would be nice if possible, although then you'd need a way to jump to the very beginning )
I've already tried this and haven't the slightest idea how to do it, but I know Axe used to do immediate non-scrolling jumps into the program editor, so...
More blocks are good, especially for people like Yunhua98
By the way, when a program is in Pause mode or Input mode (like Wacky Fun Random Numbar Generator ), it seems that removing a battery causes a RAM clear too. That might be a bit hard to block, though, other than blocking the entire prgm menu and prgm command. Same thing goes for long strings of Sin/rand commands or the SortA/D( commands if someone sorts a 999 elements list.
Its been a while, and I had completely given up on this until I started looking at writing a hobby OS. I was reading a certain thread on Cemetech when I ran into a link to an IRC log which detailed precisely the solution to this problem. Thanks Brandon W, and yay it works!
Simply put, running 'seq(select(rand(999),1),A,1,999)' and pulling a battery simply aborts the process and doesn't clear ram! (I've checked, no memory leak either )
Actually thats only enabled when security is active. Can be moved easily enough, Its just always a pain to dump...
Speaking of which, you can now change which key activates it! I even included a special case for kOff!
It used to be required for a blocked key to return 0. No longer! Again, a special case was included for kOff. (kAreYouSure = awesomess )
Also, kMode is now blocked by default.
I figured out the cause of a couple menus unblocking the normal powerdown, still searching for a solution*. Its because certain (or maybe all) menus dont re-call my app change hook when you reload (like pressing 2nd-Format in the Format Menu) them, yet still mess up flags. However, all of these menus are on the lighter-colored buttons at the top.
A slightly improved editor is in the works. Its quite buggy at the moment, which, among other things, will delay an update to tomorrow at the earliest.
yeah, thats actually one of the reasons I haven't really done much for the framerate yet I find it really easy to move around and whatnot, any faster would be maybe a little too fast?
an arena version will fit easy. an engine for world map movement/storyline stuff/etc would even fit probably. Its just when I start to put in several 300 or so byte maps and dialogues that I might start to have problems
Spoiler For a long way to say 'yeah, that's a great idea, but mostly because I have what I have already working, I'm gonna stick to improving what I have.' :P :
ridiculous amount of different tiles? no thats not really a problem... but in some cases, height factors into damage, you can only jump so high, falling damage, etc. So that is 5 bytes per 16*16 area? (4 for tiles, one or two for height cause the tiles are arranged weird) An uncompressed map in the current system is 4 bytes per tile. compressed, its about half that, depending on the map. so its more of a memory problem than a speed problem, I think.
Also, what about when people/the cursor goes behind something? That's the main problem I'm having with animation... how exactly would you test for it?
I just ran a test, and looping through an array of 120 compressed tiles 100 times (without writing anything to buffers) takes a fraction less than a second. I'm satisfied with that, as I only hope to do that around 5 times a frame, and 10fps is pretty good... i think (thats twice phisical attacking, once moving, one to shift the screen, and once drawing the screen normally, but twice if you try to push the cursor off the edge of the map )
so yeah, the slow framerate is caused more by the totally unoptimized sloppy and excessive routines I use to write to the buffers. After all, pt-mask writes to BOTH buffers (only using one), has to check if it needs to shift the sprite, has to load all the arguments, and repeat 3 more times. Plus, I'm using Rect( for the sides, which could easily be simply loading $8181 in a column...
I'm starting to hope that by the time I start the full version (assuming I do), Axe will support two-page apps
So yeah, its looking like I'm gonna have to start compiling to an app soon. Stat growth is pushing it over the top
Also, 10fps does seem like a possible goal, with a finished axiom
hmmm... 15 days... makes me wonder how that 'necropost game' thread is coming along
I put in a proper damage formula and the rest of the stats, moved around the code to delete dead people, and ran out of space So I ran through the program making minor optimizations, finished compressing the map data (yeah, i stopped halfway through, and there's still no notable speed difference), and cut a good 300-400 bytes
I've started work on a simple isometric masked 16*16 sprite drawer (completely untested), and I think I have everything up to the actual sprite.
I tried it too and it's kinda nice. However I would make arrow movement rotated by about 45° so up moves up, up+left moves up+left, instead. Else it can be a bit confusing. Also I noticed the speed: would it be easy to simply draw a part of the tilemap when scrolling?
yeah... I don't really like the cursor system that much either... but I'm used to the diagonal shift. I might (once I make an options menu) make that changeable.
and no, not really. If I made an axiom to draw the tiles, that would be sooo much faster... crazy fast. The 'Rect('s and 'Pt-Mask('s are what slows this down so much. But I don't really understand how axioms work, the equates aren't built into Mimas, and I don't have a utility to convert programs to appvars, etc.
I would like to say that I have officially done absolutely nothing on this project since my previous post.
well it blocks PRGM and APPS, so hopefully the user is going to use 'Clear Entries' to prevent that from happening. but yeah, you can unblock those (or unprotect your calc), and pulling a battery in a program will clear the hook.
Of course it's reversible, but how long does it take to switch between the two?
Mine can be done instantaneously, and on-calc... but it is less secure. Plus, if you forget your password, you gotta wait till you have a screwdriver or link cable available to uninstall... I just realized another security flaw. resending the OS, or just sending a blank app with the same name... (how am I supposed to block those )
EDIT: really? graphing? who would'a guessed... lets block that key too
just a little password-protection key hook. You hit install, type the password (it records the keys, not like a number or letter or anything ) and push ON. Hit 'Edit Block' and scroll left twice, and as you scroll, you should see a copy of your password. If you hit ')', it'll jump to the keys it blocks. Both sections are editable, just be sure to update the length bytes. If your password is incorrect (I often get a random kEnter or kClear) exit the app, re-enter it, and re-install. Once it's installed, it is not active. Push [2nd][TBLSET] to activate it, and type your password to disable.
Wow that was a long explanation
But it is impervious to anything less than pulling all five batteries*. (do those people carry a screwdriver around with them?)
* ok there are a couple other ways around it, see linked post for details
Well guys, seems I'm the type of person to just let projects almost die then start back up again
Here's that long awaited update...
PS: for security's sake, you may want to add blocks to Mode (because of Mode, Alpha + S), as well as TBLSET, WINDOW, and FORMAT (because they, for a single keypress, enable the normal powerdown, enabling PTT, which deletes the hook). Of course, if you think you might forget your password, don't block one of those three.
If you do forget your password, sorry, all you can do is (unless you have a program in your history which uses a raw key hook) pull all five batteries.
PPS: if you are confused as to what the values mean in the 'Block Editor', they are copied straight out of the key equates section of ti83plus.inc for your convenience.
EDIT: it has come to my attention that pulling a battery during graphing forces a mem clear. you may want to block GRAPH.
As the name suggests, this is a clone of Tactics. Isometric mapping and everything. Only things that will eventually be missing from this version will be: multiple equips, ability to switch between them multiple maps, a plot of any kind whatsoever classes, skill sets possibly enemy AI, but I'll try to include some...
Currently includes a copy of the first FFTA2 map for (at least) testing purposes. Only one enemy/player sprite so far (but as many players/enemies as you can fit in L1), but the turn system is working well(ish) so far. Got a nice HUD, and so far does not include a single Pause, but runs at a rate good enough for an rpg. Units have stats, although only move, jump, speed, hp, and mp so far. (it'll eventually include the typical full set)
Spoiler For something you really shouldn't read. I'll feel less obligated to make it if you don't:
Anybody else notice that the Tactics games (at least FFTA2) lack something? This won't lack it. (Hint: It really really really honestly is not not multiplayer) (thats a double negative)
I realize I am horrible at spriting anything except geometric shapes. Anybody wanna make some 16x16 isometric character/enemy sprites? (if you have trouble with this, I may be able to make them taller...)
Show Posts
Anyway, make sure that you run the nostub programs correctly (get rid of the worm portion from the executing copy before executing so all addresses are correct)
)
)