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 - theUnnamed
46
« on: April 18, 2010, 08:12:08 pm »
The unfortunately down side of builder boy leaving me in the dust is that I was using the competition as motivation and cause he finished so fast I no longer have as much motivation.
I also must note to builder boy that your codes wall time (actual execution time) is in fact not the ultimate determinate of programs quality this case as long as your code can respond and change everything in <1/60 of a second it doesn't matter how quick you do things with in that so the real challenge is to make an appearance of faster running not a straight up faster running piece of code. if it's impossible to do a full render do as close as you can and clean up next frame. that is the key to making the game look better.
we are look at run times in the 1/1000 of a second range. One must realize that you can do quite a bit in 1/60 of a second.
there is a definite place for interlacing and the like.
47
« on: April 18, 2010, 07:41:24 pm »
The N-spire OS resides in Ram, nucleus I do not believe has any transitive code although the app side likely does not at all time. but that's irrelevant because that is not a measure of RAM usage that is a measure of "archive" which is used in the N-spire like a disk.
So net result that is a measure of space in file system not RAM.
Additionally the OS is not TI-OS its Nucleus OS. TI used an outside OS and just wrote apps that nucleus runs. (using a dll like system)
We are no longer in the realm of processor, screen/keyboard, and memory and into the world of kernel, device drivers and file system.
48
« on: April 18, 2010, 06:55:18 pm »
49
« on: April 17, 2010, 10:47:22 pm »
I'm proud to report that my optimization efforts are going well even though I don't understand how half the code works but then again my current optimization is much like peephole optimization and function in-lining thous far but it seems to have had some inpack thous far I'm going to upload a copy for people to play with tomorrow. please make sure I didn't break anything.
50
« on: April 17, 2010, 10:31:04 pm »
in the older version of the OS (by older I mean really old) I got better performance with the matrix method.
also your testing procedure is flawed you forget that variables can store complex numbers so your "access time" difference is not dew to the difference in access time but dew to the fact that it has to do a complex number addition instead of an real number addition. which in fact takes longer because its doing 2 floating point adds which on the z80 are the slow step of that line of code.
I have no Idea how to test this and I currently am using a N-spire emulation for my 84 so I can not truly accurately test this because the emulator runs on an OS that is not nearly as constant in runtime as the real 84+ is also you should try changing the top line to
:starttmr->A
:While not(checkTmr(A
:End[and the last line to
:CheckTmr(A+1)/Fthis allows for a more consistent start time within the clock cycle.
and yes matrix access is slower...
in a loop because of parse time of the index but when in a seq( command it's just as fast if not faster because the interpreter only parses it once and then executes the entire seq( statement.
51
« on: April 17, 2010, 09:35:59 pm »
@theUnnamed
Just a little tip is that BBCode doesn't work inside of the [code][/code] command, such as your subscript commands. Just thought I'd let ya know 
I realize this now
52
« on: April 17, 2010, 08:37:38 pm »
I do realize that Iterating a loop takes time but I do not think you realize how for loop iteration is done in TI-basic or how much faster variable resolution is then number resolution. In TI basic the varibles a-z and Theda are indexed using an array and the calculator doesn't have to do anything more then *(arry_ptr+var_name-'a') to retrieve the value. where as the resolution of a number is a far more complex task because It has to do a conversion form a char array to a float which If you've ever implemented that in c is not pretty and a rather complex loop even when optimized. additionally for loop end values,increments and a pointer to the line immediately following the for( statement is cashed on the stack making the incrementing and checking of for loop conditions a trivial amount of time because no interpretation is ever done if you need proof of this fact try this:
:1->X
:0
:For(X,1,100,X
:Ans+1
:End
:Ansif the interpreter reinterpreted this loop each time conditions were checked the loop would run only 8 times but instead it runs 100. therefore it must cashe the value of the inc as of the time the loop starts and use that. This also explains the weird discrepancy in behavior of the for and while loops but I digress.
here is my strategy for detecting coalitions, row eliminations and full row detection a matrix of size board width+2 by board height+1 this seems like a crazy waste of memory but makes collision detection, row detection and row moving faster.
first step is the pregame setup
you set up your matrix like this (for your 10X16 board)
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,1,1,1,1,1,1,1,1,1,1,1
now checking for a collision become a single short line (assume L1 to be x coordinates and L2 to be y coordinates)
0=sum(seq([B](L[sub]1[/sub](i),L[sub]2[/sub](i)),i,1,4there is no argument that this will woln't execute faster then your check condition because it runs far faster (like half the time if i remember correct)
once the final placement of the block is determined do this:
:For(I,1,4
:L1(i->X
:L2->Y
:1->[B](Y,X
:[B](Y,X-1->A
:[B](Y,X+1
:Ans+A+1->[B](Y,X+Ans
:Ans->[B](Y,X-A
:End
:clrlist L3
:For(Y,min(L2),max(L2
:If 12=[B](Y,1
:Then
:Y->L3(1+dim(L3
:mRow(0,[B],Y
:1->[B](Y,1
:Ans->[B](Y,30
:End
:End
L3 now contains the rows that must be eliminated and they be have been reset to [1,0,0,0,0,0,0,0,0,0,0,1]
you can then use row the row swap command to move the line down. then you update the screen but I forget how I did that quickly right now so I'll get back to you when I remember.
YOU CANNOT TURN THE MATRIX to make the index order constant with that of the pixel drawing proceedure or you lose the fast row elimination.
53
« on: April 17, 2010, 06:51:24 pm »
looking at your code It is far more brute force than my design which tries to minimize interpreter parse time by employing lists as much as possible. I also keep an index of the board in a matrix in the background which is what takes up the most memory because i found that it was very slow to test the pixels on the screen. I found a nifty way of making line elimination detection really fast. and my original version made an effort to reduce flicker of the blocks by pre-calculating the shift and only changing the pixels that absolutely had to be changed. As you can tell my design is far more complicated then yours. I guess I got so wrapped up in optimization that I neglected to take the simple approach. I don't understand is how you are doing a few things:
controlling the speed of block falls
removing lines
generating block patterns
54
« on: April 17, 2010, 06:32:36 pm »
That's really neat That's better way then line(0,0,1,1
55
« on: April 17, 2010, 05:54:47 pm »
Ok I guess I continue my development of my tetris Unfortunately life decided to chop up the coding time I expected to have I like you tetris design. and what augments of point-on give u 3x3 block manipulation? I didn't no such a thing existed
56
« on: April 14, 2010, 04:14:08 pm »
I was going to write a CAS in C for the Nspire, but I couldn't find any input or output functions 
That sucks you would definitely get better performance out of a CAS in C hell you wouldn't even need to write it you would just need to build a lisp interpreter and front end for Maxima. And lisp is easy interpretation.
57
« on: April 14, 2010, 03:40:02 pm »
Woot so i already have the entire engine finished, what was the dimnensions that you required? Traditional 10 wide and about 15 hight?
I'm doing is as a 16 wide by 32 high board because that's what looks about right to me on the screen. How much time did you have to devote to this. I have only had like 15 min to work because of high school. I honestly didn't expect anyone to do it this fast. So here's the question does your program use anything that doesn't come on the calculator when it was sold because that's what I meant by in TI basic (no faster OS or interpreters allowed) and how quick does it run? and finally how did you code it. here's my interface designs 2x2 pixels to tetris block
58
« on: April 14, 2010, 06:38:47 am »
That post seems vaguely familar
59
« on: April 14, 2010, 06:36:13 am »
I would say that's a different engine but much of the code could be reused.
60
« on: April 13, 2010, 11:47:05 pm »
I think I'm going to modify the competition slightly for fairness. I'm going to build a piece of code that sets up the board layout (meaning the visual background that never changes like the sides of the tetris board and the next block box) and post I all contestants will start building code then.
This will not only give a completely level playing field as far as code complexity is concerned. It will also give people some time to think about how to implement it thus taking away some of my advantage of already having run into most of the problems. This program really takes a lot of thinking out side the box even though it seems simple the amount of memory you have to work with coupled with the time restraint of it having to be responsive and not take a long time to index itself so it can implement a simpler inner loop makes it more difficult then it first seems.
I hope to have the board setup program up by Friday
|
Show Posts
