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 - Xeda112358
Pages: 1 ... 139 140 [141] 142 143 ... 317
2101
« on: March 16, 2012, 08:03:22 pm »
I bet if I play as X, I can beat it 
2102
« on: March 16, 2012, 07:30:10 pm »
I am working on my TIConcours entry (the SNAKE program) so I backed it up earlier. I sent it to the computer and that worked fine, so my entry now has a backup on the computer. However, I tried sending it to Wabbit so that I could look at it and at my calc while programming similar sections of code. That failed. So I tried sending another file. That worked! So then I tried resending the other program and again, it failed. So, I renamed it on my actual calc, resent it to my computer, and it sent it to Wabbit just fine.
Later, I decided to back it up from my TI-84+ (OS2.40) to my TI-84+SE (OS2.43). I got a Version error. So I tried sending another program. That worked just fine. I tried to send my snake program again and it failed.
So, what I am thinking is that the OS bugs out on the name. Unfortunately, I cannot give the last two bytes of my program name (it is an ID for the contest). However:
The name starts with Theta followed by SNAKE and then the ID number. This is a total of 8 bytes. Does anybody know what is wrong?
2103
« on: March 16, 2012, 06:49:11 pm »
Yep  And nice rhyme!
2104
« on: March 16, 2012, 05:06:14 pm »
Yeah, I know, and rounding will indeed throw it off. So does it round when you divide or when you tell it the coordinates. If it is at the coordinates, then there should be a command called int( or floor(, I am assuming. You will want to use that on the coordinates.
2105
« on: March 16, 2012, 05:01:17 pm »
Ooooh, so the code will round. I did not know that. Is there some way to prevent it from rounding?
2106
« on: March 16, 2012, 04:56:22 pm »
Ah, okay. No, I wouldn't even know where to begin, sorry.
2107
« on: March 16, 2012, 04:44:17 pm »
My Snake game is now basically working at under 2000 bytes (it is between 1500 and 2000). My snake now grows when it eats a fruit, there is collision detection, several speed modes, scrolling map, and a few other secrets >.> I still plan to add more
2108
« on: March 16, 2012, 03:21:51 pm »
My snake game might still not be finished by the time it has to be turned in  I also just changed some spots of code to more optimised hex and took out 100 bytes and made it much faster o.O
2109
« on: March 16, 2012, 02:23:31 pm »
I've no clue how to approach this  Does the NXT natively support grayscale? If not, how easy is it to do bitwise logic?
2110
« on: March 16, 2012, 02:20:58 pm »
I started my snake today, I already have the playing area scrolling nicely on 256*386 pixels It has the fruit things and now I need to add back in the snake part  I made the two sections separately-- the snake code and the map scrolling code.
2111
« on: March 16, 2012, 08:52:42 am »
* Xeda112358 knows persalteas' BASIC graphics skills and cannot wait to see  My Tic-Tac-Toe also has AI and simple graphics. I have been debating adding a more difficult AI mode, but now I think I must Already, the AI is smart enough to block moves and make wins, but it still isn't the best. I designed an algorithm last year that I have never programmed, but it is fast and will be nearly impossible to beat with X as the AI.
2112
« on: March 16, 2012, 08:45:43 am »
But you also can't have them as a source subprogram?
Apparently not However, you can do what Deep Thought is doing and you can design it with source subprograms, but just include it all in one program when you submit it.
2113
« on: March 16, 2012, 08:42:13 am »
Here is another method I have been discussing quite often over the past few days and made an example of. It is what Quigibo mentioned in his last few lines, so here is what it looks like... If you have room for another buffer, you will want to draw sprites twice-- once on the viewable buffer and again on the "collision" buffer. For example, if I draw this sprite on the buffer shown on the LCD:  Then I want to draw the hit-box region on the other buffer:  Now all you do for collision is pxl-Test( on that buffer. So here I will pause to explain why this is better: Say you have a huge monster or kill zone that is like a circle bigger than your sprite. Now say you go inside that area and pixel test for collision-- you will get nothing. However, with that idea above, you will just fill in the hit region with pixels on. This method can also be applied to creating several layers such as a collision buffer, killzone buffer, warping buffer, et cetera-- and it works quickly. Also, there are times where you will want a collision zone that does not necessarily have pixels shown. Since the other buffer is not displayed, you are fine Finally, here is an example (sorry, it isn't in Axe, but it is the same concept): 
2114
« on: March 15, 2012, 10:03:34 pm »
Yes, that is a great way and, also, enemies you just do by drawing their sprites to the layers.
2115
« on: March 15, 2012, 09:27:25 pm »
I am now back and have not had time to work this out, yet. (Also, I am distracted on the phone  ) Still, I will try to figure this out <.< As for limitations, all I can think of is memory. For systems with color screens, this is an extremely good system to use as you can generate scrolling maps easily and pack a few layers into each pixel.
Pages: 1 ... 139 140 [141] 142 143 ... 317
|
Show Posts
