Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => Casio PRIZM => Topic started by: z80man on January 19, 2011, 08:03:05 pm
-
---Updated With Newer Version---
As many know the Casio Prizm recently came out. Unfortunatley the BASIC drawing commands can be quite slow. Last week I experimented with a simple snake game, but it was really slow and took forever to play. Working on some optimization I found a new way to draw with lines instead of pixels to allow the game to run much faster. Attached you will find the program. Please comment on what you like, what you don't like and any glitches.
(http://img.removedfromgame.com/imgs/0-DispCap2.bmp)
(http://img.removedfromgame.com/imgs/0-DispCap3.bmp)
(http://img.removedfromgame.com/imgs/0-DispCap4.bmp)
-
Just tried it. Pretty nice!
Now I just have to examine your source.
-
For anyone who wants to view the source for optimizations and glitches I'm posting it here in txt format using the OS's handy program to txt function. ;)
Edit: the program is uncommented so a few commands might seem a little strange.
-
Cool, gonna try it on my calc now.
EDIT: That looks nice actually. I think it definitively needs to have stuff you must eat on your way or a goal, though, so you don't just move around. Nice start, though. :)
-
I'll try to expand on this game as much as I can without slowing it down. I already have an idea to add goals without slowing down the game. I wish though I could make the menu faster. Of course I could just use the default menu, but that wouldn't look as nice.
New update: Right now I'm at school, but once I get home I will post the new version which features targets to hit for points.
-
Here it is the new version of Prizm Snake. Right now I'm working on a couple of small basic games for the Prizm which I will later compile into a game pack. For snake though the game is mostly complete. I'm still going to work on trying to optimize more for size. Speed probaly won't get a whole lot faster. There were many other basic games I wanted to port to the Prizm, but they would just be to slow. Instructions are posted below
Menu: arrow keys to select difficulty, shift key to begin game
In game rules: arrow keys to change direction
Top left of screen shows how many lives you have left (max of 9)
You start with zero, but gain one for every black dot you hit.
Everytime you hit a wall or yourself you will lose one life and pass through
The first black dot is worth 50 points, second 100, third 150 ...
You gain one point for every space you go
You immediately lose when you hit a border wall regarless of how many lives you have left.
In medium your final score is x2, hard x3, and very hard x4
I could not find any bugs, but do tell me if you find any. Any comments would be much appreciated. :)
-
Cool, I'll give it a try soon :)
Are you planning to eventually add them to the downloads section? (When I actually add a Prizm section) Also you should try making an home screen version of Snake just to show the speed difference.
EDIT: Tried it and it's nice, but collision detection seems a bit bugged. Sometimes I go through the snake or lines. ???
-
With the collision detection that was an experiment I was trying with adding life to the game. The number in the top left shows how many walls you can hit before gameover. I don't think I'm going to keep that in the final version. I'm also going to try a slightly different version of the engine where coodinates are stored in a matrix instead of doing the slow pixel test. This would allow the back end of the snake to disapear over time.
-
Oh ok I didn't think about that, and wow I didn't realize pixel test would be that slow. On the 83+ it's like the fastest way to do collision detection in BASIC. O.O
-
Oh ok I didn't think about that, and wow I didn't realize pixel test would be that slow. On the 83+ it's like the fastest way to do collision detection in BASIC. O.O
Really? It seems to have always been popular wisdom not to use pixeltest in the casio communities.
-
Holy necropost batman flyingfisch! :O
But yeah in the TI community that's one of the fastest collision detection method and in certain cases can be the most accurate (if for example all your solid tiles have black outlines and you some aren't rectangular). String collision detection is kinda slow when you need to check many elements and lists/matrices are just prohibitive in terms of memory usage (at least 9 bytes per list element, so a 16x8 map takes 1152 bytes of RAM. (the string counterpart takes between 128 and 256 bytes and pictures that works with pxl-test takes 16)
-
Woah, i didn't even realize I necroposted... O.O
I thought this topic was more recent than Jan 2011. Sorry. :-\