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 - m1ac4
Pages: 1 ... 3 4 [5] 6 7 8
61
« on: April 15, 2011, 07:42:41 am »
Non-Basic game for the Prizm! Who knows where this kind of thing can go. Good job  Now I am once again addicted to minesweeper. Except now I won't ever be able to get away from it, ever. 
62
« on: April 15, 2011, 07:29:49 am »
I might buy a CX eventually just to say I have one but I'm quite content to stay with the Prizm. In fact, I will stay with the Prizm (but I'm glad to see some real potential with the CX).
63
« on: April 13, 2011, 07:35:51 am »
Could this idea be applied to the Prizm too? You said that the language might be able to be extended by this method. It would be possible to create create/modify commands to draw objects to VRAM and create another command that would update the screen, allowing really fast screen updates to make fancy Prizm Basic games possible.
64
« on: March 29, 2011, 07:41:29 am »
Some variations found on Wikipedia:
sexatrigesimal
hexatrigesimal
65
« on: March 29, 2011, 07:36:04 am »
Or both 
66
« on: March 29, 2011, 07:30:57 am »
Thanks. However, my question was more to do with regression calculation copying than with simply putting an equation into the Y= editor. If you calculate a regression in statistics mode you see the results plus the option to copy the equation to the editor by pressing F6 and selecting the equation. This works fine outside of a program but I have no idea how to do it this direcly inside of a program. Unless found otherwise, I will have to manually store the generated coeffecients to some variables and then insert the equation (something along the lines of "Ax+b", "Ax2+bx+c" ect.) with the method that you have described.
67
« on: March 28, 2011, 07:44:28 am »
That's definitely a better MP system than before. By the way, what could you possibly do if you were to get to Lv. 100 have approximately 1000 MP? At the moment that seems like a lot so I assume that you will create some incredible magic attack for that right?
68
« on: March 24, 2011, 08:44:27 pm »
I just tested it out with a calc that I "borrowed" from a friend. This is the first time I have touched a TI calculator in several months and for the brief amount of time that I was on I was astounded by the sheer fact that I was using my (brother's) calculator on the internet. Its this kind of thing that really makes using calculators exiting. Fantastic job to all who are involved. 
69
« on: March 24, 2011, 07:44:05 pm »
Since DJ asked, I retrieved the code from my calculator and documented it. Keep in mind that I ripped some of this out of larger programs but the complete routines are included. Any advice that you can provide would be most helpful in helping me become a better Basic programmer so feel free to provide it if you wish. Thanks in advance.
70
« on: March 24, 2011, 07:21:50 am »
It's nice to see some more development on the Casio side as well. Thanks!
Edit: The Casio Prizm discussion link on the main page still links to the Casio Prizm Hacking discussion page. Can someone link it to the Casio Calculator Programming and News board directly?
71
« on: March 23, 2011, 09:58:01 am »
I think that the StrMid( command would be the equivalent. Syntax would be StrMid(string,index,length)
@DJ_O: I timed decompression with a stopwatch and it comes out to approximately 3 seconds (I really need to stop observing the run indicator as a timer since perception can be inaccurate). I can get the source code off of my calc but I don't have the time at the moment (school) and I need include a short explanation with it too.
Edit: I had considered using strings but I have never done this before and I wanted to try storing the data in a separate list file to attempt to prevent the average user from accidentally corrupting it. I'll have to look into using strings at another time.
72
« on: March 22, 2011, 07:41:47 pm »
My estimate for what I did would be about seven seconds to compress and two seconds to decompress. In this case that delay time is reasonable (drawing the tilemap to the screen takes just over 10 seconds because of the Locate command).
I think a two second lag time to decompress is worth saving around 80% of space in what I am doing.
73
« on: March 22, 2011, 06:31:36 pm »
I am curious how far we'll be able to push the Prizm when display routines like IonFastCopy are written.
Imagine actually being able to use real color textures in a 3D engine. Its kinda hard to distinguish texture in 4-color greyscale but imagine being able to use real color texture in a game. If you can get a routine to work fast enough then you can produce some amazing games with just that alone. Personally, I can entertain myself for a long time just by staring at the bouncing rectangles. Imagine what games developed later on would do.
74
« on: March 22, 2011, 06:24:11 pm »
A concept game I am working on uses both lists and a matrix for tilemapping. The matrix is 7x21 to represent all of the tiles you can have. I use a list to store the map data. Using RLE compression and compressing that further by storing data for two instances of tile and repetition in a single list element, I can generally achieve at least 70% compression. So to answer your question, using a matrix for uncompressed data would be good but since you are dealing with 147 real #s you would want to compress the data to store it.
75
« on: March 17, 2011, 09:56:56 am »
 In that case, I'll just have to store the coefficients to some variables and work with that to get what I want.
Pages: 1 ... 3 4 [5] 6 7 8
|
Show Posts