Oops, I didn't mean I'd be making this game in C, I'm merely experimenting with it for future projects since BASIC is far too restricted. This game will still be in BASIC.

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.

They are similar, but I really feel TI-BASIC is the better programming language because of the ability to wrap strings around the screen, having the ability to check a certain part of a string (Casio-BASIC would need to extract the symbol from the string, store it into a seperate string and compare it with the comparison string) and the ability to use HEX codes to generate icons. Especially the last function got me jealous of TI-calc owners The fastest method of drawing a sprite on CASIO is storing the coordinates of the pixels into two lists and drawing them all using Scatter,List 1,List 2 (also with some other things before and after it I can't remember) and changing the V-Window settings to move the sprite around.

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.

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?

Just the screenshots of the main menu's make me want to buy a Prizm. Looking awesome!

Hi everybody, I'm back again!

I could take the entire post explaining why I was absent and apologizing for that but instead I'll share some new developments with you I'm sure you'll like. It'll suffice to say I was preoccupied with a holiday job, thinking over something new to implement and attempting to program those ideas.

After some failed attempts I became interested in the subject of Randomly Generated Mazes. At first I just started it as a seperate project, just for the fun and challenge of coding it but when I had a first, buggy and extremely slow version running I thought I could implement it into my big project!

The idea is that my program generates a random maze of 19x5 because to generate one correctly it needs to check the locations next to the 'current' cell (more about that later) which will result in an error if the current cell is at the edge of the screen. Also, a wall around the maze looks slicker and it drastically cuts down the generation time (by around 25%!).

Now for what the function of the maze in the program will be; it will kinda act like a dungeon. While walking around in it you can randomly encounter monsters and discover treasure. The first part won’t be difficult since the fighting program is completely separate from the main ‘map’ program. The second part will be incorporated like this; when the maze is generated 1/8 empty places will be replaced by breakable walls. These look the same as regular ones and mainly serve to make navigating through the maze harder. But it will also replace 1/40 empty spaces with a different kind of breakable wall; one that will yield treasure upon breaking it.

The maze generates like this; it will first generate a matrix of 7x21. The first number represents the amount of rows=the height, so to keep the visual look of the matrix similar to the look of the final product Y goes before X. The maze will then fill up completely with the value 1. 1 stands for a wall. The program will then assign location (2,2) in the matrix to the starting point and begin by setting it to 0, which is an empty space. Then it will randomly check whether a neighbor is not a 0 already and is not on the edge of the screen. It will then proceed to check whether or not the neighbors of that cell are 0 as well. If they are all still 1 as well it will set the cell to 0 and set the X and Y coordinates of that cell as the new standard X and Y values.

At this point it will repeat until it can’t go on in any direction. At this point it will retrieve data from two lists that have been storing the coordinates of each visited cell. It will mark the one before the one it is in as the current cell and start at the beginning of the whole process. An important note is that if it starts backtracking like this it will start overwriting parts of the two lists, starting one after the cell the new side-route originates from. This is to ensure it will also check the side route for possibilities to branch off again, and to make sure it’ll check the cell the branch started for the possibility of having yet another branch.

This entire system will ensure that there are no walls left the maze can still bend into without looping on itself. The downside is that it takes around 40~80 seconds to generate a complete maze. One of my idea’s is to terminate the program when the maze has 60 empty spaces which will cut off the lag at the end when it’s backtracking all the way back to the beginning but will also leave some unused wall segments.

And that’s about it! Let me know what you think of it, I’ll either post a demo of the maze generator over the course of the next week or upload the new version of the game with the random dungeons implemented!

Thanks for the info!
(Great game by the way!)

Never mind, problem solved, somehow the results were random and just appeared not to be. Every other run of the program returned normal results (95% of the values within 2 standard deviations of the average, checked with CALC1). I also removed the lines involving C since the program runs 4 times as fast without the counter on-screen.