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 - Quigibo
Pages: 1 ... 89 90 [91] 92 93 ... 135
1351
« on: June 08, 2010, 11:44:22 pm »
det is not a command that contributes anything to executable code. It only tells the parser to allocate extra space to the end of the program. You want to use the Fill command to fill memory with zeros.
If you want a sub string of Str1 starting at A that is B bytes long, you can do this:
:"Hello World"->Str1
:
:conj(Str1+A,L1,B) ;Copy the part of the string you want to L1
:0->{L1+B} ;Add a null character to signify the end of the substring
:Disp L1 ;Display the substring
1352
« on: June 08, 2010, 11:30:02 pm »
You can always display them manually...
This displays the 32-bit number in the location Str1, but destroys the number afterwards. (range of 0 to 4,294,967,295)
Lets Make Str1 hold 9000*9000 = 81,000,000 In Hex, that's 4D3F640.
:[04D3F640]->Str1
:
:For(D,0,9)
:0->A
:For(B,0,3)
:A*256+{Str1+B}->C^10->A
:C/10->{Str1+B}
:End
:Output(15-D,0,A+'0'â–¶Frac)
:End
:Disp i
Of course, you can extend this to any arbitrary length.
Please don't ask me how this works. I looked up the algorithm on the learn z80 in 28 days tutorial. I kind of see why it might work, but I don't really know it enough to explain.
1353
« on: June 08, 2010, 07:37:39 pm »
Well, I don't want to do too many of those. Even though it reduces the size, it also slows down the program a little each time it has to call a subroutine. Normally, you don't notice this, but sometimes when you're doing very heavy math (like checking if any objects on one list collide with objects on another list) you can actually notice it.
That's an interesting optimization though. It would be very difficult to figure out what to group though. Like if you did _*2+1/8+L1 a bunch of times for instance, its convenient to group that whole operation into a single subroutine. But unlike a computer compiler, Axe doesn't have large memory or fast speed, unless I use the extra ram pages maybe but it would still be super slow for larger programs, so its really not practical to keep track of all that. Its going to have to be up to the programmer to do a majority of these optimizations. There's always the computer compiler idea though...
1354
« on: June 08, 2010, 07:26:33 pm »
I don't know if this is because of Axe Parser at all, but seeing as it's only started after I downloaded it, I felt I should post it here.
I've been noticing that certain actions on my calculator have gotten slower and slower. Before, I could archive and unarchive variables under 1 KB almost instantaneously, but recently, it's become really slow. I just tried to archive a mere 68-byte program, and it took four whole seconds. Same goes for exiting Axe: when I first downloaded the app, it exited in less than a second, but now it also takes something like four seconds. Anyone have any idea what's happening? I've already tried RAM clears (dozens of them since I first downloaded Axe -- don't worry, most of them were intentional), and it hasn't helped. I really hope this isn't anything permanent.
You need to garbage collect. I could have Axe ask you periodically, but I think it would get annoying.
1355
« on: June 08, 2010, 04:29:03 pm »
When you draw sprites in grayscale, you are drawing twice as many sprites as monochrome since you need to draw to both the front and back buffer layers, and 4 times as many if you need to mask any of those sprites! Also, the flickeryness is my fault, I've already written a better looking routine with the help of calc84maniac.
1356
« on: June 08, 2010, 04:51:56 am »
Hmm... I can't tell if the locations for collision detection are accurate... I would try using the method I used in AXERPG. I was able to get collision detection there pretty easily even with a 8x16 sprite. You would have to adapt it to half byte compression, but that's really not that difficult since you would only have to modify that one subroutine and it looks like you already understand the math behind it.
1357
« on: June 08, 2010, 02:00:37 am »
I'm feeling particularly evil today >:)
1358
« on: June 08, 2010, 02:00:12 am »
I don't think so. Archive is a type of ROM, but not vise versa. The calculator is divided into "pages". Have you ever wondered how the calculator can have hundreds of kilobytes of flash, but can only read values from 0-65535? This is becasue you have to swap in pages which will temporarily replaces part of the rom with a page of flash in 16kb chunks (like for instance replacing over the location $4000 to $7FFF which is how applications run). This is why its a little trickier to read from archive since you also have to keep track of page number and often you're replacing over parts of the ram or rom that are needed for other things.
1359
« on: June 08, 2010, 01:43:09 am »
Not quite. RAM (Random Access Memory) means you can read, write, and execute over it. The rest is ROM (Read Only Memory) meaning that you can only read and execute over it. So its only locked off from writing. That's why you can read from it and see something, and obviously you can execute over it (its part of the OS after all). Different combinations of these 3 factors exist, although I'm not sure about the variety for the calculator.
1360
« on: June 07, 2010, 09:44:04 pm »
I don't understand why there are so many of these: {{L1}} a pointer in double brackets. If you really are using that as a pointer to a pointer, then you need to use the entire 16-bit pointer and not just read a single byte from it. But I don't think you're trying to double reference from what I see. Everywhere you have a {L1} should be just L1 I presume.
Also, it doesn't even look like L1 is initialized anywhere. You can't assume it starts out as all zeros, its usually random garbage.
1361
« on: June 07, 2010, 06:14:55 pm »
That's actually only partially true. I talked to BrandonW and he said that the 10-15 minutes is only for signing applications. You can still compile to applications at a decent speed and run them on your calculator. Its only when you want to transfer the app to another calculator that you need to sign it. Another option is to just send the app to a computer and have the computer sign it super fast.
Timeline? Possibly the next version, but I can't guarantee anything. I only made very basic progress so far, but BrandonW has already written a program that compiles apps and he is helping me decipher his code so I can use it for the parser.
1362
« on: June 07, 2010, 06:01:27 pm »
RLE is great for decompressing. BUT, if you have a very large tile map, say its 60x40 for example that needs to be scrolled through, that's 2400 bytes. You can use half byte compression to only take up 1200 bytes and maybe half-byte RLE would be 500 bytes in this example. The fact is, the map is too large to decompress anywhere in RAM unless you tack on extra size to the program. So you're better off reading directly from the map in the program data. When you read off that map, it needs to be fast so RLE isn't going to be possible.
1363
« on: June 07, 2010, 05:43:48 pm »
I remember Quigibo mentioning a while ago that statements like "If A" may not work in some situations any more. Why was this again?
I didn't end up doing that since my logic was flawed.
1364
« on: June 07, 2010, 01:53:23 pm »
Don't forget, the executable is the same size regardless, and you can archive your source before compiling to save space.
If you're using half byte tiles though, hex is more convenient since every digit 0-F are individual tiles.
1365
« on: June 07, 2010, 12:39:46 pm »
Wait until application compiling is completed. That gives a 16kb limit, enough for most projects. You can have data be external variables like in appvars and programs, but not executable code.
Pages: 1 ... 89 90 [91] 92 93 ... 135
|
Show Posts