| |
trip6
Account closed
Registered: Jan 2007
Posts: 51 |
Berzek for C64
Hello... I recently recieved assembler source code for Berzerk video game. I was told that I would have to use CCS65 to compile it. However, I am quickly realizing that I have no idea how to do this in CCS65. Can some one help me our compile this for me with CCS65 if I sent the source code? All help is appreciated, I'd love to get a port of this classic on the C64.
|
|
... 260 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
you would do this by making 2 lookup tables. one for y, to adress the leftmost byte "column" of the bitmap, and one for x, for adressing horizontally.
ldy y
ldx x
lda ytablow,y
clc
adc xtablow,x
sta $fc
lda ytabhi,y
adc xtabhi,x
sta $fd
lda $fc
clc
adc #$08
sta $fe
lda $fd
adc #$00
sta $ff
lda spritesource1,x
sta $f0
lda spritesource2,x
sta $f2
ldy #$07
lda ($f0),y
ora ($fc),y
sta ($fc),y
lda ($f2),y
ora ($fe),y
sta ($fe),y
dey
bpl -
somehow like this.. to give you an idea.. |
| |
Heaven
Account closed
Registered: Jul 2008
Posts: 102 |
koesz.
|
| |
Heaven
Account closed
Registered: Jul 2008
Posts: 102 |
ok... got it... I wrote my first c64 basic code ever:
0 for i=1024 to 1024+999:poke i,1:next i
1 poke 53265,peek(53265) or 32
2 poke 53272,peek(53272) or 8
3 for i=8192 to 8192+8191
4 poke i,0
5 next i
10 x=rnd(0)*320
20 y=rnd(0)*200
30 c=int(x/8)
40 r=int(y/8)
50 poke 8192+c*8+r*320,255
60 goto 10
so thanks Oswald, now I know how to prepare my lookup tables... I thought it is same trickery like the weird Apple II screenlayout...
Yes, I know...this is for high res but should be no problem to adapt to MCM. |
| |
Heaven
Account closed
Registered: Jul 2008
Posts: 102 |
of course Oswald, your code fragment does not care about "clipping" across different cells.
Can you remember our conversation regarding my sprite routines in Beyond Evil?
I guess here I have to deal with "split draw" as well as f.e. an 8x16 sprite occupies different cells which are not align together like the
ADG
BEH
CFI
"font modes"...
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
splitting across rows:
tya
tax
ldy specytable1,x
lda ($f0),y
ora ($fc),y
sta ($fc),y
lda ($f2),y
ora ($fe),y
sta ($fe),y
dey
bpl -
$fe=$fe+$140
$fc=$fc+$140
ldy specytable2,x
lda ($f0),y
ora ($fc),y
sta ($fc),y
lda ($f2),y
ora ($fe),y
sta ($fe),y
dey
bpl -
from the top of my head again... sprite data should be indexed with abs,x and the code adjusted to that tho.. |
| |
Fungus
Registered: Sep 2002
Posts: 686 |
First off, there is no need to use bitmap mode... char mode is fine, and hi-res too. The game doesn't use any multicolor graphics.
You can even use built in char set to make the walls.
Use sprites, they are there, use them. There is plenty of easy to understand/use multiplexers which can have 24 sprites on screen quite easy.
The only problem I encountered was the collision detection, so that the bullet can still pass through the players "neck".
|
| |
Heaven
Account closed
Registered: Jul 2008
Posts: 102 |
if the goal is to reuse 90% of the Atari code... then why should I use sprite multiplexor? c64 has mcm, atari has...only difference is the organisation.
so imho could be easy task.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
My God, the Atari 2600 version takes nearly a whole C64 frame to execute one frame. |
| |
Heaven
Account closed
Registered: Jul 2008
Posts: 102 |
hehehe...why not... are the c64 and the 2600 not nearly the same cpu speed?
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Umm, the 2600 generates the display manually, so everything takes a whole frame regardless of complexity. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 27 - Next |
