Cypher Update

[Tempest]

Since Cafeman has been posting all the updates he's made to Koffi I figured I'd fill everyone in on Cypher's progress.

 

After not touching the code for well over 3 months I've spent the last few days going over it again and now I remember exactly what my code does (don't laugh, I wasn't good about commenting my code so it took awhile to remember). I've started to clean up some of the code and like Cafeman have attempted to modularize it for easy updating, but I've hit a bit of a snag there. Hopefully modularization will come later (Any help you ccan offer Cafeman is appreicated).

 

Since I don't have access to my code on my computer I've been playing around with a print out I made just prior to going on vaction. I think I've come up with a way to randomize the squares in the pattern which is the thing that's been holding me up for these last few months. If it works expect to see major progress in the next few weeks.

 

I'm still shooting for a CGE 2K2 release but I should have a playable demo running at the Philly Classic. Keep your fingers crossed...

 

If anyone has hints on how to modularize and clean up code please post them. I've made some progress there, but I still need some help from the experts.

 

Oh yeah, and if anyone can tell me how to implement artifacting with Antic F graphics so my title appears green again instead of white, please let me know.

 

Tempest

http://www.msu.edu/user/reicher6/cypher.htm

[+Cafeman]

Hi, Tempest.

 

FYI, the copy of Cypher you sent me in November is 56k (the source code). Koffi is currently 128k and I only have 1.5 screens built.

 

I didn't see any obvious places where you COULD modularize more.

 

With Koffi, there's alot of graphics drawing. I draw those trees in 6 row increments since my loop routine runs into problems if the "y" register exceeds 255. So I have several repetitive loops just to draw stuff on the screen because I couldn't figure out a clever, smart, concise loop that could read ALL the data and map it to the screen. Cypher doesn't have as much graphics data so you don't have all the .bytes and all the repetitive loops.

 

I'd suggest you just work on the actual code for now, and maybe the optimization ideas will pop in your head as you go. Cypher looks like it could maybe fit on a 16k or maybe an 8k ROM, don't you think?

[DEBRO]

quote:

---

Originally posted by Tempest:

...Oh yeah, and if anyone can tell me how to implement artifacting with Antic F graphics so my title appears green again instead of white, please let me know.

 

Tempest

---

 

How about using a redefined character set for your title. If you did that you could use one of the character or text modes and have your title green again. I think this would be easier. It may take time to redefine your character set (it would be easier and faster using Envision or EnvisionPC) but I think you would like the results.

[+Cafeman]

Matt, look at Koffi's lettering here:

http://cafeman.www9.50megs.com/atari/5200d...offiKopter.html

 

It's in Antic B, a 2-color mode where you get 8 pixels per byte. Wouldn't that work for your Cypher routine? Koffi's letters are yellow, and I use a DLI for the cycling purple band across the letters. I really just did that to see what it would look like.

 

If the resolution is too low in Antic B for you, just use Antic D like you did for the rest of your game. Antic D is 2-colors too, right? But with the same resolution as Antic E?

 

[ 12-29-2001: Message edited by: Cafeman ]

[Tempest]

Update: I got the randomization routine for the pattern (not the board) working, at least in theory. It worked with two squares, but if I do more I start getting Branch Out of Range errors due to the way my code is set up (a seperate loop for each square in the pattern).

 

Things are starting to look up for Cypher! I was so excited about working on my code I totally ignored all the new Playstation games I got including FF X. Amazing huh? I guess when the programming bug bites ya you don't care about anything else.

 

Tempest

[Heaven/TQA]

a little trick to get larger branches: invert your condition checks...

 

f.e.

 

lda var

cmp #blabbla

bcc loop

...

 

lda var

cmp #blabla

bcs cont

jmp loop

cont

...

 

just a thought...

[Tempest]

Well this is what I'm actually doing:

 

ptrnrand

ldy #$00

inc sqrcnt

lda sqrcnt

 

cmp #$01

beq square1

cmp #$02

beq square2

cmp #$03

beq square3

cmp #$04

beq square4

cmp #$05

beq square5

cmp #$06

beq square6

cmp #$07

beq square7

cmp #$08

beq square8

cmp #$09

beq square9

 

rts

 

 

square1

lda SKREST

sec

sbc #$7F

bpl white1

 

black1

lda blacksqr,y

sta $1888,y

sta $18B0,y

sta $18D8,y

sta $1900,y

sta $1928,y

iny

cpy #$03

bne black1

jmp ptrnrand

 

white1

lda whitesqr,y

sta $1888,y

sta $18B0,y

sta $18D8,y

sta $1900,y

sta $1928,y

iny

cpy #$03

bne white1

jmp ptrnrand

 

 

square2

lda SKREST

sec

etc.

 

 

I'm checking which square I'm on (1-9), then I take a random number. If that number is less than 128 it's going to be a black square, if its more it's white. Then I load the black square graphics into the right area on the pattern.

 

The blacksqr and blacksqr2 are almost exactly the same, but blacksqr has the left most boarder while blacksqr2 doesn't have it. I'm using blacksqr for the left most squares down the left hand side and blacksqr2 for all the rest of the squares. This part may not make sense to all fo you but it's really not important to the problem anyway.

 

Tempest

[Thomas Jentzsch]

quote:

---

Originally posted by Tempest:

Well this is what I'm actually doing:

 

lda sqrcnt

 

cmp #$01

beq square1

cmp #$02

beq square2

...

---

 

code:

---

You could do:

ldx sqrcnt

dex

beq square1

dex

beq square2

...

---

...or use a jump table:

code:

---

ldx sqrcnt

lda tableLo,x

pha

lda tableHi,x

pha

rts

 

tableLo:

.byte #square1-1, #square2-1,... ; or was that +1?

tableHi:

.byte >square1-1, >square2-1,...

---

 

Then it doesn't matter, how far away your target address is.

 

Can't use the inverted > (replace #)

 

[ 12-31-2001: Message edited by: Thomas Jentzsch ]

[Tempest]

Can you explain that jump table theory a bit more? That might be the way to go.

 

BTW, what is the range of a branch? Just curious.

 

Tempest

[+Cafeman]

Just to chime in again (with no help though), I am also always getting hit by the branch exceeded error, so I invert my condition and use a jmp. This method is uglier but still conceptually simple.

 

Good to hear you are making progress again. For a while I was thinking you would lose interest in the project and shelve it.

[Tempest]

To be honest I did loose interest for awhile and I did think about quietly shelving it, but after I had people tell me they were actually looking forward to playing my game I decided that I should finish what I started. I'm glad I did though, I'm having a blast again. It's easy to loose interest when you hit a wall like I did.

 

Explain that inverting the branch logic. How would I apply that to my code? I still dont see how it would help (I'm obviously missing something).

 

Tempest

[+Cafeman]

well, if your code initially looks like this:

code:

---

lda sqrcnt

 

cmp #$01

beq square1

cmp #$02

beq square2

...

---

 

And if the above starts to give you branch exceeded errors because square5,6,7,8,and 9 routines are too far away, you just start to change them to something like this:

code:

---

lda sqrcnt

cmp #$01

beq square1

cmp #$02

beq square2

...

cmp #$05

bne NextCheck1

jmp square5 ; you can jmp as far as you want

NextCheck1

cmp #$06

bne NextCheck2

jmp square6

NextCheck2

... etc!

---

 

get it? You probably are already doing this.

 

[ 12-31-2001: Message edited by: Cafeman ]

[Tempest]

That worked, but since every third branch was out of range it makes for some sloppy looking code. I need to look into consolidating some of that code.

 

Now I need to get those addresses right, I was off on my calculations...

 

Tempest

[Thomas Jentzsch]

quote:

---

Originally posted by Tempest:

Can you explain that jump table theory a bit more? That might be the way to go.

 

BTW, what is the range of a branch? Just curious.

---

To answer your last question first: -128..+127 bytes.

 

The jump table tricks works by pushing the target address onto the stack and then use RTS. This normally returns from a subroutine , using the top two values on the stack. Now that we've pushed two new values there, is takes them as the address where it returns. And that's our new target address.

And because the old values for RTS are still on the stack, after you've done your work, you can RTS again, and now the real subroutine values are taken and your are leaving the subroutine as normal.

 

The code might not work 100%, because I haven't my docs lying around. So maybe you have to use +1 instead of -1, and maybe you have to swap the pushing order to Hi,Lo. But a lot of games for the 650x are using this trick (and a lot of other even more sophisticated stuff )

 

BTW: Happy new year 2002!

 

[ 12-31-2001: Message edited by: Thomas Jentzsch ]

[Tempest]

Hmmm... Sounds interesting. I'll have to try that. I need to come up with a different way to do my randomization because my playfield is just too big to use the current method (it's hard to manage with only 9 squares).

 

BTW I got the pattern randomization to work. It's not pretty, but it works.

 

Tempest

[Thomas Jentzsch]

Just found some docs:

- The pushing order is High, Low (was swapped in my code example)

- The -1 is correct.