Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: DJ Omnimaga on May 10, 2010, 02:10:03 am
-
Hey, I noticed something weird happening when compiling for MirageOs/Ion:
Sometimes, when exiting my tunnel game, the file size in Mirage will show up as 65535 bytes, as you'll notice in the screenshot below my source code
:.DJTUNNEL Axe Parser Tunnel clone
:"vDJTUNNHS"→GDB1
:UnarchiveGDB1
:[80C0E0F0E0C08000→Pic1
:"AXE TUNNEL"→Str2
:"2010, by DJ Omnimaga"→Str3
:"SPEED:"→Str4
:0→D→P+1→S+1→Q→K
:5→J
:8→C+1→R
:29→I+1→A
:40→W→T
:Full
:DiagnosticOff
:ClrHome
:ClrDraw
:For(Z,9,21
:Line(0,Z,95,Z
:End
:Line(0,56,95,56
:StorePic
:ClrDraw
:For(Z,8,22
:Line(0,Z,95,Z
:End
:For(Z,56,63
:Line(0,Z,95,Z
:End
:DrawInv
:Fix 5
:Fix 1
:Text(20,12,Str2
:Fix 0
:Text(14,57,Str3
:Fix 3
:Text(5,35,Str4
:Repeat Z=54
:DS<(K,12)
:DispGraphr
:End
:DS<(J,11-(S*2))
:Pt-Change(I,35,Pic1)
:I+1→I
:If I=86
:29→I
:End
:End
:getKey→Z
:If Z=15
:1→S
:Goto GO
:End
:Z=3-(Z=2)+S→S
:If S=6
:5→S
:End
:!If S
:1→S
:End
:End
:ClrHome
:ClrDraw
:For(Z,10,50
:Line(0,Z,95,Z)
:End
:Repeat W=6 or getKey(15)
:P+S→P
:DS<(C,8)
:rand^2*2-1→D
:End
:R+D→R
:!If R
:1→R
:End
:If 62-W<R
:62-W→R
:End
:A-getKey(4)+getKey(1)→A
:Pt-Change(0,A,Pic1)
:Line(95,R,95,R+W)
:DS<(Q,S)
:DispGraph
:If pxl-Test(0,A) or pxl-Test(0,A+6)
:Goto GO
:End
:End
:Pt-Change(0,A,Pic1
:Horizontal(-
:DS<(T,99)
:W-1→W
:End
:End
:Lbl GO
:getKey
:Fix 4
:Fix 2
:ClrHome
:If P
:Output(0,0,"Score:",P►Dec
:End
:GetCalc(GDB1)→M
:If M
:If P>{S*2+M-2}r
:P→{S*2+M-2}r
:End
:Else
:GetCalc(GDB1,10
:GetCalc(GDB1)→M
:P→{S*2+M-2}r
:End
:Output(0,1,"SPEED HIGHSCORE
:For(S,1,5
:Output(0,S+1,S►Dec," ",{S*2+M-2}r►Dec
:End
:Output(0,0
This happens in version 0.2.0 through 0.2.3 of Axe Parser (basically every version that has built in shell support)
-
Is anyone else getting this error?
Could it be possible your high score code is leaking and overwriting the program size bytes? Like I'm confused where that "S" is coming from when you first check if the high score file exists. I never saw S initialized. Also, could it be possible you're using a ram location used by MOS like L2?
-
Mhmm not sure. As for S, do you mean I have to do 0->S at the beginning of my program? Cuz I actually did
0→D→P+1→S+1→Q→K
-
Any clue? I seriously don't know what I am doing wrong.
I still don't know how MirageOs+Axe works with memory together, so it's impossible for me to figure out how to not overwrite anything MirageOs uses (besides L2) if any
-
I think it's a little know fact that Mirage uses AsmFlag1 for stuff with the size. I think Axe is using this flag somewhere, and it's causing problems. Quigibo, could this be the problem?
To clarify: It won't cause a crash, but it's irksome that somewhere Mirage and Axe don't get along. ;D
-
Yes, I do use that flag. That must be it. Are there any flags that MOS doesn't use that I can steal?
-
I have no idea, but I will share where this knowledge came from: There's a thread somewhere on UTI in which Iambian was dealing with the same issue in his Fishy game. Someone brought this up and Iambian changed it. You can see evidence of this in his source code, as it has an equate so he didn't have to change it all. ;)
I'm glad we found the glitch! ;D
-
Is the problem just a display issue or will it actually do something bad or anything if not fixed?
-
Calc84maniac or BrandonW might actually know a lot about it.
As for now, I did not receive any crash resulting from the 65535 bytes thing. Also my game works perfectly under DoorCS6
/me hopes it remains this way in DCS7 D:
-
Nice bug catch guys! It's really weird how some of these things pop up with older programs. =D
-
Also, I tried my game under Ion. Works perfectly. Seems to only happen in MirageOs
-
Yes, I do use that flag. That must be it. Are there any flags that MOS doesn't use that I can steal?
Maybe asm_Flag2 or asm_Flag3?
Have you fixed this? Not many assembly programs use asm_Flag2 and asm_Flag3, I think.
You can also reach the statVars safe ram through iy.
-
Well, it has to be a location that isn't in any of the L1-L6 free ram and it can't ever be modified from any standard bcalls. I switched to asm_flag2, we'll see if this fixes it.
-
I hope this one is not used by any shell, it would suck if none of those were used by no shell at all. If it was the case, do you think in the future, you could make Axe use a different asm_flag (or something else) depending of which shell he chooses to compile for?
-
That should work I think, what say you Quigibo? I think he already does conditional compiling to make use of built-in routines provided by the Shells.
-
yeah that's what I thought. One thing I worrry about, still, though, is that I am not sure what Safe RAM areas the new DCS uses. It's not even guaranteed DCS6 Axe programs will work well under DCS7. That's unless he changed none, though.
-
Hopefully it uses less or the same as Mirage, or else not only will mirage programs not work, but a lot of Ion and other assembly games O.O
-
I actually have been putting off conditional compiling, I think only a few of the commands do that, and only in mirage.
The problem is that most of the built-in functions are either slower than my routines, don't take the right input or output, or don't work quite the same way. For instance, there is a shell call for sprite drawing, but it doesn't clip the sprites. And there is one for random numbers, but only 8-bit random numbers. There really aren't as many routines as I first though either. I think Doors has a lot, but other than that, the line drawing and get-pixel routines seem to be the only ones I can use. I think I'm going to just drop conditional compiling all together until I add a new compiling mode to compile for size rather than for speed.
-
Ouch that sucks, I hope you can still find a solution to make sure games works in all shell, or maybe just put warnings for commands that won't work well in Mirage for example, so people won't bother compiling their games for it.
-
All commands work in all shells, the problem is just that I can't use the built in commands that come with Ion/MOS instead to save space.
EDIT: 500th post :o
-
Oh I meant mostly the MirageOs issues we talked about (like the 65536 thing and Obstacle Snake author reporting random crashes with his game related to Mirage)
-
You can also reach the statVars safe ram through iy.
I saw now it is one of free ram used by Axe Parser. You could instead use statVars+2 for the pointer.
Maybe someone wants to do or use Axe Parser program as an assembly lib. We need to add to the documentation what safe rams are used by xLib and CelticIII if they are used too...
-
we can actually. However, no stuff requiring reading from BASIC vars yet. Basically Axe libs for BASIC programmers would be more like magic animations or transitions, for example.
-
Yeah, i cant wait for the day when variable reading and writing are added, then we can start writing our own helper programs akin to celtic and xcopy ^^
-
Too bad the compiled code is somewhat unpredictable. I though it was fixed locations because BuilderBoy had success with SMC.
we can actually. However, no stuff requiring reading from BASIC vars yet. Basically Axe libs for BASIC programmers would be more like magic animations or transitions, for example.
Yes, that is a good use. You can code your animations instead of going through steps of a builder of a assembly program with pictures.
Yeah, i cant wait for the day when variable reading and writing are added, then we can start writing our own helper programs akin to celtic and xcopy ^^
In assembly, that is not of the hardest tasks because you are using high-level routines of the TI-OS. Ans, X, Y, n, Theta have their own b_call() to store or read.
So porting to Axe Parser still requires some smart code to do it and will probably need coding just for this task.