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 - Runer112
Pages: 1 ... 130 131 [132] 133 134 ... 153
1966
« on: October 04, 2010, 03:28:05 pm »
I suggest looking at page 15 of the Documentation.pdf file. Reading from archive is explained well there, and it has an example too.
1967
« on: October 04, 2010, 03:23:02 pm »
Axe 0.3.2? You should probably update that 
1968
« on: October 04, 2010, 03:19:46 pm »
So... I was working on porting necro's gfx to axe parser format (for my zelda-like game), and I stumbled upon 2 questions.
1. Can axe read from programs stored in the archive? (Then I mean, my program, since my gfx are in a program in the archive)
2. I have this program data file (created the same way as an appvar), but its source is open (I can read it using TIOS's edit), how can I lock this?
3. Can I "break" loops? For example, I have a for loop that goes from 1 to 10, but as soon as it discovers that number 6 is empty, that it will skip the 7-10 as well?
1. Yes, Axe is able to read data from archive. Reading tilemap data and sprite data from the archive is how my Zelda demo worked  (It seems that everybody wants to make a Zelda or Zelda-like clone lol) 2. You can change the protection status of programs with the flash application Calcsys by finding the program in the VAT and typing "P" to change its protection status. 3. As others have said, to break from a loop, just set the loop variable to an exit condition.
1969
« on: October 04, 2010, 09:22:48 am »
If you decide to upload the source again, I can help optimize it again
1970
« on: October 03, 2010, 09:37:41 pm »
I initially checked for anything that might have been disabling the music in your code, but I couldn't see anything, so I figured I'd try to compile and debug it myself. After much sifting through the code and replacing forum-friendly characters with the real tokens so I could compile this on a calculator, the music appears to work fine for me. Are you sure the version of the failing source you posted is the version that isn't working for you?
1971
« on: October 03, 2010, 08:59:33 pm »
True. And just wondering: Does anyone have an example of where DS<( would be useful?
DS<() Is useful when you have something in a loop/interrupt that you don't want to run every iteration. For instance, if you want to update the screen in a program's main loop or in an interrupt but don't want the screen updating too often (to save processing power for other things), enclose the screen updating portion in something like DS<(A,4) so the screen is only updated every fourth iteration.
1972
« on: October 03, 2010, 08:55:13 pm »
How does it fail? And do you have a version of the code from before the music stopped working?
1973
« on: October 03, 2010, 01:19:54 pm »
(They don't work with the TI's native RecallPic or StorePic commands). It's possible to do this; I've done it using this epic program written by our very own calc84maniac: http://www.ticalc.org/archives/files/fileinfo/391/39138.html
I think this is for Axe...
He was replying to Runer's comment saying that recallpic only works with pic 0 to 9 in BASIC . As Recallpic both supports the Recallpic 0 and Recallpic Pic0, if you use one of the hacked token to recall Pic 11, for example, it will work as well. I tried before with the Devpic8x program.
How would you access the hacked tokens from a BASIC program though? The only way I could see that working is by getting the hacked tokens in Ans or a string variable of something with an assembly program and then recalling them.
1974
« on: October 03, 2010, 12:12:17 pm »
look at this maybe,
Why are you copying random bytes of RAM to the screen? (Not really randomly chosen, but arbitrarily chosen bytes that have no practical meaning) And why one byte at a time?
1975
« on: October 03, 2010, 11:39:33 am »
Umm, there's no reason not to use copy, it's much faster and much smaller than looping through the bytes manually. To copy the screen to a 768-byte appvar starting at P, do this:
conj(L₆,P,768)
And to copy this back to the screen, just reverse it (remember to update the display though):
conj(P,L₆,768)
DispGraph
1976
« on: October 03, 2010, 09:57:54 am »
The "extended pictures" are just pictures with hacked names. The tokens for Pic1 to Pic0 range from [6000] to [6009], and the "extended pictures" just extend this token range from [600A] to [60FF] (They don't work with the TI's native RecallPic or StorePic commands). In Axe, the "name" to access a picture variable would be [0760XX00], where XX is anything from 00 to FF. Although I'm not sure why you would need these if you're using Axe, because it would be more clean and simple to store data in appvars. EDIT: Ninja'd? Although my response contains information yours doesn't
1977
« on: October 02, 2010, 09:39:00 pm »
Just wondering, why are appvars not suitable for your purposes? It sounds like you want the data to be invisible to users. If you want, you can just store the data in an appvar with a name containing an invalid character. The appvar will still exists and work like a normal appvar, but it won't be visible in the memory management menu.
Honestly, though, most people who play calculator games wouldn't even know how to actually access/edit the data, even if it was stored in a visible appvar. And for those who do, they could probably find your invisible appvar anyways if they wanted to.
1978
« on: October 02, 2010, 12:39:33 pm »
Aichi: with Applications, writeback/self-modifying code is impossible (or at least extremely difficult). Applications are stored in flash memory, which unlike RAM, can only be in one mode at a time: read or write. When you're running your Application, you're in read mode, so you cannot write anything to flash memory, which is where your program and any internal data reside. That's why there are AppVars. They're Vars for Apps
1979
« on: October 02, 2010, 12:30:45 pm »
Oh right I remember that. When exiting games with clear, the homescreen content is cleared almost in an instant.
Couldn't you just put the following code at the end of the program, right before it exits? Or is this something different involving apps in particular. While getKey(15)
End
1980
« on: October 02, 2010, 12:14:28 pm »
That's pretty much the way to do it. You'd be surprised just how fast one massive For() loop that OR's the contents of both buffers is, though. I calculated that the following loop runs about 40 times per second at 6MHz:
Repeat getKey(15)
For(A,0,383)
.That ﹢ symbol is the 16-bit OR operator
{A*2+L₆}ʳ﹢{A*2+L₃}ʳ→{A*2+L₆}ʳ
End
C+1→C
End
Pages: 1 ... 130 131 [132] 133 134 ... 153
|
Show Posts
