Re: [stella] Euchre: a tight fit

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