Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: DJ Omnimaga on June 03, 2010, 03:21:14 am
-
Ok, so definitively, I have absolutely no luck with Axe APPVARS. Always had trouble with them.
Basically I am trying to write a map editor that reads/write to a map stored into an APPVAR, but my problem seems similar to the one I got when trying to write a screen capture program for Kindermoumoute two weeks ago. In the current case, though, it's the bottom of the data that seems glitched up. Anyway, here is my code for the appvar creation (before I even started making the map at all), then the map editing tool (which lets you scrolll around the map and edit every two tile, the top-left-most one, so far):
:.APPVAR
:"vMAP"?GDB1
:GetCalc(GDB1,16800)
:.AMAP
:[FFFFFFFFFFFFFFFF00000000000000000123456789ABCDEFFEDCBA987654321002468ACEFDB97531369258147ADBECF0?Pic1
:"vMAP"?GDB0
:GetCalc(GDB0)?Q
:!If Q
:Return
:End
:0?L?S?X?Y
:Fix 5
:Fix 1
:Repeat getKey(15)
:ClrDraw
:For(A,0,5
:For(B,0,6
:{B*120+A+L+Q}?C <-note, this is from our dear friend tutorial at http://ourl.ca/4550 (thanks btw)
:C^16?D
:C/16?C
:Pt-On(A*16,B*8,C*8+Pic1
:Pt-On(A*16+8,B*8,D*8+Pic1
:End
:End
:Pt-On(4,56,S*8+Pic1
:Text(16,56,L?Dec
:DispGraph
:getKey?Z
:L-(Z=2)+(Z=3)-(120*(Z=4))+(120*(Z=1))?L
:If L>60000
:0?L
:End
:If L>15961
:15961?L
:End
:If Z=54
:S?{Q+L}
:End
:If Z=55
:S+1?S
:If S=6
:0?S
:End
:End
:End
:ClrDraw
:DispGraph
:Fix 4
:Fix 0
Basically, this is for a 240x140 tile map. Since I use half-byte compression, each row of tiles are 120 bytes each.
Note sorry if the sprites looks horrible, this is just for testing. And yes it uses half-bytes. I'll try to figure out later how to store tiles to each half-byte. For now, I am more worried about what am I doing wrong?
-
First thing I noticed is that you're scrolling by 2 bytes at a time when moving left and right since these are half bytes. What I would to do make this less of a nightmare is to write a subroutine that returns the sprite number times 8 (the sprite index) at a given a coordinate position on the map.
:.Input
:.D=x-position
:.Ans=y-position
:
:Lbl XY
:{*120+(D/2)+data}→C
:If D^2
:C^16*8
:Return
:End
:C/16*8
:Return
Use different temporary variables if C or D are locked up.
This makes it much easier to draw maps and read tiles:
:For(A,0,11
:For(B,0,6
:A+X→D
:Pt-On(A*8,B*8,B+Ysub(XY)+Pic1)
:End
:End
Here I'm not using L, I'm using an X and a Y coordinate since its much easier to program and there is less math to do. Only downside is that now you need 2 variables to keep track of position instead of 1.
X must be in the range 0-227 and Y must be in the range 0-133 otherwise you're drawing random garbage outside the appvar.
-
Yeah thanks for this, but sadly it won't solve my glitch issue. The 2 tiles jumping issue you reported is something I'll worry about later. Now this is not the topic question. Thanks, though, but I would like to know how to fix my bug. If people dwell on the other issues (such as the 2 bytes scrolling, which I was very well aware of), I'll have to stop my project altogether, since I can't fix my bug in the first place by myself.
So I ask again, can anyone help me solve my issue with the tilemap glitching up at the bottom? It seems like when I check through it, I'm off by about 500 bytes or so, or garbage is added at the end when creating the app, but I checked the former and I am certain I made my prog read from the right memory locations.
-
Did you zero the data in the appvar before looking at the map?
:"vMAP"→GDB1
:Return!If GetCalc(GDB1,16800)->A
:fill(0->{A},16799)
The reason I suggested the one byte at a time method was because I though this might be a boundary problem where you went past the end of the data at the bottom resulting in random tiles being shown. I don't know how to restrict the movement with a single variable used for both coordinates which is why I split it up.
-
Oh wait I forgot to do that. I'll give this a try.
However I think for now I'll resort to 1 byte tiles instead. It seems like half bytes + scrolling == major hassle. It will be even worse when I try adding smooth scrolling and while at work I thought about it, and I am fairly certain I'll hit the 8K code limit much faster with all the additional code resulting from half byte checks and stuff. Yes the data will be twice larger, but I think it might be better this way, especially that this is one of my first real venture into tilemapping.
I'll check all the code you posted and stuff, though, to see if what I could do. Thanks
-
This looks really cool! Good luck DJ! ;D
-
Btw, SirCmpwn had a half-byte-based scrolling tilemapper, as he told me a few hours ago somewhere, but he also had the speed issue, I think, because he told me it didn't feature smooth scrolling.
Player had issues with Rally-X. If you wondered why Rally-X isn't much faster, it's because of the amount of time it takes to handle everything from an half-byte tilemapper
-
aww that's sad. I was thinking of making a scrolling tilemapper for the Axe contest, but if it's hard to do, then I might just as well make it screen to screen map (like Illusiat 13, Elmgon, Serenity, etc.)
-
screen to screen would work pretty well with half bytes, because you just need to uncompress your map data into L1 then use that uncompressed data for collision detection/event triggering.
If you use bytes, though, then you should be able to have smooth scrolling fine, though. However, with how crappy the LCD is, I am unsure if smooth scrolling looks good on a real calc if it's too fast. My guess is that you might need to update the screen like 15-16 times a second max
-
In reference to your post at http://ourl.ca/5989/93100 , do I need to swap the ^ and / for the routine above?
I Integrated it in my code, but regardless of if I swap the ^ and / or not, I see garbage displayed in both cases.
EDIT: screenshot attached to post. Code coming soon.
-
At what values of X and Y do you see garbage? Also, you mentioned before that you were going to fill the appvar with the 0 tile before looking at it, was that implemented in your test?
-
yep, the appvar is filled with zeros and the garbage happens at every single values of X from 0 to227 and Y from 0 to 133
I checked if I made a typo and couldn't find anything wrong :/
EDIT: screenshot attached, altough at wrong post x.x
(http://www.omnimaga.org/index.php?action=dlattach;topic=3391.0;attach=1449;image)
EDIT 2: code below:
:.APPVAR
:"vMAP"→GDB1
:Return!If GetCalc(GDB1,16800)→A
:Fill 0→{A},16799)
:.AMAP
:[FFFFFFFFFFFFFFFF00000000000000000123456789ABCDEFFEDCBA987654321002468ACEFDB97531369258147ADBECF0FFFBDFFDEFFFBFFE80AAB4AAB4BE80FF→Pic1
:"vMAP"→GDB0
:GetCalc(GDB0)→Q
:!If Q
:Return
:End
:0→S→X→Y
:Fix 5
:Fix 1
:Repeat getKey(15)
:ClrDraw
:For(A,0,11
:For(B,0,6
:A+X→D
:Pt-On(A*8,B*8,B+Ysub(XY)+Pic1)
:End
:End
:Pt-On(0,56,S*8+Pic1
:Text(12,56,X►Dec
:Text(32,56,Y►Dec
:Text(52,56,120*Y+X►Dec
:DispGraph
:X-getKey(2)+getKey(3)→X
:Y-getKey(4)+getKey(1)→Y
:If X=65535
:0→X
:End
:If X>227
:227→X
:End
:If Y=65535
:0→Y
:End
:If Y>133
:133→Y
:End
:If getKey(55)
:S+1→S
:If S=8
:0→S
:End
:End
:End
:ClrDraw
:DispGraph
:Fix 4
:Fix 0
:Return
:Lbl XY
:{*120+(D/2)}→C
:If D^2
:C^16*8
:Return
:End
:C/2/2/2/2*8
:Return
I must have integrated your routine the wrong way :/
-
What is that last number? You shouldn't have "L" in your code anymore since you're using X and Y instead. Also, I can't really help without seeing the code you're using.
EDIT: nevermind, saw your edit, will look at code.
EDIT2:
:{*120+(D/2)}→C
should be
:{*120+(D/2)+Q}→C
-
oh ok I forgot the "data" part. Thanks!
Now how would I change a tile in the tilemap?
-
:.Input:
:.D = x-position
:.C = y-position
:.Ans = tile to store there
:
:Lbl ST
:→E
:C*120+(D/2)+data→C
:If D^2
:{C} and 240+E→{C}
:Return
:End
:{C}^16+(E*16)→{C}
:Return
Note that that 240 is actually the decimal for b11110000 (a high nibble mask) and has nothing to do with the the map size.
-
Ok I will give this a try later today
-
Ok that worked, thanks! I have a bit of issues understanding the code, though. I think this is gonna be tricky to make an actual game with the collision detection x.x
-
The cool thing about subroutines is that you don't need to understand the code. Once you know what the subroutine does, you just put it everywhere you need it and never think twice about it.
-
well, my issue was that the routine you posted for moving the map around and the one to change a tile in the map seemed a bit different. The second one even missed the brackets
1st: {*120+(D/2)+data}→C
2nd: C*120+(D/2)+data→C
So I am kinda at loss
It took me about 30 minutes to implement the second routine because I couldn't figure out how to call it x.x
Now I can't imagine how I am gonna do tile-based collision detection (or worse: scrolling without recalling the entire tilemapper every frame)
-
I decided to give up on Axe language altogether.
It is becoming clear to me that the things I want to do in Axe are way beyond my learning capacities and there's no more hope in bothering trying. I just can't do it. I don't know what to say anymore but I am posting the map editor as it is now, not working. People are free to do whatever they want with it.
With that, I am afraid this ends my calc programming "carreer" as well. My dream of making games that requires speed (impossible in BASIC) has been pretty much destroyed now, and I just no longer have the motivation to work on a RPG anymore in BASIC.
-
Gee, that's terrible. Well, if we can't convince you... I'm sorry. :(
-
I just realized that version isn't the latest but slightly older (a few minutes). However the newer version was even worse (when running Asm(prgmAMAP) all it did was displaying "Done" even if shell selected was No-Stub, appvar was present and even if I did a RAM clear before trying it)
-
I'm sorry to hear that, and I hope you change your mind Omni. :( Even if you can't understand everything, I believe you can still create some fantastic programs. Either way, I respect your decision.