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/
