This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - ztrumpet
Pages: 1 ... 4 5 [6] 7 8 ... 385
76
« on: December 18, 2011, 08:23:45 pm »
That is awesome! I'm so glad you're working on this again; keep it up!
77
« on: December 17, 2011, 10:09:56 pm »
You could also just cap the "terminal" velocity of the character. This would limit the checking so it would have a maximum of places to check. For instance, if you capped your Y velocity var at 512, the character could only move a maximum of two pixels down per frame (assuming *256 inflation). As for tilemap based collisions, check here: http://ourl.ca/4279/169823
78
« on: December 17, 2011, 10:05:25 pm »
Quigibo, why don't you add an invert command like the rotC, rotCC, flipV, and flipH commands? This would make tasks like what Frey wants to do a lot easier and I can see it being just as useful as those other four commands.
79
« on: December 16, 2011, 06:55:35 am »
Can there be an option to make pxl-test() return a one instead of zero when it is out of bounds?
Frey wouldn't it just be easier to check if the coordinates are outside of the bounds of the screen first?
I'm in favor of a really optimized scrolling tilemapper routine, but I'd like to see some more of these agressive ops 
Bounds checking is built in to the routine, and it'd be a trivial matter to change it from returning a 0 to returning a 1
Yes, but that would not allow backwards compatibility to everyone who already uses 0 as the value returned by objects out of bounds in their code. Like leafy said, it'd be easier to check first and then pixel test.
80
« on: December 15, 2011, 10:38:26 pm »
That looks pretty great. Nice job on it!
81
« on: December 15, 2011, 10:37:56 pm »
Wow! I heard you talking about Tag 2 and thought it was too good to be true. Apparently, it's not, which is great. I loved the first Tag; I'm sure this one's going to be incredible as well, especially judging from the look of the screenie above. Wow. (believe it or not I wrote that elevator routine from scratch, and I think it might even be better than Builder's  )
I like how the pause is in the middle, so if it takes longer for a larger level to load it just looks like its a longer elevator. Edit: Wait a minute - it doesn't stop, it just goes slow... That is so cool!
82
« on: December 15, 2011, 08:49:13 pm »
Sorry to say it, but it is your code's fault. This line is the problem:
:0→{T+L₄}ʳ→{P+L₅}ʳ
The value left in hl after storing a number to a constant pointer is the original value you stored. But when storing a 2-byte number to a non-constant pointer, the value left in hl is pointer+1.
And now I feel really, really dumb. I should have remembered to check that. Thanks, Runer, and I'm glad to hear this isn't Axe's fault.
83
« on: December 15, 2011, 07:18:16 pm »
There is some wacky bug with the inData() command. (This is tested with the most recent version of Axe, 1.1.0, on a TI 84+SE running 2.43) This code comes straight out of Detonate. I'm sure it can be triggered in other situations as well, but this is how I ran into it. I am using inData for a collision check with my explosions. If you need to see more code than what I provide here, I can give that to you, but I think this should be sufficient: Here's my code that should have worked, but didn't: : 0->{T+L4}r->{P+L5}r
: !If inData(r3*16+r4+1->N,L4)
: !If inData(N,L5)
: N->{P+++L5-1}
: End
: End The code inside the second !If would be skipped even if it was supposed to be executed on some occasions. This code deals with bombs being detonated in my game, and sometimes the bombs wouldn't be set off, which happened if the second !If was erroneously skipped. By adding more/less code at the beginning of my program I could change where the bomb would fail to be detonated, but I never saw a pattern. This code, however, works, proving that it's an Axe bug and not my own code at fault: : 0->{T+L4}r->{P+L5}r
: !If inData(r3*16+r4+1->N,L4)
: 0->{P+L5}r
: !If inData(N,L5)
: N->{P+++L5-1}
: End
: End Like I said, let me know if you need more info. I can give you my source if you need it; it's no trouble at all.
84
« on: December 15, 2011, 07:02:07 pm »
This looks great! It looks like an excellent job by everyone involved.
85
« on: December 14, 2011, 07:17:07 am »
Awesome! This also means error scrolling can finally be automatic since it won't ever crash. No need to press [prgm] anymore, it will always take you to the error unless you press [clear].
Does error scrolling work even if the program being compiled is in archive? Thepenguin added a place for you to chain into zStart for that to happen, and it would certainly be a wonderful addition to Axe.
86
« on: December 13, 2011, 08:50:40 pm »
wait. so I need the space between those hex?
No. You don't want spaces there; I included them only to make it easier to look at on the computer.
87
« on: December 12, 2011, 11:01:50 pm »
What do I put for that pointer?
Try this (or something like it): : [0203 FFFFFFFFFFFFFFFF 0000000000000000 FFFFFFFFFFFFFFFF FF818181818181FF FF818181818181FF FF818181818181FF]->Pic1
: ClrDraw
: Bitmap(10,20,Pic1)
: DispGraph
: Pause 1000
88
« on: December 12, 2011, 10:58:44 pm »
I could at the same time display the percentage of the subprogram elsewhere at this moment.
That's a really cool idea, and I like it a lot. Maybe you could display it in the very bottom row of the screen.
89
« on: December 12, 2011, 10:33:53 pm »
It will know the executable size after pass 1, but it won't know the total size including the data until after pass 2.
Ah, okay. In that case, I vote for the homescreen method too.
90
« on: December 12, 2011, 10:30:45 pm »
@Happybobjr
The problem is that it won't know the size until it finishes the entire compile. If I make it pause the size at the end, it will annoy many users who want to compile as quickly as possible. But I just had a great idea as I was typing this. What if I use the homescreen to display the final size of the program? Axe clears the homescreen anyway when it quits, it might as well do something useful with it. I like that, I think I'll add that feature. By the way, the size displayed will not be the same as what you see in the memory management menu because it will not include the symbol table entry.
Won't it know the final size after Pass 1? Couldn't it display the size then and have it onscreen while Pass 2 is happening? I'm not opposed to the size being displayed on exit, I just figure it'll conflict with some other programs so all users won't be able to see it, plus I like having a clear homescreen.
Pages: 1 ... 4 5 [6] 7 8 ... 385
|
Show Posts
