Subject: Re: [stella] Euchre: a tight fit From: "TwoHeaded Software" <adavie@xxxxxxxxxxxxx> Date: Tue, 4 Sep 2001 10:12:44 +1000 |
You can save a fair bit by junking the LetterImageTable and calculating the address instead of looking it up. This requires the letters to be defined in a set order, but that's not a big limitation. Replace... GetLetterImage txa asl tax lda LetterImageTable,x sta $00,y lda LetterImageTable+1,x sta $01,y rts with GetLetterImage txa asl asl asl adc #<LetterImageSpace sta 0,y lda #>LetterImageSpace adc #0 ; can be omitted if LetterImage stuff doesn't cross a page sta 1,y rts This loses 1 byte in the routine, but junks the LetterImageTable, saving a total of 65 bytes or so. The same thing can be done with the other tables indexing data of known sizes. eg: ScoreImageTable indexes 5-byte entries, so GetScoreImage stx temp txa asl asl adc temp adc #<ScoreImage0 stat 0,y lda #>ScoreImage0 adc #0 ; can be omitted if ScoreImage stuff doesn't cross a page sta $01,y rts This should save something like 25 bytes. Same can be done with RankImageTable. Another mmh.... 15 bytes or so. As Thomas said, LOTS of space to be saved. Cheers A - Andrew Davie, TwoHeaded Software adavie@xxxxxxxxxxxxx ----- Original Message ----- From: "Erik J. Eid" <eeid@xxxxxxxxx> To: "Stella Listserv" <stella@xxxxxxxxxxx> Sent: Tuesday, September 04, 2001 7:01 AM Subject: [stella] Euchre: a tight fit > I've been working on incorporating the actual play of a hand of Euchre into > my game. I nearly finished adding the code that would allow a full hand to > be played, counting up tricks, scoring the hand, and let the human player > select a card with the paddle. The computer, for now, would just pick the > first available card from its hands. > > When I finally compiled the code, I got this message from DASM: > > "segment: code fb00 vs current org: fc14" > "line 2281 D:\Atari2600\Euchre\Euchre.asm Origin Reverse-indexed" > > I'd gotten this once before after I added a couple of new messages and > digit images. It means that my code crossed over an org boundary that I > set up. In the case mentioned above, my code has overlapped code that is > set to start at $fb00 by 276 bytes. This is without adding in the > intelligence for the computer to play a hand! > > Needless to say, I'm in a bit of a tight spot. I still want Euchre to be a > 4k game. This means something has to give. > > I don't believe that I have room enough at the end of the pages that I have > set aside to cram in some utility code - certainly not 276 bytes' > worth. Since I haven't finished adding everything in, my problem will grow > even more later, so trying to push chunks of code into little spots isn't > the whole solution. > > What I need from readers of the list is some advice as to what I can trim > from my code. I'm looking for a general strategy, though advice about > specific segments of code is certainly welcome. > > One prime candidate for trimming is the user interface. The text messages > that appear at the bottom of the screen, while they inform the player well, > may be too expensive. The definition of each letter takes eight bytes, > plus two bytes for inclusion in a table of letters, for a total of ten > bytes. With 26 letters plus some other symbols, this can push 300 > bytes. I could get rid of the message area at the bottom and just have > symbols or short words appear near the card of a player. "Pass", for > instance, can fit into two sprites if each letter is only four bits > wide. Of course, having messages potentially appear in more than one > location could be expensive in terms of code to display them. > > Another candidate for trimming is the computer's intelligence. I'm > reluctant to reduce that at all because I'd like to have a game that > provides a worthy opponent. Backgammon, Bridge, 3-D Tic-Tac-Toe, and Video > Chess all manage on 4k (as far as I know). Euchre should be no different > (particularly because Euchre is a much less complex game than Bridge). I > should not need much more code than what is already in place. With only > five cards to choose from at most and a requirement to follow suit, the > amount of choices available to a computer player during play are small. As > far as deciding whether to accept or call trump or not, a lot of "thought" > goes into judging whether or not the team can reasonably take three out of > five tricks. > > I might be able to save some bytes by reading the joystick, which is only > one read per frame, versus reading the paddle, which is many reads per > frame. However, some overhead would be added because I'd need to always > track the current selection so that the cursor moves to the right > one. With the paddle, the paddle's location always determines the selection. > > There are probably other areas in which I can shave off a few > bytes. However, given that I'm now over by a page and essential game play > elements aren't finished, not to mention fancier features (sound and a > title screen), I need to cut out and/or optimize a significant amount of code. > > I've attached the current source, which will not compile successfully. Any > advice as to what I can reasonably cut out and how I can make the code more > efficient will be greatly appreciated. > > Thank you all very much! > ---------------------------------------------------------------------------- ---- > > . . \_ +\_ + o_-/ . O > . \-_o -=/- . . > . . \=// . > ---------\_______ ||O ___.______ > /* Erik Eid */ \____||L/\_____/ > /* eeid@xxxxxxxxx */_______________________ - Archives (includes files) at http://www.biglist.com/lists/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] Euchre: a tight fit, TwoHeaded Software | Thread | Re: [stella] Euchre: a tight fit, Erik J. Eid |
Re: [stella] Stella at 20, Glenn Saunders | Date | [stella] Cart card edge connector, B. Watson |
Month |