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 ... 117 118 [119] 120 121 ... 153
1771
« on: November 10, 2010, 05:24:48 pm »
The signed division auto optimizations are gone  EDIT: Also, sprite routines targeted to arbitrary buffers reverse the x and y arguments. EDIT 2: Oh, and in the commands list you accidentally call EXP1**EXP2 signed multiplication instead of fixed point multiplication.
1772
« on: November 10, 2010, 02:38:37 am »
Signed greater than comparison: p_SIntGt:
.db 13 ;13 bytes, 48 T-states
ex de,hl
xor a
ld b,h
sbc hl,de
ld h,a
rra
xor b
xor d
rlca
and 1
ld l,a | | p_SIntGt:
.db 12 ;12 bytes, 67 T-states
ld bc,$8000
add hl,bc
ex de,hl
add hl,bc
xor a
sbc hl,de
ld h,a
rla
ld l,a |
You getting all this Quigibo? 
1773
« on: November 08, 2010, 10:45:33 pm »
I believe fixed point multiplication and sprite rotating/flipping are both outdated, as well.
1774
« on: November 08, 2010, 06:20:50 pm »
The reason TI is jacking up the price of the 83's and 84's is because they want their new product, the Nspire, to sell more. By increasing the price of 83's and 84's, they are effectively trying to force people to buy Nspires by making the old and less capable models unreasonably expensive in comparison. By then having more sales of the Nspire, TI hopes to spread its influence and eventually have it replace 83's and 84's. At this point, when Nspires become the new standard for graphing calculators bought by every new high school student, they could even decide to increase the price more and get away with it.
1775
« on: November 08, 2010, 05:52:55 pm »
Oh cool, thanks. So I'm guessing that the lack of an argument inside the {} is because it is taking HL as its argument, which is 'pointer' because when you store pointer to r2 it is stored to HL....like ans....kk i'm learning 
Does every Axe operation leave stuff in HL?
Every loading or mathematical operation will put the result in hl. As I mentioned to someone a while ago in a different thread, the hl register is like the "Ans of Axe." All loading operations put the value into hl, and all mathematical operations put the operands into hl and de, calculate, and put the result back into hl. The nice thing about this method is that complex strings of operations can be handled easily. If parentheses or curly brackets are reached, the current value of hl can just be pushed onto the stack for later, and any operations in the parentheses or curly brackets can then be handled using hl. Every time the "depth" of the operation is increased, hl just needs to be pushed, and every time the "depth" decreases, hl can be popped right back. Note: Just in case anyone reading this doesn't know what pushing and popping are, they are methods of saving and restoring data (respectively). Pushing loads a value onto the top of a stack of values, like a stack of physical objects. Popping takes the top value on the stack and retrieves that. Using this method, you can push multiple values onto the stack and retrieve them in the opposite order that you put them there, allowing things like parentheses to be handled very well. It's explained quite well here.
1776
« on: November 08, 2010, 05:45:48 pm »
Here's the most optimized way, using standard subroutine calls, to either set or reset a bit of a pointed to byte, with bit 0 being the most significant bit. Input would be in the form of sub(SET/RES,bit,pointer).
Lbl SET
{} or sub(BIT)
Lbl SR2
→{r₂}
Return
Lbl RES
{} and (sub(BIT) xor ᴇFF)
Goto SR2
Lbl BIT
e^(7-r₁)
Return
1777
« on: November 08, 2010, 03:47:58 pm »
General form: {Pointer}Asm(CB XX)→{Pointer}, where XX is a byte from the following table. In this table, I call bit 0 the least significant bit and bit 7 the most significant bit. | RESET | SET | | BIT 0 | 85 | C5 | | BIT 1 | 8D | CD | | BIT 2 | 95 | D5 | | BIT 3 | 9D | DD | | BIT 4 | A5 | E5 | | BIT 5 | AD | ED | | BIT 6 | B5 | F5 | | BIT 7 | BD | FD |
1778
« on: November 08, 2010, 03:29:43 pm »
I found a bug (I think) :
When I compile this code in Axe 0.4.4, it work :
:!If EXP1
:.Code
:ElseIf EXP2
:.Code
:End
But in 0.4.5, I'm obliged to do that :
:If EXP1=0
:.Code
:ElseIf EXP2
:.Code
:End
This is due to ERR:BLOCK when I compile.
I have noticed this too, this problem isn't just you.
1779
« on: November 08, 2010, 01:41:35 am »
The old engine only scrolled 1 pixel per frame, so it got 60 fps, but therefore it only scrolled 60 pixels per second. Behold, the new engine that can scroll an arbitrary number of pixels from 1-8 per frame! In the example screenshot (which probably looks like crap and doesn't accurately reflect the realistic performance) I'm scrolling 3 pixels per frame (controlled by the value of S set in the program) and get about 35-40 fps, giving scrolling rates of 100-120 pixels per second!
Also, with the old engine I didn't realize how interested people would be in this so I didn't bother to optimize it much. This time I went ahead and optimized it to the fullest of my abilities.
1780
« on: November 07, 2010, 11:02:35 pm »
DOUBLE EDIT:0→θ, eh? so answer isn't carried from if statements. i should really learn the syntax BEFORE messing around with a code.
The answer is carried from if statements, but that was an !If statement which activates when the expression following it equals zero, so zero carries to the next line. Wow, you're source is wonderful. I like the optimizations... wow... 
I must learn to code like you in Axe! 
I've been debating making a super-optimization guide for Axe. Should I? I wonder if this can be modified to scroll in arbitrary distances... (up to 8 pixels of course)
I'll try my best
1781
« on: November 07, 2010, 09:07:23 pm »
This isn't a project or anything, I just whipped this up as an example in all of 30 minutes or something.
1782
« on: November 07, 2010, 08:28:55 pm »
:!Ifθ+1→θ-10
:→θ
so... if, after being incremented, θ=10 then 1→θ?
runer, your optimisation is incredible.
Increment θ, and then if it equals θ=10, then 0→θ
1783
« on: November 07, 2010, 07:41:14 pm »
I didn't comment it much, but hopefully it's still understandable. If not, just ask me about it.
1784
« on: November 07, 2010, 06:47:24 pm »
Some notes about this test program: - It uses a 32x32 tilemap, with each tile being 1 byte. For testing purposes, the value of each tile is the sum of its x and y positions in the tilemap.
- For testing purposes, each tile is an 8x8 tile displaying its base-10 tile number with the left half (tens digit) inverted.
- Arrow keys to scroll, CLEAR to quit.
EDIT: By the way, sorry if the lowercase comments don't look right. I wrote this program with TI's Program Editor, which turns any lowercase letters that are also statistics variables into those special tokens instead of just treating them as lowercase letter tokens.
1785
« on: November 07, 2010, 06:24:24 pm »
My program only draws tiles as they scroll onto the screen. That means it's drawing at most 13 8x8 tiles per frame. This means you couldn't have animated ground tiles, but it would work great for static ground tiles. It could also be easily extended to working with grayscale tilemaps.
Pages: 1 ... 117 118 [119] 120 121 ... 153
|
Show Posts