An axiom would actually be cool, if we can customize it and stuff. It would allow for more projects
I don't think that's likely to happen. Nobody is going to want to be limited to the built-in sprites, and I really don't think that axioms are that customizable, but I wasn't around when they were an option, so idk. The most I could give is something that calculates X and Y from X, Y, and Z, a 16x16 Pt-Mask(), and a couple rect()'s. That comes out to (in unoptimized axe, ASM would be soo much easier):
:[00000000]->Str1 .temporary memory space, so we don't have to use named variables (won't work with apps) :r1-r2*8->{Str1} .X on screen :r1+r2-r3*4->{Str1+1} .Y
:.Draw the two bottom lines any which way, I used masked sprites :P
:.Just in case Y is off the top of the screen (can be ignored if that limitation is removed) :If {Str1+1}+16<<0 :0->{Str1+2} :r3*4+{Str1+1}+16->{Str1+3} :Else :{Str1+1}+16->{Str1+2} :r3*4->{Str1+3} :End
:.Connector lines :Rect({Str1},{Str1+2},8,{Str1+3}) :Rect({Str1}+8,{Str1+2},8,{Str1+3}) .Because if X is off the left side... :RectI({Str1}+1,{Str1+2},6,{Str1+3}) :RectI({Str1}+9,{Str1+2},6,{Str1+3}) .same
:Pt-Mask_16({Str1},{Str1+1},r4)
Main problem with my current setup is that I have to draw so many rectangles and do so many calculations. The task is trivial in ASM, as, for the connector lines, all you have to do is load $8181 to a column...
On second thought, an axiom would be so useful. However, a X/Y offset argument would be useful, especially for smoother scrolling (just add or subtract from the initial X/Y calculations).
I'm having trouble with compression in my program, tho. It works perfectly fine with uncompressed data, but when I try to compress something, it messes everything up.
Compressed Data: [F00007] //make T=00 for 7 blocks, not including exceptions... lol oxymoron [F1010107] //auto-increment X, and keep Y=01 for 7 [F30103] //make Z=1 for 3 blocks [FF] //ignore me and loop, stupid program [FE00050003] //EXCEPTION! ignore everything else and interpret this as uncompressed [F30204] //make Z=2 for the last four blocks [FF] //:P
That compresses 32 bytes to 20 bytes!!! (most maps would get a much better ratio)
PS: the compression codes were specifically chosen to represent the task they perform, for example, F1 replaces bytes starting at 1, FE is an exception...
Awesomesauce. Really nice work there. The slanted tiles are especially impressive
I actually have to revise every single slanted tile... Gotta take the bottom line off. Sure, the cases where that line would show up are pretty rare, it is still not supposed to be there. Its not visible in the screenie because every sloped tile is no more than one level higher than the tiles around it. But that'll be a pain...
Is this just an engine or everyone to use? Or are you planning to make a game with it first. (Hint^ )
Yes, and yes. I don't mind whatsoever if anybody wants to use this (or just parts), but the sprites are currently being oriented towards a Tactics game I fully intend to make.
Darn that looks so impressive! Great job! I always wanted to see an isometric game. I hope someone makes one for calcs. Would it be possible to not lose speed if you add blocks at the bottom so it won't look like floating blocks, though? Because if yes, then someone could maybe redo Kirby's Dream Course (Kirby Bowl) for calcs.
Well, I do have it displaying the blocks at the bottom at a better speed than before... probably not good enough for like a racing game, but perfect for an rpg, methinks. Of course, I'll still try and make it faster.
Got vertical lines working (came out to 4 Rect(/RectI( commands per tile, virtually bug-free, see screenie for only known bug)
Now what should water look like? Transparent or just a couple waves? Should it look different on the sides?
I had a little trouble with the new tiles. Turns out Pt-Mask( and FlipH( don't like each other. The back layer gets flipped, but the front doesn't. Spits out garbage instead of a pretty tile... So I had to include images for the flipped tiles instead.
Oh my g. That is really looking cool! Um, I am not familiar with axe, but I know how to do it in regular assembly (making vertical lines). But yeah, are you familiar with making tilemap data? Each byte can be a tile. Like, if the byte is 00, draw nothing, if it is 01, draw just the tile, if it is 02, draw a tree, if it is 03, draw a tile and a tree. Pretty much, if the number is odd, draw a tile and a pic, if it is even, draw a pic. I might be able to make some random opcodes...
Yep, I'm familiar with tilemap data... but this is awkward. I need an X, Y, and Z coordinate for each tile, as well as tile type.
Yeah, it does look pretty cool with just floating blocks, but not for what I eventually want it to do. I eventually want it to not draw so many vertical lines... they're a little annoying.
I temporarily removed the part that draws the tile all the way to the bottom, and look at the speed potential! Floating blocks FTW.
Trees officially work, at the cost of an extra byte per tile. Gotta get some compression now.
Anybody know a good way to draw lots of vertical lines quickly and safely? Since the tiles snap to bytes, I could simply calculate the proper bytes and write $8181 to them.
I'm still waiting for somebody to tell me where I pulled that map from
What are all those comments in the beginning of the code?
It looks nice, though.
in prgmISO, thats the code for a random map generator. simply uncomment that, and change 'Str1->M' to 'L1->M' in prgmTIMG, its so I don't forget what the images are.
I figured out why it was returning 'mean(' and 'seq(' for program names: prgm! and prgm# The ascii doesn't tokenize properly.
As for my indexing problem, I am now using a string hash. ('prod(cumsum(L1' after an 'inString(' loop.) This allows for icons on programs not made for the shell by use of a custom list... but I still need a place for the icontexts...
As for that white line, its because of some system flag making 'Text(' erase the line beneath it. As I said, I have no idea how to fix this, but I know I read it somewhere.
EDIT: just remembered: visit the Y= screen. now how does that get set in the first place
It looks nice reminds me a little of my old CCI shell project, but not as feature filled, although faster. I guess there is a trade off for not using Celtic III and making it more dynamic I hope you have lots of fun with this project
Oh it's probably nowhere near done... getting it to run programs will be the fun part though. (unless I dump the program name to another program...) But yeah, most of that speed during boot is because of Wabbit's instant-write flash. I do quite a bit of archiving on boot. (Pic, GDB, 28-item list)
Grr. Wabbit won't play nice with this. First, my GetProgName function fails in MathPrint mode (returns Str1="mean(", fixable, but annoying), then my icons all have that row missing, I forget how to fix that.
I was too lazy to just paraphase....
Oh yeah! Thanks for noticing holmes.
oh, I was just looking at the pretty screenie.
Yeah, I don't know about that line... Never happened to me on the actual calc until just after I transferred it to the computer. Then, next time I ran it, it garbage-collected and that seems to have fixed it. Then again, I did just replace the batteries before transferring... ?
Anybody have any ideas for how I can keep a more permanent index of programs? My current method is by index in the VAT, and, needless to say, extremely volatile. Also, I'd rather not use Str2 for permanent icon data...
Well, I've been inactive on these forums for a while, but not on the calculator. So this is what I've been doing: a BASIC shell.
Of course its not all BASIC, I've needed an ASM program for 4 functions: 1: Number of programs on user's calculator 2: Getting the first couple bytes of each program, for use with text sprites 3: Getting the name of each program 4: Running the selected program
The startup is a little slow (due to archiving variables such as a copy of the user's graph screen), but other than that it actually works really well so far. It not only saves all of the settings it changes, but every single real/cplx variable!
The setup should be familiar to anybody who has a computer (except the lack of a mouse), using 7*7 text sprites for icons (an unrolled loop, if you're wondering how it draws them so fast). It currently does not support running programs (need to figure out how to do that, but I do plan to allow ASM programs as well), archived programs with icons in the source code, or selecting programs that do not have icons.
Grr. Wabbit won't play nice with this. First, my GetProgName function fails in MathPrint mode (returns Str1="mean(", fixable, but annoying), then my icons all have that row missing, I forget how to fix that. It initializes slower on my calculator, due to the presence of 32 programs on it.
grrr... I wanted to include a backup utility with this, but its failing.
My calc is one of the newer ones, so no pages 4-7. I would think pages 2 and 3 would work well enough though... but apparently not. The calc crashes when trying to parse BASIC with just a backup, and resets immediately upon return to ti-os with a backup and restore.
Scratch that, re-running the app after backup strangely prevents crashing, but the restore still fails.
Everything else mostly works. That'd be the backdoor that still fails.
Actually, 82 (ram page 2) should work. TIOS uses 80 and 81 (ram pages 0 and 1).
Well I'm not sure whether its 82 or 83 that is failing. They both should work fine, but they don't seem to. I'm not sure whether its because I'm messing up somewhere or because of some OS glitchy-thingy.
From what I've read, the OS uses/can use pages 2 and 3 for file transfers. Maybe since byte $4000 of page 2 isn't FF or 00 or something like that, it thinks it has a file transfer going on... And then, why does it only crash when I push enter? (I don't edit/backup $4000-4400/$8000-8400, because wikiti says the OS uses this general area, although probably not for anything permanent/important)
On second thought, I don't see why a backup works fine (mostly), but when I restore, it crashes? Meh, probably something I'm doing wrong there.
Show Posts
I don't know much java. 
(came out to 4 Rect(/RectI( commands per tile, virtually bug-free, see screenie for only known bug)
