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 ... 123 124 [125] 126 127 ... 135
1861
« on: March 07, 2010, 01:23:26 am »
Hey hey! It certainly does catch the optimization. But repeated divisions are only optimized in terms of their speed not size. Regular division is still less code (if you use it a few times). That's why its not an automatic optimization, you can choose when you need the extra speed with the downside of larger code. Very nice explanation by the way 
1862
« on: March 07, 2010, 12:29:50 am »
umm... do you mean the value of the address becomes the expression? I think the other way around is the expected behavior, no?
I'm pretty confident this won't change. I know that I might in the future add something to store 16 bit numbers into 2 consecutive bytes, but I think that will use a different syntax anyway.
1863
« on: March 06, 2010, 11:00:51 pm »
99% of the time, if the executable is smaller, the code is also faster. How much faster will vary, but there are very few exceptions to this rule. A notable one is successive divisions by 2 instead of a single regular division. So in general, you can use this rule to see if the program is faster or slower without even running it.
1864
« on: March 06, 2010, 10:17:46 pm »
What is a sprite? Its just a pointer. As is a string, even the variables themselves are pointers! But you don't have direct access to those which is why L1 says "saveSScreen+54" because each 2 byte number is stored there (26*2 = 52) plus a 2 byte random seed = 54 bytes.
So actually, this is kinda cool. Another way you can access variables:
:5->A
is the same as:
:5->{L1-54}
:0->{L1-53} ;This is because the number is 2 bytes and also little endian
But the first one is more optimized of course.
1865
« on: March 06, 2010, 10:05:19 pm »
When you input pictures, strings, and other data, it get added to the end of the program. Here is the memory map for you: <Program><Data1><Data2><Data3>...<LastData> The first data block you entered was "Pic8". Don't forget, that's just an arbitrary name, you can call it Str8Z if you want and it will behave the same way. What it does is add that data you just wrote to the end of the assembly program. The pointer to that block of data is now in the name Pic8. You will see if you do "Disp Pic8>Dec" that Pic8 is really just a pointer to the end of the program so far. But then, the you added more data and stored the pointer to that data in Pic7. Those new bytes get added to the end of the program directly after the first sprite since that is the new end of the program. In fact, you don't even need to give it a name, you can leave the -> part out since you don't need to refer to it by a unique name. You can get that pointer simply by doing 8+Str8 since it occurs 8 bytes after the first pointer. I am going to call the first sprite Str8Z so it appears arbitrary: :[FFFFFFFFFFFFFFFF]→Str8Z
:[FEFEFEFEFEFEFE00]
:[FCFCFCFCFCFC0000]
:[F8F8F8F8F8000000]
:[F0F0F0F000000000]
:[E0E0E00000000000]
At this point, the first picture is Str8Z. You can call Pt-On(X,Y,Str8Z) The next sprite is 8 bytes after the first one right? So you can do Pt-On(X,Y,8+Str8Z) The next is 8 bytes after that so you can do Pt-On(X,Y,16+Str8Z) Then Pt-On(X,Y,24+Str8Z) In general, the nth sprite (starting at n=0) in that particular data block is N*8+Str8Z. So in general, you can do Pt-On(X,Y,N*8+Str8Z) to get the nth sprite. EDIT: and by the way, Builderboy's method is identical.
1866
« on: March 06, 2010, 09:41:21 pm »
You didn't define Pic0 so of course its undefined. In your case, the first sprite is Pic8 it should be C*8+Pic8. But actually, you start C at 3 so it should really be C-3*8+Pic8. That would make C=3 correspond to pic8, C=4 is pic7, etc... You might have to rearrange the sprites if you need it in the other order.
Edit: and no, you don't need the "]" after sprite data, just like strings don't need the "
1867
« on: March 06, 2010, 06:49:26 pm »
I'm calling routines that use the VAT to expand the memory, that's why. But I don't really know enough about how the OS structure works to write those routines myself so I have to use them.
1868
« on: March 06, 2010, 06:46:49 pm »
How do you know he didn't do this first:
:L1->A
I use that trick all the time when I have a lot of math like:
:Y*8+X+L1->A
Because that way it can become:
:{A}->B
:15->{A}
Which saves memory and speed if you call it a lot.
1869
« on: March 06, 2010, 06:13:41 pm »
STARSHIP is hardly even playable with 60 sprites because its too fast with 16mhz mode  In regards to that other post, maybe this will help: ........ <- Normal sprite that will be drawn (lets call Pic1)
........
........
........
...00...
..0000..
..0000..
...00...
........
........
........
................
........ <- One byte after Pic1 (Pic1+1)
........
........
...00...
..0000..
..0000..
...00...
........
........
........
................
........
........ <- (Pic1+2)
........
...00...
..0000..
..0000..
...00...
........
........
........
................
........
........
........ <- (Pic1+3)
...00...
..0000..
..0000..
...00...
........
........
........
................
........
........
........
...00... <- (Pic1+4)
..0000..
..0000..
...00...
........
........
........
........Notice how the sprite appears to animate a ball moving upwards. Reversing this would make it appear moving downwards. Sorry for the really tall post.
1870
« on: March 06, 2010, 05:37:58 pm »
100 Lives? That's a lot!
You're clearly thinking about how basic uses Output() which is not how Axe uses it. In Axe, the last argument is the address of a string you want to display, not the value of the number. If you want to instead display the number in base 10, you use >Dec at the end.
I think everyone would benefit by reading the documentation all the way through, maybe more than once, and then ask questions if you are unclear about a description. A lot of these questions can be answered there. But also, I think its the general unfamiliarity of pointers, arrays, and unsigned arithmetic that are throwing people off. A new tutorial should address these issues. Would anyone like to help me write one if you have a clear understanding already? I think it would really clear up a lot of the confusion.
1871
« on: March 06, 2010, 04:09:06 pm »
Because there are conceivably situations where you may want to draw fractions of a sprite. Consider this sprite, I'll draw it in ascii so you can see it.
........
........
........
........
...00...
..0000..
..0000..
...00...
........
........
........
........
Its not 8x8, but by drawing portions of this sprite with offsets from 0-3, you can have a bouncing ball animation without needing 4 separate sprites for each frame. In fact, any scrolling, looping sprite like a barbershop spiral or checker pattern reversal can use this optimization.
1872
« on: March 06, 2010, 03:37:50 pm »
There are 8 bytes in every picture. Lets say the first picture is stored at the end of your program at address 9000. That means the second byte of the picture is at 9001, the third at 9002, etc. until the 8th byte is at 9007. The first byte of the NEXT picture then starts at 9008. You can try Disp Pic1>Dec if you want to see it visually, it will be over 9000!!! You'll see each picture is 8 bytes apart, assuming that they were all created one after another. If you have a string defined in between them or something, that would offset the data a little.
<Entire program><8 bytes of first pic><8 bytes of second pic>...
1873
« on: March 06, 2010, 02:15:49 pm »
:rand^96->X (returns 0-95)
:rand^64->Y (returns 0-63)
Modulus "^" is the remainder after a division.
1874
« on: March 06, 2010, 02:12:46 pm »
I found the annoying mysterious bug!
Apparently, as the assembly executable is being written and expanded, the other programs in the VAT start moving around to make room for it. Sometimes, the source file is one of those files which means that the location it was reading from suddenly switches to some other program or random garbage. I tried to make it use the symbol table to keep track of the pointer instead, but it turns out even the symbol table rearranges itself. So I have no idea how to fix this. I remember there was a bcall called "EditProg" or something that was supposed to allocate the program so that things don't switch around, but I was never able to get it to work. Do any of you assembly programmers know how it works or another way around this?
1875
« on: March 06, 2010, 01:57:59 pm »
If your pics are in order, you can do "C*8+Pic0" and it will be the same as "PicC"
Pages: 1 ... 123 124 [125] 126 127 ... 135
|
Show Posts