### Show Posts

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.

### Topics - sjasogun1

Pages: [1]
1
##### Other Calc-Related Projects and Ideas / Compressing maps
« on: March 27, 2013, 09:47:26 am »
Most people who program games on their calculator have encountered them: maps. They can take many shapes, sizes and forms, but they always have one thing in common. They occupy a lot of memory. Now, I think I have found a solution to this problem or at least an improvement from the current situation. It mainly revolves around using Matrices to store variables for 2D maps in.

Normally a matrix is very handy for storing numbers in that represent something on the map without having to worry about storing the coordinates for you since matrices have the coordinates built into them. The problem is that matrices tend to take up a lot of memory as they get bigger. For example, on my calculator, an fx-9860GII, a small 10x10 matrix takes 1236 bytes, and a 7x21 matrix that has the dimensions of the screen as far as ASCII goes takes 1800 bytes. And that is just a single matrix. A game will need many more to be of any use as a single screen-sized level won’t allow you to make much of a game that actually needs maps. Storing it in an array doesn’t make any difference either: it still takes 1800 bytes on my device (though it may save you a little bit on another device).

The solution I propose is as follows. You start by generating a list of prime numbers. You probably won’t need much more than 10 for simple maps that only include walls and have the exit hard-coded into them (meaning it is represented as an ‘empty’ square in the matrix but the code has something happen when the player stands on the spot where the exit is), but for maps that have more features on them you’ll need to generate more prime numbers as well (how many exactly will be detailed further in the explaination.)

Now, start by making yourself a map, probably something simple like a maze because you only have walls to work with for now. Put 1 in the matrix for any empty square and the first prime number on your list, which should be 2 if you did it correctly, for any wall. The reason for not using 0 as the 'empty' squares will become obvious in a minute. Now we have our first map. Nothing much, right? A player should be able to solve this maze in well under a minute. So, we’ll need more mazes. But instead of making another matrix to store the next maze in we’ll store it in this one, without changing it dimensions.

To do this you take your list of prime numbers. The first prime number is 2, but we already have 2 in our maze. So we’ll start with the second prime number: 3. Now, to make the process of making the new maze easier make yourself a new matrix. Make another maze of the same size as the previous one here, but this time use 3 for the walls instead of 2. Empty squares are still 1. Now, when you’ve finished, you multiply each square in the matrix with the matching square in the other one. So, you multiply A[1,2] with B[1,2] and A[5,12] with B[5,12]. This multiplication is why empty squares shouldn't be 0; multiplying with them would always give you zero. Before you start the multiplication, there is one important precaution to take: multiplying each square in a matrix with its corresponding square in another matrix is not the same as multiplying the two matrices. You’ll have to write a double loop in order to get the multiplication right.

Now, you end up with a matrix that looks like garbage. It has 1,2,3 and 6 scrambled all over it. The trick is that this matrix contains both of the original maps. Extracting them goes as follows: If you want the first map you take the first prime number (2) and go over each square of the combination matrix to see if the number in that square is divisible by 2. If so, count that square as a wall. If not, count that square as an empty square. If you draw the result on the screen you’ll see that it has produced your original maze again. You can extract the second maze in the same way, with the difference that you’ll take the second prime number (3) as your divisor. You can make many more mazes and multiply the squares in them with those in the combination matrix to store them all in the same one, going over the rest of the prime numbers. So 5 will be the wall in the third maze. 7 the wall in the fourth maze, 11 the wall in the fifth maze and so on.

This neat little trick makes use of one of the useful properties of prime numbers: every number has a unique set of prime factors. This means that if you take a random number like 59175839719 and figure out how to divide it into prime numbers there will be no other product of prime numbers that will produce the same number. In the compressed matrix this is easy to see. No prime number is divisible by 2 except 2 itself since the basic definition of prime numbers is that they can only be divided by themselves and 1. So, only the squares that were labeled with 2 in the first maze will ever be divisible by 2 since we only multiply by prime numbers. The same goes for all of the other prime numbers we used.

The only downside of this technique is that, in its current form, it only works for maps that have only two different kinds of squares: empty ones and walls in this case. There is an easy way to add more types of squares to the map though: simply skipping prime numbers. For example, in the first maze you’d use 1 for empty squares, 2 for walls, 3 for pitfalls that put you back a level and 5 for invisible walls. In the second maze you’d then use 1 for empty squares, 7 for walls, 11 for pitfalls and 13 for invisible walls. The only downside of this is that you need more prime numbers for more different features in your maps, scaling linearly for the amount of features. 1*10 prime numbers will allow you to make 10 maps with 1 feature (walls), 2*10=20 prime numbers will allow you to make 10 maps with 2 features (walls and pitfalls) and 3*10=30 prime numbers will allow you to make 10 maps with 3 features (walls, pitfalls and invisible walls). Luckily this only scales linearly so adding a feature will only add as many prime numbers as you want maps. Another advantage is that arrays (called Lists on my fx-9860GII) and matrices will usually reserve the same amount of memory for every element: enough to hold a number up to 9.99*10^99. This means that having a value like 6469693230 in your matrix (the product of the first 10 prime numbers) in your list won’t take any extra memory, effectively making the limit 53 prime numbers (after which the combined product of them, which is the worst case scenario, exceeds 10^99). Of course, this limit only applies to maps that only use walls: in maps with two features 2 and 3 can’t be multiplied, nor can 5 and 7 or 11 and 13, thereby raising your limit to 91 primes (took me a while to calculate that ). The limit to the amount of maps you can make does shrink as you add more features (from 53 to 45 in this case) but it won’t shrink too fast, especially not when you consider that adding more features gives maps potential to be harder thus requiring less to make an interesting game.
Also, if you need to store more maps you can simply make a second matrix in which you can re-use your prime numbers to store even more maps, thus reducing your memory load by a factor of 30~50, depending on the amount of features you add (not 30~53 as the code for generating primes, the storage for the primes and the code for extracting a map all take extra space as well, but not much and the 'memory reduction factor' only increases as you add more maps).

I hope you all like my idea and can put it to some use!

2
##### Casio Calculators / Unsendable data items
« on: January 23, 2012, 01:56:31 pm »
I posted this before in the 'Getting started in Casio Basic' topic but since this isn't really on a 'getting started' level I decided to make a seperate thread.

In the guide of the Casio fx-9860 GII I found a list of data items that can be sent over communications. In regards to my previous question (in the Getting started in Casio Basic topic) a data type that is missing from this list could be used to contain a unique password of some sort. The problem is that I haven't found any data types not present on this list. But since there is a list in the first place I am sure they must exist. Do any of you see a data item missing from this list?

Spoiler For Spoiler:
ALPHA MEM (alpha memory contents)
<CAPTURE> (Capture memory group)
CAPT n (Capture memory (1 to 20) data)
CONICS (Conics setting data)
DYNA MEM (Dynamic Graph functions)
EQUATION (Equation calculation coefficient values)
E-CON2 (E-CON2 setup memory contents)
FINANCIAL (Financial data)
<F-MEM> (Function memory group)
F-MEM n (Function memory (1 to 20) contents)
<G-MEM> (Graph memory group)
G-MEM n (Graph memory (1 to 20) contents)
<LISTFILE> (List file group)
LIST n (List memory (1 to 26 and Ans) contents)
LIST FILE n (List file memory (1 to 6) contents)
<MATRIX> (Matrix group)
MAT n (Matrix memory (A to Z and Ans) contents)
<PICTURE> (Picture memory group)
PICT n (Picture (graph) memory (1 to 20) data)
<PROGRAM> (Program group)
Program names (Program contents (All programs are listed.))
RECURSION (Recursion data)
SETUP (Setup data)
STAT (Stat result data)
<STRING> (String memory group)
STR n (String memory (1 to 20) data)
SYSTEM (OS and data shared by applications (clipboard, replay, history, etc.))
TABLE (Table data)
<V-WIN> (V-Window memory group)
V-WIN n (V-Window memory (1 to 6) contents)
Y=DATA (Graph expressions, graph draw/non-draw status, V-Window contents, zoom factors)

Original data can be found through the link down here, page 318 and 319.
http://education.casio.com/resource/pdfs/GII%20User%20Guide.pdf

3
##### Math and Science / Rewriting Formulas
« on: January 12, 2012, 02:31:59 am »
I’m trying to create a program that is able to solve certain physics problems (right now they’re all related to circular motion) for school. The problem is that the program doesn’t cover everything. I have rewritten all of the formula’s by hand and put them in the program’s code to let it process the data.

My problem is that it is unable to combine two formula’s in a way some variables get cancelled out.

For example, take a rollercoaster in a theme park. The track of the rollercoaster contains a looping with a radius of 2,0 metres (r=2,0). We assume that the gravitational accelleration is 9,81 m/s^2. How fast does it have to go at the top of the looping to prevent the carts from falling out? (we ignore the weight-shift of the cart train as it moves a along the track, as well as the friction)

We can solve this by equaling two formula’s: the one for the centrifugal force and the one for the gravitational force. F(centrifugal)=F(gravitational) Because the centrifugal force points directly from the center of the circle to the cart which is straight up when it is at the top, the opposite of the gravitational force’s direction.

We get (m*v^2)/r = m*g
Multiply with r
m*v^2 = m*g*r
divide by m
v^2 = g*r
v = sqrt(g*r)
filling that in gives
v = sqrt(9,81*2,0) = 4,3 m/s

This equation crosses the m out of the equation, something my program isn’t able to do. I can’t figure out how to make it do that. Does anybody know an algorithm for crossing out variables like this?

4
##### Casio Calculators / Rewriting formula's
« on: December 20, 2011, 07:27:41 am »
I’m trying to create a program that is able to solve certain physics problems (right now they’re all related to circular motion) for school. The problem is that the program doesn’t cover everything. I have rewritten all of the formula’s by hand and put them in the program’s code to let it process the data.

My problem is that it is unable to combine two formula’s in a way some variables get cancelled out.

For example, take a rollercoaster in a theme park. The track of the rollercoaster contains a looping with a radius of 2,0 metres (r=2,0). We assume that the gravitational accelleration is 9,81 m/s^2. How fast does it have to go at the top of the looping to prevent the carts from falling out? (we ignore the weight-shift of the cart train as it moves a along the track, as well as the friction)

We can solve this by equaling two formula’s: the one for the centrifugal force and the one for the gravitational force. F(centrifugal)=F(gravitational) Because the centrifugal force points directly from the center of the circle to the cart which is straight up when it is at the top, the opposite of the gravitational force’s direction.

We get (m*v^2)/r = m*g
Multiply with r
m*v^2 = m*g*r
divide by m
v^2 = g*r
v = sqrt(g*r)
filling that in gives
v = sqrt(9,81*2,0) = 4,3 m/s

This equation crosses the m out of the equation, something my program isn’t able to do. I can’t figure out how to make it do that. Does anybody know an algorithm for crossing out variables like this?

5
##### Casio Calculators / Casio SDK
« on: October 06, 2011, 08:02:14 am »
I’ve started programming with the Casio SDK but I’m currently stuck at trying to draw sprites. If I assign the hex values to an array and display it using Print((unsigned char*)sprite1) it displays the character codes that are bound to the hex values instead. I know it is possible to do this via this method because of a screenshot of the Pixel Studio program, showing hex codes being assigned to an array. It’s the code that wasn’t on the screenshot I need.

Also, I know I can use fx-revolution 1.0 for this but I want to know how to do it like this as well.

6
##### Casio Calculators / problem with PxlTest
« on: September 23, 2011, 06:27:50 am »
EDIT: Somehow the entire problem vanishes once I replace PlotOn with PxlChg. I don't know how, but it works.

I have a problem with the PxlTest command in an IF statement. I basically want a dot to move around the screen without running into any pixels that are on. But for some reason the dot will move regardless of whether or not there is a dot in the way. I used a different program to check it by breaking the program when the dot is next to a pixel in the on state, and it says it is on, no matter how i formulate it (PxlTest(B,A), PxlTest(B,A)=0, PxlTest(B,A)=/=1, etc) it will definitely say the pixel is on. But the IF-statement will simply ignore whatever state the pixel is in. I'll post the code for the IF-statement when the down button is pressed.

Code: [Select]
If Getkey=28 And PxlTest(64-B+1)=0(the 64 is because I use PlotOn to place the pixel, making the Y-coordinate (the B variable in this case) inverted. Because the graph screen is 64 high this makes sure the coordinates are correct)Then A->D:B->E:B+1->B(D and E just remove the old dot image when it has moved)IfEnd
If you think it's the inversion making it go wrong it isn't; as I said before I tested it by continuously using PxlChg on the pixel that should be tested to make sure the right pixel is tested. Can anybody help me?

7
##### TI-BASIC / Illusiat 12 ERR:UNDEFINED SOLVED
« on: June 07, 2011, 12:04:29 pm »
EDIT: Problem solved; WabbitEmu doesn't recognise .8XI files like .8XP files. You have to check All Files at Files of Type when loading a file to see them.

I have been trying to run Illusiat 12 on WabbitEmu (with the TI-83+ ROM, by the way) but even though I put the files from the archives folder into the archive memory and the files from the RAM folder into the RAM memory the program ILLUSI12 displays ERR:UNDEFINED when I press enter on EXEC and then enter again.

For the record, here is my memory data as displayed by SHIFT, MEM, 2:Mem Mgmt/Del..., 1:All:

RAM FREE 4668
ARC FREE 1555K
ILLUSI12
L1
*L10
*L2
*L3
*L4
*L5
*L6
*L7
*L8
*L9
LA
LB0
*LB1
*LB2
*LB3
*LB4
*LB5
*LB6
*LB7
*LB8
LC
LD
LE
LF
LG
LL1
*LL2
*LL3
*LL4
LM
LR
LT
LV1
LV2
LV3
L1
L2
L3
L4
I

I also can't find the Pic1.8XI to Pic8.8XI files anywhere on the calc, even though I am sure I extracted them as well. Can anybody tell me where these files should be located so I can check whether or not they are there?

8
##### Casio Calculators / Monopoly
« on: May 30, 2011, 12:58:36 pm »
I created a small program to simulate walking over a 40 square monopoly board (without the cards and special squares of course). The odd thing is that after I let it run for one-and-a-half hour (100.000 dice rolls) there were some really big deviations from the expected 2500 per square. They occur with intervals of 7 squares and are in pairs, the first of the pair being around 3100, the second one being around 2000.
They occur on 1, 8-9, 16-17, 24-25, 32-33, 40 (40 and 1 are also a pair). Does anybody know where this comes from? Here is the code (not that complex really):
Code: [Select]
For 1-->A To 400-->List 11[A]Next0-->A:1-->B:0-->CLbl 0RanInt#(1,6)+RanInt(1,6)-->AA+B-->BB>40==>B-40-->BList 11[B]+1-->List 11[B]C+1-->CLocate 1,1,CGoto 0

9
##### Casio PRIZM / Casio RPG: The age of Slime (beta 0.2)
« on: March 01, 2011, 04:05:12 am »
I am working on an RPG game for the Casio fx-9860GII. The game will be, like DJ_O's Illusiat games, completely sprited with ASCII (all the characters the fx-9860GII can make).

I'll probably upload an Alpha version for you to try in a week or two. I only need to get some monsters and the damage showing system(completed) running, and then it's good to go. Take note though, the programs still take a lot of space since I haven't optimalized them yet.

Beta download here (current version 0.1)! (I'm not sure whether you need both the g1s and g1r files, but I uploaded them both to be sure. Just run the RESET program first and then don't touch it again (it resets all of your data). Then always run the RPG program. Move around on the map with the <- and -> arrow keys, use SHIFT to open the menu on the map screen or to leave the inventory screen or the shop and use EXE to select an option. Have fun and report any problems!

http://www.mediafire.com/?a7uc18duf0w2xbb
http://www.mediafire.com/?ol26bx2b9792f3y

Screenshots in spoiler tag!

Spoiler For Screenshots:
The map sceen

Battle!!!

Slime took 4 damage!

Current progress:

Battle system: 100%
Monsters: 20%
Maps: 20%
Save system: 100%
Shops: 10%
Monster drops: 0% Cancelled

10
##### Casio Calculators / RPG game bug
« on: February 20, 2011, 08:43:06 am »
I am currently working on a small RPG game programmed in the language the fx-9860GII uses (some kind of BASIC, but not TI-BASIC), but there is a problem. I've got a first, primitive battle system working but there is a problem.
When the character dies in battle, the program functions normally; it returns to the Map-Routine and refills the characters HP and the next battle will start normally. But when the character wins in battle, the second battle only shows the attack animations of the character and the monster without even drawing the character or the monster, and then displays the character has won the battle again. The battle started after that works normally. I think this has something to do with using the return statement and then starting the program you returned from again, but I'm not sure. So here is the code for the routines ([DISP] means the DISP command):

RPGL1
Spoiler For RPGL1:
Code: [Select]
Lbl 0ClrText0->DRanInt#(0,1)->RProg "RPGCHAR"R=0=>Prog "RPGSLIME"R=1=>Prog "RPGGIBTL"Lbl 1If Getkey=31Then 1->GProg "RPGCHAR"IfEndLocate 13,7,LIf L=0Then ClrTextLocate 7,4,"YOU WON!"[DISP]ReturnIfEndG=1 And R=0=>Prog "RPGSLIME"G=1 And R=1=>Prog "RPGGIBTL"Locate 2,7,HIf H=0Then ClrTextLocate 8,4,"YOU LOST"[DISP]1->DReturnIfEndGoto 1

RPGCHAR
Spoiler For RPGCHAR:
Code: [Select]
Lbl 2G=0=>Goto 0G=1=>Goto 1Lbl 0Locate 1,7,"H"Locate 2,7,HLocate 7,7,"M"Locate 8,7,MLocate 1,6,"---------------------"Locate 3,3," o"Locate 3,4,"-|-"Locate 3,5,"/ \\"ReturnGoto 2Lbl 17->XFor A+1->A To 17Locate X,4,"@"Locate X-1,4," "Frac (A/2)=0=>6+A/2->XNext0->ALocate 14,4," "Locate 13,7,"    "L>0=>L-RanInt#(2,6)*List 1[3]->LL<0=>0->L1->GReturnGoto 2

RPGSLIME
Spoiler For RPGSLIME:
Code: [Select]
G=0=>Goto 0G=1=>Goto 1Lbl 040->L0->PLocate 12,7,"H"Locate 13,7,LLocate 18,7,"M"Locate 19,7,PLocate 7,1,"SLIME LV1"Locate 15,2,"  ^"Locate 15,3," / \\"Locate 15,4,"/ o \\"Locate 15,5,"\\___/"ReturnLbl 113->XFor A+1->A To 17Locate X,4,"@"Locate X+1,4," "Frac (A/2)=0=>14-A/2->XNext0->ALocate 6,4," "Locate 2,7,"    "H>0=>H-RanInt#(2,6)x2->HH<0=>0->H0->GReturn

RPGGIBTL
Spoiler For RPGGIBTL:
Code: [Select]
G=0=>Goto 0G=1=>Goto 1Lbl 050->L0->PLocate 12,7,"H"Locate 13,7,LLocate 18,7,"M"Locate 19,7,PLocate 7,1,"GIANT BEETLE LV2"Locate 15,3,"<---\\"Locate 15,4,"|o  |"Locate 15,5,"=-=-="ReturnLbl 113->XFor A+1->A To 17Locate X,4,"@"Locate X+1,4," "Frac (A/2)=0=>14-A/2->XNext0->ALocate 6,4," "Locate 2,7,"    "H>0=>H-RanInt#(2,6)x3->HH<0=>0->H0->GReturn

RPGMAP1
Spoiler For RPGMAP1:
Code: [Select]
Lbl A1->BLocate 1,1,"******* ****** ******"Locate 1,2,"******   ****  ******"Locate 1,3,"*****   *10*   *****"Locate 1,4,"***   3  ***     ***"Locate 1,5,"**        *        *"Locate 1,6,"      *       6    *"Locate 1,7,"@    ***          **"List 1[5]>=3=>Locate 7,4,"@"List 1[5]>=6=>Locate 16,5,"@"List 1[5]>=10=>Locate 11,3,"*@"Lbl 0If D=1Then 0->DList 1[1]->HIfEndIf B=1Then Locate 1,6,"\/"Locate 7,3," "Locate 16,5," "Locate 12,4,"*"IfEndIf B=2 And List 1[5]>=3Then Locate 7,3,"\/"Locate 1,6," "Locate 16,5," "Locate 12,4,"*"IfEndIf B=3 And List 1[5]>=6Then Locate 16,5,"\/"Locate 1,6," "Locate 7,3," "Locate 12,4,"*"IfEndIf B=4 And List 1[5]>=10Then Locate 12,4,"^"Locate 1,6," "Locate 7,3," "Locate 16,5,"*"IfEndGetkey=27 And B=1 And List1[5]>=3=>B+1->BGetkey=27 And B=2 And List1[5]>=6=>B+1->BGetkey=27 And B=3 And List1[5]>=10=>B+1->BGetkey=27 And B=4>=3=>B+1->BGetkey=38 And B=1 And List 1[5]>=10=>B-1->BGetkey=38 And B>2=>B-1->BB>4=>1->BB<1=>4->BGetkey=31 And B=1=>Goto 1Getkey=31 And B=2 And List1[5]>=3=>Goto 2Getkey=31 And B=3 And List1[5]>=6=>Goto 3Getkey=31 And B=4 And List1[5]>=10=>Goto 4Getkey=78=>Goto 5Goto 0Lbl 1Prog "RPGL1"Goto ALbl 2Prog "RPGL2"Goto ALbl 3Prog "RPGL3"Goto ALbl 4Prog "RPGB1"Goto ALbl 5Prog "RPGMENU"D=1=>ReturnGoto A

I have no idea what might have gone wrong, can anybody help?

11
##### General Calculator Help / fx-9860GII; inefficient coding?
« on: January 20, 2011, 08:10:53 am »
I'm creating a simple maze-like game on my fx-9860GII, but there's one thing taking a huge amount of data and time. The goal of the game is to move a dot (.) between the crosses (X) towards the exit (O). There are also fake exits (looks exactly the same as a real exit). Touching a cross or fake exit adds 1 to the death counter (which decreases your score after completing all of the levels by 2500 per death) and resets the level. Every step you take also decreases 100 from your final score.

The problem is not the positioning of the crosses, (fake) exits and the dot, but the death system is. Level 1 and 2 are respectively 3220 and 5344 in size. They just contain this bit of code, repeated over and over again:

(Everything between {} is either a command I can't type or a number that differs throughout the code and [] are comments)

Spoiler For Spoiler:
If X={x-coordinate of cross/fake exit}          [Determines the x-coordinate of the cross/fake exit]
Then If Y={y-coordinate of cross/fake exit}            [Determines the y-coordinate of the cross/fake exit]
Then ClrText                                                      [Clears the screen]
Locate 7,2,"YOU DIED"{disp_command}                  [Displays "YOU DIED" text]
D+1-->D                                                           [Adds 1 to the death variable]
Prog "LEVEL1"                                                    [Restarts the level]
IfEnd                                                                [Ends the x-coordinate If-statement]
IfEnd                                                                [Ends the y-coordinate If-statement]

I was wondering whether there is a more efficient way to do this instead of repeating this (with variations for completing the level and hitting a fake exit). I'm asking because I also recently learned how to get rid of the tracks the dot leaves behind without being required to draw all of the crosses and (fake) exits again per step.