Author Topic: Expanding Elite  (Read 1383 times)

0 Members and 1 Guest are viewing this topic.

Offline Ygdrazil

  • Global Moderator
  • 6128 Plus
  • *****
  • Posts: 502
  • Country: dk
  • Liked: 59
  • Likes Given: 283
Re: Expanding Elite
« Reply #25 on: 12:05, 02 August 21 »
Hi There
My favourite game for the CPC!...
Now the code has been disassembled, any trace of unknown missions!
As far as I remember there was only one mission in the whole game....

/Ygdrazil

I retraced the drawing routines after the line drawing was halfway adapted to the screen memory.
The drawing itself works, but the number of line segments doesn't fit. Somewhere there is still something in the Bresenham algorithm that calculates the line length incorrectly if you feed it with memory addresses from the CPC screen memory.

At least I was able to find where the data for the vertices, edges and faces are read out and identify another data field in the header and had to try it out right away.

Et voila: The Constrictor

Offline Fessor

  • CPC6128
  • ****
  • Posts: 246
  • Country: de
  • Liked: 239
  • Likes Given: 47
Re: Expanding Elite
« Reply #26 on: Yesterday at 02:35 »
Hi There
My favourite game for the CPC!...
Now the code has been disassembled, any trace of unknown missions!
As far as I remember there was only one mission in the whole game....

/Ygdrazil
I know of two Missions: The Asp with the Cloaking device and the Mission where a Sun goes Supernova. I don't know if there are more, but i havent not yet dumped out all strings in cleartext.

Actual i have Problems to change this code to give me the Address of a Pixel in CPC-Screen-Memory instead of its Position in the Linear-Bitmap at 0xa000.

Code: [Select]
    LC     C,B     ; Save X-Coordinate in C
    ; Adresscalculation (Memblock*2+1)*32 + x/4 (because of 4 Pixel per Byte in Mode 1) + y*64
    LD     H,0x2   ; 16k memory Block (0..3)
    LD     L,A     ; Load Y-Coordinate to L

; Calcs y in Bitmap;
    ADD    HL,HL        ; * 2
    INC    H            ;  Leads to 0xAxxx
    ADD    HL,HL        ; * 4
    ADD    HL,HL        ; * 8
    ADD    HL,HL        ; * 16
    ADD    HL,HL        ; * 32
    ADD    HL,HL        ; * 64

    LD     A,C          ; C = X-Coordinate
    SRL    A            ; / 2
    SRL    A            ; / 4 - Because 4 Pixels in a Byte
    ADD    A,L          ; Add to ScreenCoordinate (H = Y, L = x)
    LD     L,A         
    LD     A,C          ; Get Coordinate
    AND    0x3          ; Masks Pixellocation in the byte
    INC    A
    LD     B,A
    LD     C,0x11       ; Colormask of the Mode 1-Pixel
LAB_ram_7f33
    RRC    C            ; Rotate it to the Correct Position in the Byte
    DJNZ   LAB_ram_7f33
    LD     B,E
    LD     E,0x80
    EXX
    RET

Offline Trebmint

  • 464 Plus
  • *****
  • Posts: 467
  • Country: zw
  • Liked: 326
  • Likes Given: 32
Re: Expanding Elite
« Reply #27 on: Yesterday at 11:42 »
I know of two Missions: The Asp with the Cloaking device and the Mission where a Sun goes Supernova. I don't know if there are more, but i havent not yet dumped out all strings in cleartext.

Actual i have Problems to change this code to give me the Address of a Pixel in CPC-Screen-Memory instead of its Position in the Linear-Bitmap at 0xa000.

Code: [Select]
    LC     C,B     ; Save X-Coordinate in C
    ; Adresscalculation (Memblock*2+1)*32 + x/4 (because of 4 Pixel per Byte in Mode 1) + y*64
    LD     H,0x2   ; 16k memory Block (0..3)
    LD     L,A     ; Load Y-Coordinate to L

; Calcs y in Bitmap;
    ADD    HL,HL        ; * 2
    INC    H            ;  Leads to 0xAxxx
    ADD    HL,HL        ; * 4
    ADD    HL,HL        ; * 8
    ADD    HL,HL        ; * 16
    ADD    HL,HL        ; * 32
    ADD    HL,HL        ; * 64

    LD     A,C          ; C = X-Coordinate
    SRL    A            ; / 2
    SRL    A            ; / 4 - Because 4 Pixels in a Byte
    ADD    A,L          ; Add to ScreenCoordinate (H = Y, L = x)
    LD     L,A         
    LD     A,C          ; Get Coordinate
    AND    0x3          ; Masks Pixellocation in the byte
    INC    A
    LD     B,A
    LD     C,0x11       ; Colormask of the Mode 1-Pixel
LAB_ram_7f33
    RRC    C            ; Rotate it to the Correct Position in the Byte
    DJNZ   LAB_ram_7f33
    LD     B,E
    LD     E,0x80
    EXX
    RET


If you have a few hundred spare bytes just use a look-up table. Feed in the Y, and get a straight screen address back. If the Y is always between 0-127 which I assume it would be you can 256 byte boundary the screen address data so its really quick


ADD A ;Double the Y so 8 bit result to 16Bit
LD L,A ;Load the Low byte with Y
LD H,screentable/256 ; H=High Byte Address table start
LD A,(HL)
INC L
LD H,(HL)
LD L,A


Maybe? ???



Also use a table for the pixel rotation and mask too
« Last Edit: Yesterday at 12:15 by Trebmint »

Offline Axelay

  • 6128 Plus
  • ******
  • Posts: 595
  • Country: au
  • Liked: 394
  • Likes Given: 89
Re: Expanding Elite
« Reply #28 on: Yesterday at 13:37 »

Actual i have Problems to change this code to give me the Address of a Pixel in CPC-Screen-Memory instead of its Position in the Linear-Bitmap at 0xa000.


As Trebment suggests, a lookup table would be the faster, and if you're making it 128k, you presumably have the memory.


I threw together a bit of a quick stab at calculating directly to video memory if you're interested though - assuming a &4000 base as you mentioned in a previous post and the same registers holding x & y.  Only gave it a quick couple of tests, so it might not be correct or contain oversights, and I hate the presence of the jumps, but the results looked OK.


Code: [Select]
ld c,b


ld l,a
and a,7
ld h,a ; 3 lsb of y need to be multiplied by &800, or 256*8, so this is the *256
ld a,l
and a,&f8 ; 3 msb will be 3 lsb of h, middle two become 2 msb of L
add a,a
rl h
add a,a
rl h
add a,a
rl h
ld l,a
set 6,h ; assume base &4000


ld a,c
ld c,&88
srl a
jr nc,Bit0is0
rrc c
.Bit0is0
srl a
jr nc,Bit1is0
rrc c
rrc c
.Bit1is0
or a,l
ld l,a ; masked in x offset for final screen address

Offline Fessor

  • CPC6128
  • ****
  • Posts: 246
  • Country: de
  • Liked: 239
  • Likes Given: 47
Re: Expanding Elite
« Reply #29 on: Yesterday at 15:29 »

As Trebment suggests, a lookup table would be the faster, and if you're making it 128k, you presumably have the memory.


I threw together a bit of a quick stab at calculating directly to video memory if you're interested though - assuming a &4000 base as you mentioned in a previous post and the same registers holding x & y.  Only gave it a quick couple of tests, so it might not be correct or contain oversights, and I hate the presence of the jumps, but the results looked OK.


Code: [Select]
ld c,b


ld l,a
and a,7
ld h,a ; 3 lsb of y need to be multiplied by &800, or 256*8, so this is the *256
ld a,l
and a,&f8 ; 3 msb will be 3 lsb of h, middle two become 2 msb of L
add a,a
rl h
add a,a
rl h
add a,a
rl h
ld l,a
set 6,h ; assume base &4000


ld a,c
ld c,&88
srl a
jr nc,Bit0is0
rrc c
.Bit0is0
srl a
jr nc,Bit1is0
rrc c
rrc c
.Bit1is0
or a,l
ld l,a ; masked in x offset for final screen address
Yeah, tried that already, but got also garbage on screen and after some lines drawn a crash.But, i think, im looking at the wrong place. Because this changes in the code are shifting the addresses of the Musicplayer i simply uncommented the loading-routines for it to deactivate it this way. But this results in addresschanges earlier in the code and shifting more routines to lower addresses.And somewhere in there must be a routine that reacts allergic to this and maybe expects something on a 256byte-boundary.I tried to start a game with original-draw routines reactivated and outcommented loading-routines, departed from the spacestation, and in rearview got very weird drawing and extreme slowdown before the game crashes.After reactivating the loading of the Musicroutines the game runs normal.
I hate this kind of error...