Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.

What calculator type are you using?
TI-83
 0%  [ 0 ]
TI-83+
 18%  [ 3 ]
TI-83+ SE
 0%  [ 0 ]
TI-84+
 18%  [ 3 ]
TI-84+ SE
 56%  [ 9 ]
Other
 6%  [ 1 ]
Total Votes : 16

Hey, everyone, I just finished a TI-(83/84)+ remake of the game Bejeweled by PopCap.

In stead of the colored gems I've decided to use the numbers 1 to 7 which is why it's called Benumbered.

Features it supports are:
- 4-level grayscale graphics
- Main menu with high score lists
- Scores up to 9,999,999 (24-bit integers)
- 6 different game modes (5 ported and 1 original)
- Selecting/deselecting/swapping
- Detection of all possible moves to be made
- Hints (after 15 seconds of doing nothing or when pressing [ALPHA]
- Cascades
- Scoring
- Time
- Level progressing
- In-game contrast changing
- Teacher key
- Text messages on screen like "Level X", "Go!" and "No moves!"
- Floating scores, so you can see on the board how many points you just got for a pair that was created
- Pause / turn calc off
- Game saving and loading
- High score and name saving
- Mode unlocking
- AppVar for data saving
- Reasonable high scores to beat

Possible future features:
- Regular TI-83 version
- Hardwarde-specific grayscale
- No moves/time up/level complete animations for smoother transitions
- Splash screen
- Easter egg

The program on the calculator is 9371 bytes and will create a 669 byte AppVar to store data.

You can find it in the archives at Cemetech here or get it from ticalc.org.

Here are some screencaps:

The file has been accepted, and is here:
Benumbered 2.0 Beta

I'll definitely give it a try and see how it goes. Did you write it nostub, for Doors CS, or something else? I am of course biased to suggest that if it isn't, that you make it a Doors CS game. Smile The features you have seem good, and your future features are a good mix of the trivial (see also: contrast changing) and the challenging (see also: demo mode). A minor silly nitpick: 24-bit numbers actually go up as high as (2^24)-1 = 16777215, so are you just approximating re: 10 million, or do you limit numbers at 10 million for display sanity?
I would have to assume sanity Razz i

I have never played bejewled before, so I might try this out Very Happy
Why do you use 24 bit scores? If you want the score to look big, just append zeroes to it.
KermMartian: Thank you for accepting my file. It is nostub, but the full description is in the readme that's included in the ZIP-file.

About the scores, it actually is the sanity thing. Theoretically you could surpass 9,999,999, and in the menu I suppose it would be displayed normally, but on the HUD it would fail. But I guess you would have to check it out to verify that. Wink

Also, implementing the demo version would probably be the hardest feature left to do and that's why there is a question mark beside it. I would have to come up with some sort of AI for every game mode. But I will leave that for last anyway. I'll probably be adding the features in the order they are listed.

But I would love anyone to test it out before I add too much more to it, to catch any bugs while it's still possible to find the source.

Edit by tanner:
souvik1997: I Actually wanted to keep the scores as small as possible. I just felt that 65535 would not be that hard to surpass with all the bonuses and multipliers applied once you reach the higher levels. The lowest possible amount of points you can get for a move is 2. That does not look that big to me. Smile
A quick note on Cemetech policy: when your last post was less than 20 hours, it is proper etiquette to edit the post, rather than post a new one. The exception is, of course, project updates that are so spectacular, they need their own post.
_player1537 wrote:
A quick note on Cemetech policy: when your last post was less than 20 hours, it is proper etiquette to edit the post, rather than post a new one. The exception is, of course, project updates that are so spectacular, they need their own post.
Thanks for that, Tanner, that's exactly right. Smile And Cerzus, thanks for the details!
Here is a screenie detailing the game.



That is really amazing o.o
That looks great! The numbers work a lot better than I thought they would.
Thanks, guys, this is great to hear! Very Happy

_player1537: Thank you for the putting up the screenshot! Did you find anything should be changed or did you come across any bugs?
Just to clarify, is this pure ASM or Axe? I got the impression it was pure ASM from your division question, but either way, very nicely done!
Ii is pure ASM. The only 'libraries' it depends on are a couple romcalls to set OP1 and display it. Thanks, man, but now the question: did you like playing the game too?

EDIT: Of course this is not true. It also uses the built in string routines and a checkfindsym for the write back
cerzus69 wrote:
Ii is pure ASM. The only 'libraries' it depends on are a couple romcalls to set OP1 and display it. Thanks, man, but now the question: did you like playing the game too?

1. I found the grayscale slightly eyestrain-inducing, but that was most likely the fault of the emulator I was using, not your (and Jim E's) coding.
2. I liked how fluid everything felt
3. You even included hints, like the original!
4. A note on the readme: I'm not sure why you quoted SMC as a problem with Doors CS. DCS has no problems at all with SMC. Smile
What emulator are you using, because when I run it in Wabbitemu, the grayscale is as smooth as it can get.
The problem with Doors CS and SMC is that I use custom variables like this:


Code:

variable = $ + 1
  ld a, $00
  ...
  code that modifies a
  ...
  ld (variable), a


When not using Doors CS, (variable) will be reset to zero every time you start the game, because the SMC only changes the version that has been copied to progStart. Doors CS on the other hand (and correct me if I'm wrong here) will copy the running version back if it has changed.
I've seen this in the location of the cursor for example. When I was using Doors and I quit the game and started it again, the cursor would be at the location I would have left it off the last time.
I counteracted upon this by initializing those variables at the start of the game/level with:


Code:

  xor a
  ld (variable1), a
  ld (variable2), a
  ...


But I am not sure if I've got them all.
If you zero out the variables before you exit, you can even keep Doors CS from doing writeback if there are no new high scores.
Before you exit, when you start, doesn't make much of a difference speed or size-wise, I just need to find out what variables need to be set.
I would want to make it as compatible as possible, so for the highscores I will write my own writeback function and I actually already am writing back in the random function.

EDIT: Sorry, I just got how it does make a (speed) difference if I set the variables before exiting. If all data is the same when the program finishes, then Doors CS won't write back right?
That's exactly correct, that's the point I was making. Smile Doors CS trumps other shells in that regard in that it actually checks the contents to make sure that there are new contents to write back before it does writeback.
this is brilliant!
i particularly love that each number, upon moving, has it's own variable velocity. shift mode is a very nice touch as well.
the gray does look a bit wonky on my 84+SE's LCD; was the screen refresh rate specified for running on a different model? if so, it shouldn't be all that hard to detect which hardware the game is being run on and adjust it accordingly.
that really isn't necessary, though, as it's only a minor issue.

this game, as it is, already blows me away, and i can't wait to see how you implement your other listed features.

a question: i am curious as to how exactly you go about finding hints/determining when no possible moves remain as this is something i've attempted myself with only slow results.
Agreed, that's a very hard task. I too was wondering what your exact methodology was, if you had some kind of brute force solver, or is it does something more subtle.
shmibs: Thank you! The grayscale at the moment is actually tailored to my own TI-83+, which (of course...) is one with the faulty LCD driver so it is not optimal yet, but as I said I want to make it as compatible as possible, so that's something to add to the list as well. As well as better graphics in the HUD.

It was indeed pretty hard to do the move detection. It actually is quite brute force. And before the function was finished, I was afraid that it would be too slow to do all the numbers at once and get an immediate result, but somehow it isn't.
I do a check once after every cascade that has finished and one at the start of each level to make sure that you don't start without any moves.
For each direction (left, right, up, down) it loops through all numbers on the board and check if it results in a pair of 3 if the number would move to the next spot in that particular direction. It's hard to explain the exact details, but I could give you the code that does this, if you'd like. I think it is commented pretty well, but it is also quite heavy on SMC so it might not be that easy to understand.

Here is a diagram that explains it a bit better.
  
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
» Goto page 1, 2, 3, 4, 5, 6, 7, 8  Next
» View previous topic :: View next topic  
Page 1 of 8
» 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