elfprince13 wrote:
MateoConLechuga wrote:
KermMartian wrote:
This is looking great! Are you using the DCSE sprite routines, out of curiosity? Regardless, keep up the excellent work.


Unfortunately, no. Sad This is because I am considering making it an app because storing 60 levels might take some room.


Don't compile the 60 levels in. Load them externally.


Ah, that could work. Thanks! Smile
Have you considered using the scrolling feature? Instead of moving all the tiles in the field, you would move the data displayed in the margins. Your code would certainly be more complicated. But if you add a layer of indirection into all of the graphics routines that abstracts it away, you could possibly get a speed improvement, and eliminate the tearing effect you see in those screen shots. (Of course, you'd just be replacing it with a tearing effect in the margins, but it would be less distracting.)
Or consider running at half resolution and double buffering?
Yes, I am definitely considering scarping most of what I have now, and just keeping the main block checking routines. When I first started, I should have started on half resolution, but it is not too big of a deal to change. I might opt for the double buffer, but will shall see since I would have to write to the buffer and then directly to the screen, which could cause some slowdown. Well, time to redo a whole bunch! Smile
I could use a little bit of help: So, I tried using Unknownloner's reference to half res, but I am getting a crashed calculator when I try to use it. Here is the code:


Code:
#include   ti84pcse.inc

   .org   userMem-2
   .db   $EF,$69

   ld   a,1
   out   ($20),a      ; 15MGHZ Speed

   out   ($10),a
   out   ($10),a
   ld   a,%00000100  ;bit 10 set
   out   ($11),a
   xor   a           ;a = 0 for low bits
   out   ($11),a
   
   ld   a,7
   out   ($10),a
   out   ($10),a
   ld   a,%00110001  ;Enable both partial images
   out   ($11),a
   ld    a,%01001100  ;Default values for low bits
   out   ($11),a

   ld   a,$80        ;Img 1 disp position
   out   ($10),a
   out   ($10),a
   xor   a           ;Display position of first img = 0
   out   ($11),a
   out   ($11),a

   ld   a,$83        ;Img 2 disp position
   out   ($10),a
   out   ($10),a
   xor   a           ;MSB should be 0 since 160 < 256
   out   ($11),a
   ld   a,160        ;Display position of second img = 160
   out   ($11),a

   ld   a,$81        ;Img 1 start line
   out   ($10),a
   out   ($10),a
   xor   a
   out   ($11),a
   out   ($11),a

   ld   a,$84        ;Img 2 start line
   out   ($10),a
   out   ($10),a
   xor   a
   out   ($11),a
   out   ($11),a

   ld   de,159      ;End lines for partial images
   ld   c,$10
   ld   a,$82       ;Img 1 end line
   out   ($10),a
   out   ($10),a
   out   (c),d
   out   (c),e

   ld   a,$85       ;Img 2 end line
   out   ($10),a
   out   ($10),a
   out   (c),d
   out   (c),e
   
FullExit:
   ld   a,1      ; Disable Interlacing
   out   ($10),a
   out   ($10),a
   xor   a
   out   ($11),a
   out   ($11),a
   
   ld   a,7
   out   ($10),a
   out   ($10),a
   ld   a,%00000001  ;Disable both partial images
   out   ($11),a
   ld   a,%01001100  ;Default values for low bits
   out   ($11),a
   
   bcall(_DrawStatusBar)      
   ld   hl,cmdShadow
   ld   (hl),' '
   ld   de,cmdShadow+1
   ld   bc,259
   ldir
   ld   hl,textShadow
   ld   (hl),' '
   ld   de,textShadow+1
   ld   bc,259
   ldir
   bcall(_maybe_ClrScrn)
   bcall(_HomeUp)
   ret


I was thinking this would simply return to the home screen, but I just get a blank screen. Confused
I don't have an answer because I'm not an asm genius, however I do have kind words.
So far this is looking exceptionally good! I'm liking all the colors and how great the port resemble the original.
I didn't get a chance to search through your code, but it would be a lot easier if you just used the half-res header field in the Doors CSE ASM program header. If you're greatly resistant to using that, I can look further at your code later or tomorrow.
KermMartian wrote:
I didn't get a chance to search through your code, but it would be a lot easier if you just used the half-res header field in the Doors CSE ASM program header. If you're greatly resistant to using that, I can look further at your code later or tomorrow.


That sounds like a better idea! I'll see what I can do with DCS8. Thanks!

EDIT: UPDATE: Was just able to pretty much half the number of clock cycles for my sprite routine! Cool! Smile
Okay, I need some advice not regarding code but of functionality. So, in the original Puzzle Frenzy, a password was required to replay beaten levels. Would it make sense to just skip this step by storing the current level into an AppVar and just allow the user to select a level if it is lower than the current level? Or should it be password based? Thanks! Smile

EDIT: Update: All levels have been converted to the new format. Now only the above question remains...
I think the latter would make more sense. Does anyone actually remember those passwords?
APotato wrote:
I think the latter would make more sense. Does anyone actually remember those passwords?


Not without writing them down. Wink Plus, this will make it easier to advance from one level to the next, and make a whole bunch of code nonexistent. Smile
Hmm I do agree with that. Well I guess I will leave it up to you Razz Both functions have pros and cons.
Password:
•Any lazy gamer is lazy and doesn't want to write passwords down or remember the code
•Eliminates large chunk of code, easier to program.
The not-password:
•Easier for the player
•Adds large section of code
Actually, wouldn't implementing an autosave be less code? You wouldn't have to write a password input, a password database, and a password check.. Without it, all you do is save the highest level to an appvar. I like that better.
I like the idea of passwords, probably largely because I played Puzzle Frenzy back in high school over a decade ago, and dutifully memorized the password for the latest level I had achieved. It would be quite nostalgic for it to offer the password system, at least for me, and I think it's a nice feature in general, especially if a group of friends is competing against each other.
KermMartian wrote:
I like the idea of passwords, probably largely because I played Puzzle Frenzy back in high school over a decade ago, and dutifully memorized the password for the latest level I had achieved. It would be quite nostalgic for it to offer the password system, at least for me, and I think it's a nice feature in general, especially if a group of friends is competing against each other.


Okay! Now I will have to decide... Smile


EDIT: Well, I have reached a decision: I will (probably Smile) implement some type of password routine, but the passwords will not be the same as the original game, in order to add some difficulty. Perhaps I will release the codes, much like the original.

Password site: http://www.random.org/strings/

EDIT: UPDATE: Well, here is a screen shot playing the first ten levels of Puzzle Frenzy. Any comments or criticisms or ideas are appreciated!



EDIT: Password input is complete. Now you can type in a password and it will go to that level. Luckily the code for all of that is less than 400 bytes, including the level passwords.
Looking awesome! Very clean and crisp, i like it.
tr1p1ea wrote:
Looking awesome! Very clean and crisp, i like it.


Thanks! I have also added a feature so that you can choose a completely custom color scheme for the blocks -- just have to work on making it save to an AppVar though.
I like it as well, but the gray text is a bit too dark. Maybe make it lighter, especially for people who have their brightness set lower?

Otherwise, great job and I like the layout so far. Smile
DJ_O wrote:
I like it as well, but the gray text is a bit too dark. Maybe make it lighter, especially for people who have their brightness set lower?

Otherwise, great job and I like the layout so far. Smile


That is a good idea! I'll try to make it somewhat lighter. Smile

Now, I need to come up with a good way to change the color of blocks easily, rather than trying to input the color value. I am thinking about having predetermined sets of colors, which you can choose for each block. Any other ideas?

MateoConLechuga wrote:
tr1p1ea wrote:
Looking awesome! Very clean and crisp, i like it.


Thanks! I have also added a feature so that you can choose a completely custom color scheme for the blocks -- just have to work on making it save to an AppVar though.
Good luck. And wow, this looks absolutely great! It almost looks like you're running in full-resolution mode with that text, as a matter of fact; am I mistaken?
  
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 2 of 4
» All times are UTC - 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