I'm currently making a tetris game that uses complex numbers to store piece positions. For example:
16.06+20.06i
20.1+24.1i
Means that there are cells (cells=parts of pieces) at (16,-6),(20,-6),(20,-10),(24,-10).
Note that y-coordinates are negative and i's in complex numbers are ignored.
The problem: This system makes rendering extremely fast and efficient, but makes rotating a piece when [/\] is pressed quite difficult. I've tried every approach I can think of. This is the code I have so far. Var A contains data for two cells, and Var B does also.
Code: :real(a)+100(fpart(real(A))-fpart(real(b)))+.01(ipart(real(A))-ipartipart(real(B)))+i(real(A)+100(fpart(real(A))-fpart(imag(B)))+.01abs(ipart(imag(B))-ipart(real(A->B
:real(a)+i(real(A)+100fpart(imag(a)-real(A))+.01ipart(imag(A)-real(A->A
The way this is supposed to work is by leaving real(A) alone and using it as a reference point in calculating the positions of the other three cells.
Any suggestions?
Well it's beyond me but perhaps I might offer a suggestion. Maybe put the thing in some sort of loop, and make it do whatever you need using If...Then looops??? Like:
If k=24
1->A ....
If A=1
Then
Quote:
Code:
:real(a)+100(fpart(real(A))-fpart(real(b)))+.01(ipart(real(A))-ipartipart(real(B)))+I(real(A)+100(fpart(real(A))-fpart(imag(B)))+.01abs(ipart(imag(B))-ipart(real(A->B
:real(a)+I(real(A)+100fpart(imag(a)-real(A))+.01ipart(imag(A)-real(A->A
End
I'm offering something. Better than nothing right...
seems similar to the problem I had with my maze engine. let me know if you get it worked out
Aye, me too. I could ponder that a bit if you want.
It works perfectly except for one piece. When I switch it it transforms from a left-biased parallelogram to a square. I thik it has something to do with how I format the pieces, but I have tried every other way and i get the same, if not worse, results.
By the way, I would reccomend not using complex numbers, because they are much slower.
They're slower, but they sure do well halving the number of variables you have to juggle.
KermMartian wrote:
They're slower, but they sure do well halving the number of variables you have to juggle.
lists cut it down even more
Eh, but real lists are roughly the same speed as complex variables.
Jonathan_Pezzino wrote:
By the way, I would reccomend not using complex numbers, because they are much slower.
Real variables are to clunky and mem-consuming, lists are too slow, matrices are too hard to render efficiently, and I don't know ASM. I don't see another good way to do this besides complex numbers.
Sounds to me as if the solution there would be to learn ASM.
Yeah, except that I'd like to have this released by mid-March, and it will take longer than that to learn asm.
Maybe someone should make a complete tutorial focusing on Ion/Mirage Asm. Asm just seems so much easier when using those libraries (especially the sprite routines).
*sigh* It's just a matter of calling those...read the spec sheet at the end of the DCS sdk. It's not actually a different kind of programming or anything.
Just a harder kind of programming.
? No, it's actually easier, because you don't have to worry about writing those routines yourself...
True, it is easier in that regared. Just the code always seems opaque at first glance and that makes it seem hard.
Initially you can just assume they work and use them; eventually you can go back, look through them, and try to understand the generally excellently-written code they contain.
Where do they publish code for rom calls? I haven't seen them on TI's site.
Kuro wrote:
Where do they publish code for rom calls? I haven't seen them on TI's site.
They never do. Those are copywrite by TI and there's no way they'll ever give out the source. They even get antsy when people write clones of the routines.