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 - Happybobjr
Pages: 1 ... 89 90 [91] 92 93 ... 166
1351
« on: December 25, 2010, 07:11:49 pm »
Thank you ! Now i have to finish linked multiplayer. It will be a bit slower than on-calc multiplayer, but that'll be fun  . I just need mighty moose to test the first playable version.
i have 2 calcs at the ready if you want me to test.
1352
« on: December 25, 2010, 06:59:20 pm »
ok, could i edit the code to have rotation? If you want to see the Axe version I made a while back, you can download the source code here but it doesn't have rotation. One confusing optimization that programs like these use though is to remove the multiplication in the main loop and replace it with an addition.
1353
« on: December 25, 2010, 06:44:57 pm »
can we see the program you used for 
1354
« on: December 25, 2010, 06:28:25 pm »
can you give me a small code example of a small mode 7 screen or something?
1355
« on: December 25, 2010, 06:22:01 pm »
Is that what you used on your sorry, but that doesn't have enough info. How would i make it?
1356
« on: December 25, 2010, 06:01:23 pm »
ok, so i read wikipedia's thoughts about mode 7 and i am even more confused.
can someone explain this please?
mostly about the matrices.
"Planar texture maps using Mode 7 graphics are generated by transforming screen coordinates to background coordinates using a 2D affine transformation,
umm??? VVV
\begin{bmatrix} x' \\ y' \\ 1 \end{bmatrix} = \begin{bmatrix} a & b & x_0 \\ c & d & x_0 \\ 0 & 0 & 1 \end{bmatrix} \begin{bmatrix} x - x_0 \\ y - y_0 \\ 1 \end{bmatrix}
where a, b, c, and d are the transformation coefficients; x and y are the screen offset; x_0 and y_0 are the origin offset; and x' and y' are the transformed coordinates. All arithmetic is carried out on 16-bit signed fixed point numbers, while all offsets are limited to 13 bits. The radix point is between bits 7 and 8.
Affine transformations only allow for displacement, scaling, and shearing effects. Many games create additional effects through creative manipulation of the transformation matrix parameters on a scanline by scanline basis. In this way pseudo-perspective, curved surface, and distortion effects can be achieved"
1357
« on: December 25, 2010, 10:58:31 am »
 I like knowing with more precision,
1358
« on: December 24, 2010, 09:35:44 pm »
no, I mention it on 1st page.
It causes a crash whenever you use the Send( command.
1359
« on: December 24, 2010, 08:47:19 pm »
do you have a cord?
note: DO NOT USE ON NSPIRE!
1360
« on: December 24, 2010, 08:33:42 pm »
Update: Perfect Syncing now.
no known issues except for inconstant speeds.
1361
« on: December 24, 2010, 08:20:56 pm »
I think that the best way to make a game slower is to embellish it. If you have a lot of processor power, don't waste it with Pause commands or whatnot. Make your game look better. Put in some nice looking grayscale or something!
But yes, if you are looking to save power, then I don't know how to help you. I don't think it can be done, unless you want to lower the contrast on the calc automatically (that should lower power consumption). The battery life on those things lasts for about a year anyway. AAA batteries aren't that expensive.
when you start programing on your calc 24/7 you will see a major decrease in its life. I occasionally leave it running for an hour to test the speeds of different commands.
1362
« on: December 24, 2010, 08:09:43 pm »
the peanuts are an old meme. We always love to see new members. Are you an axe programmer, ti-basic programmer, or asm programmer? (for calc.)
1363
« on: December 24, 2010, 11:51:33 am »
This looks great. I didn't ever bother to find out what correlation was by reading through 100's of posts.
I shall be using this.
I can see many ti-basic games being redone using this.
1364
« on: December 23, 2010, 06:21:43 pm »
According to Quigibo it's about the same speed as just DispGraph, so you're saving all the time it takes to clear the graph buffer.
Seems like a useful command  I was just about to ask for DispGraphrClrDraw/DispGraphrrClrDraw, but then I realized how pointless it'd be (there'd be no grayscale anyway if you're clearing it every pass).
why wouldn't there be?
1365
« on: December 23, 2010, 04:41:20 pm »
New feature added:
DispGraphClrDraw
When used on the same line without a colon or newline in-between, it will function exactly as if you had done DispGraph:ClrDraw but it does them both simultaneously so its just as fast as if you had used the DispGraph by itself. Its great to squeeze more frame rate out of games where you have to clear the screen after drawing each frame like for instance; ray-casters. But I'm sure this can be used in may games. Keep in mind this does add an extra routine to your code so I would still use the regular DispGraph unless you can use the new command exclusively or if you really need more speed.
love it, that will be great.
Pages: 1 ... 89 90 [91] 92 93 ... 166
|
Show Posts