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!

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?

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.

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
L₁
L₂
L₃
L₄
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?

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!


Current progress:

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

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)


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.

Thanks in advance!