Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Nearly four months ago, I mentioned in a forum post of a Simon-type game I was working on for the TI-84+ CE. Pretty early on I hit a block from disinterest and stopped working on this project. In an attempt to re-inspire myself, I decided to participate in CC23 to work on something new. After nearly an entire month, I have decided to get back into programming and what better way than to actually complete an older project Laughing! Without further ado, I present the current version of SimonCE:

The game is still in its very early stages, no menu nor any actual input is used (besides clear to break the loops). The colors are being displayed first as triangles and then a more visual sprite is being drawn on top:

The sprite is being scaled 3x in an attempt to reduce its size (It's still almost 4500 bytes). I couldn't really think of another method of reducing this size. The lag in the timer is due to the fact that I have lines between when it finishes and when I reload it so ignore that Very Happy
I'd love to hear any suggestions to reduce size or other gameplay elements!
Compression + RLET Sprite would make that thing tiny.
Agree, you could use compression and other stuff. You could even store the sprite as monochrome and expand it at runtime, or even use circles + lines (which would make it look less blocky perhaps).

You could also look at palette swapping to change the colours instead of redrawing everything all the time, if speed was an issue.
I would display the Simon as circles and lines like tr1p1ea said, but otherwise it looks good.
Development has been very slow recently due to lack of free time but over the past weekend I was able to set up sprite compression and palette swapping. With this, I almost tripled the resolution while keeping the sprite itself much smaller than the original (thanks to the compression example). The actual interactive gameplay development has yet to even start but a rough idea has already been mapped out. Anyways, here's what the significantly faster game looks like.
Wow looks a lot slicker now - great job!
Inspiration is still somewhat difficult for me to find in this project. I know this could be a simple weekend project if I truly put my mind to it but I feel like I keep getting distracted. Anyways, I spent the last couple hours working on it and now it is completely functional. All elements of the game have been added except for a proper start screen and possibly options to control how fast the computer lights are shown. Here's a bit of what the product will look like (I'll eventually center the game, maybe add some indicators when it's the player's turn as right now you can only really tell based off the timer, and other nice space-fillers):
May I suggest drawing the circle/ line thingy, then using FloodFill() to rapidly fill the clicked area?
SM84CE wrote:
May I suggest drawing the circle/ line thingy, then using FloodFill() to rapidly fill the clicked area?


The current method of palette swapping is surely much faster than this Smile
I think that the emphasis was more on getting the shape right, rather than using it as a replacement for setting the palette. However, I still don't think that floodfill is the best solution here - I believe that at one point there was a comment next to it saying something along the lines of "this is just here to prevent people from writing their own slow buggy code to do the same thing." I would imagine that for an area as large as this it would be more efficient to draw over a few pixels multiple times than it would be to run the recursive flood fill algorithm over the entire area. However, you probably shouldn't take my word for it - I would run a test with both colors, if I were really concerned with the speed for this. I doubt that will be necessary, though, as this only has to run once and then palette techniques can be used.
_iPhoenix_ wrote:
SM84CE wrote:
May I suggest drawing the circle/ line thingy, then using FloodFill() to rapidly fill the clicked area?


The current method of palette swapping is surely much faster than this Smile


Yes I am quite happy with how fast the palette swapping is, especially considering how easy it is to change between the colors. I can always modify the original sprite to make any changes I feel necessary.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement