News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Fessor

Expanding Elite

Started by Fessor, 18:15, 21 July 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ygdrazil

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

Quote from: Fessor on 19:44, 31 July 21I 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

Fessor

Quote from: Ygdrazil on 10: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 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.

    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

Trebmint

#27
Quote from: Fessor on 00:35, 03 August 21
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.

    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

Axelay


Quote from: Fessor on 00:35, 03 August 21Actual 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.



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

Fessor

Quote from: Axelay on 11:37, 03 August 21

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.



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...


Fessor

#30
So, after many crashes i managed to patch the linedrawing-routines to draw to screenmemory.
A clearly noticeable increase in the fps, but just as clearly noticeable drop when there is a lot to be drawn.
But that is also noticeable in the unpatched version ...Its not playable and only a demonstration of how much fps we could get with doublebuffering.Simply start ELITEP.BAS

I hope that somebody with better knowledge will take a look at the drawing routine when I publish the source, for possible optimisation. At least it works ...

Thanks to https://www.bbcelite.com/ I am a bit torn as they explain the code of the BBC version very well and also how the different versions have been expanded. And then that brings me to the shipsets. Even if the BBC's disc version has all ships, not all of them are available at the same time, only a part of them. Depending on the tech level / government of the target system, other ship models are used to fill roles. Pirate ships like the Krait or Sidewinder are replaced in more dangerous systems by stronger opponents like Mamba or Gecko. Basically, only one set of 15 ship types is currently active.
https://www.bbcelite.com/deep_dives/ship_blueprints_in_the_disc_version.html

Our disc version should now also be able to be adapted, like the BBC version, not only to determine the color variation and positioning of the planet, the sun and the space station when entering a new system, but also which ships are allowed to appear in this system and then load the table and ship definitions accordingly.

I am still missing the meaning of a few data fields in the ship definitions, I might find out when looking through the code.

It may open the way to create a disk version for the 464 that contains all ships, but remains with the current graphics with offscreen buffer.
And a version for 6128 with double buffering and data storage in the memory banks so that there are no interruptions due to the loading of data, depending on the situation.

nivrig

Amazing work so far!

Fessor

#32
In the attachment you will find my current working version for the RASM assembler. About 30% of the functions are identified. Please do not publish on other sites.
(I wish RASM could output a new, cleaned up listing of the active code passages without the passages switched off with if / ifnot)
I don't understand the math routines with their tables in order to label them properly. My adjustments to the line draw routine are also a quick hack. I hope that someone with better assembly knowledge can take a look at it and possibly improve it.
For Textprinting and Circledrawing they have switches where to draw (offscreen or in screenmem), for linedrawing unfortunately not.But with possible switch to double buffering, these are code passages that can be dropped and a lot of bytes can be used for other purposes
In the structures there are some flags whose meaning I have not yet identified, but which apparently control the behavior of the AI.


Fessor

Attached is a fresh version with bug fixes in the naming of some labels and other revealed functions.
For the ship slots I have set field labels everywhere to make it easier to debug how the flags change.
I'm hoping that something like a destination number would appear in the flags. But unfortunately that only seems to be the case with the missiles so that they know which target they have to fly to.

I think it would be nice if the ships could fight with each other.
So I uncovered and looked at the subroutines for firing the laser.
When firing the own laser, the status of the hit target is set to hostile and only one other flag is changed, but apparently no record of who hit the target.
The hostility seems to be directed against the player only.
So next I have to find the subroutines for the behavior of a hostile ship. After all, there must be variables so that the opponents know what to shoot at.

Fessor

I just converted this https://www.bbcelite.com/disc/flight/subroutine/lships.html
Routine for an extendend Disk Version to support different Shipsets
    call getRandomNumber
    and 3              ; to get four different Shipsets for a System
    ld b,a                     
    ld a,(Government)  ; sort out after dangerousness
    cp 3               ; 0..3 Feudal to Dictatorship
    rl b               ; rotate Carry into LSB of Reg B
    ld a,(Techlevel)   ;
    cp 10              ; Advanced Systems have a Dodo instead of a Coriolis
    rl b               ; rotate Carry into LSB of Reg B
    ld a,b             ;
    add 'A'            ; To get a valid Char for the Filename

That gives a nice Matrix, basing on 2bit Random, 1 bit for Government and 1 bit for Techlevel

Zaonce: Corporate State, Techlevel 12:    A,E,I,M
Lave: Dictatorship, Techlevel 5:                B,F,J,N
Xezaor: Multi-Government, Techlevel 11: C,G,K,O
Zaalela: Feudal, Techlevel 5:                    D,H,L,P
A first Run with Files containg the Dodo or containing the Coriolus was successfull
At entering the Hyperspace it now loads one of the four possible Shipsets for the System.
Now its time to convert the Shipdata and look how to fill the Tables.


MaV

Hi!


I looked at some of the tables in the sources. The ones at 0x4600 (low byte values) and 0x4700 (high byte values) together form a quadratic table it seems.
I added a HTML/Javascript file in the ZIP that draws the length in a window (1080p screen preferred). The graph with the many peaks are the values of 0x4600, the smaller curve the values of the table at 0x4700, and lastly the big curve contains the values of the same indices from both tables combined (table1-index + 256*table2-index). I divided the results of the latter values by 75 to make the whole graph visible in the browser.


MaV
Black Mesa Transit Announcement System:
"Work safe, work smart. Your future depends on it."

Fessor

So, in the attachments is the first beta of the extended disk version for all CPCs as well as the current source code. Please do not upload to other sites as it is not the final version yet. (Actually only the music player needs to be adjusted).

What has been expanded / changed:
- Splashscreens 1 and 2 revised, Splashscreen 2 is now a showcase similar to the 16bit Elites.
- The mechanics of the BBC disk version, which reloads various shipsets, have been reproduced.
- In the savegames it is now noted which shipset is active, they are therefore incompatible with the officially published versions, so you have to start a new career.
- Routines for loading / saving savegames in order to be compatible with future changes to the game (encryption against program code deactivated)
- Unused code commented out and a little over 1000 bytes gained. This may be enough to retrofit the two missing missions (Hunting the Constrictor / delivering Thargoid-Plans), but I have to take a closer look at that in the BBC code.

Fessor

Another small experiment to better estimate the memory requirements: Localization
It would have been too easy to simply copy the tables from the other language versions ...
Seems that the French version has extra code to create the special characters and some text placements seem to be hard coded ...

Fessor

With the next release, a potential crash will be fixed, which can rarely occur if you let the showcase run longer in the second splash screen. Even if it looks clean to save the loop counter for djnz with push / pop, strangely enough it is possible to break out from time to time by pressing the space bar and leave the stack in a faulty state.
(The showcase has also been refined a bit and now takes into account their individual maximum view distance)

I think I will also switch off this "Boarded by Pirates", which can rarely occur every now and then when docking, as it is extremely annoying when you have just barely survived several fights and have just reached the space station with a heavily collapsed spaceship (destroyed docking computer, destroyed energy unit, fuel leak ...) and then get a game over with this message ...
This event is no fun and IMHO just annoying.

genesis8

I didnt know there was this game over in Elite.
Any news about this next release ?
____________
Amstrad news site at Genesis8 Amstrad Page

stevensixkiller

Quote from: Fessor on 12:33, 05 September 21
Another small experiment to better estimate the memory requirements: Localization
It would have been too easy to simply copy the tables from the other language versions ...
Seems that the French version has extra code to create the special characters and some text placements seem to be hard coded ...
Not speaking for all french people here but i think this is perfectly understandable without the accents. I suppose some products description could be abbreviated or adapted: Prod. de luxe,  Prod. Aliens instead of Prod. Etrangers, Spiritueux instead of Vins/Liqueurs. Nice work!

Fessor

Progress is extremly slow at the moment, to say at least. Since my last Post I had shot down my Gitbucket with an update on my NAS, it took a lot of time to get it running again without losing my repositories.

To a certain degree I fixed the new splash screen so that Elite doesn't crash here anymore. However, I have not yet managed to arrange the code in such a way that banking works as a prerequisite for doublebuffering.  I suspect it's because some functions have their own stack areas and are allergic to this.
The title music also does not want to be integrated yet. Although the code for the intro overwrites unused routines in memory and is called in the interrupt for the color split as before, something is not compatible with "my" new splash screen and after a few iterations the stack is corrupt, although the code actually looks clean.

In between, I also took a closer look at the French language version; they added four more text functions there for the accents and some string numbers changed as a result.
I've also started to take a closer look at the German language version, there are even bigger differences in the string numbers. But I didn't look to see if there were any major differences in the code compared to the English/French version yet.

It's a Sysiphus task to rework all the text calls and replace the still hard-coded string numbers with equates in the first pass for the english Version

    CALL printFollowingTokenWithSpace
    db 3

to

    CALL printFollowingTokenWithSpace
    db token03

And then defining the Lists for the French/German Version.I hope that there are no differences in the keyboard query of the versions, but I haven't looked at it yet.



simulant

I also just want to show my support for this project. Having a disk version of Elite on the CPC as good as the BBC original and using the full 128K with all the ships etc would be incredible. I hope you can continue to get support from the community and work on this for a finished release one day.
Amstrad BBS - https://amstrad.simulant.uk

Amstrad Hardware & Software: https://www.simulant.uk/shop/

Fessor

The minimum goal of having the complete shipset from the BBC was achieved. The last disk version should also work on machines with 64k.

128k would only be necessary for the expected performance increase through double buffering, the development of which was halted at the time due to health problems.

In preparation for double buffering, I had started trying to relocate the code in order to move the screen memory from bank 3 to bank 1. But I never managed to get a version that worked.

To make matters worse, after a QNAP firmware update, my GitBucket no longer wanted to work and I was in danger of losing my code. (I was only recently able to restore my repository by switching to Gitea)

The roadmap was:
- Undo changes in the intro screens, as the showroom of the ships caused a crash after some time, for whatever reason. 
- Relocate code in preparation for double buffering
- Line draw routine for CPC screen memory
- Circle draw routine for CPC screen memory
- localization (German/French)

I actually expected the greatest difficulty to be the circle draw routine for CPC screen memory. The developers have written a circle draw routine for the CPC screen memory organization, which displays the fuel range in the local and galactic chart, since these views are written directly to the screen RAM when docked.

Unfortunately, it has no clipping function and a circle is simply not drawn if the drawing would exceed image boundaries (observable when you visit the system at the edges of the map). They probably just ran out of memory. For the display of the sun and the planet during flight, it is of course unpleasant if the objects simply disappear from the screen when they reach the edge of the image. (It would have been too good to be able to use an existing function).

In any case, based on my own knowledge of assembly language, I consider this to be the biggest challenge (besides relocating the code)

Unfortunately, I currently lack the enthusiasm to revive the project

eto

Quote from: Fessor on 14:07, 23 May 24Unfortunately, I currently lack the enthusiasm to revive the project
I can imagine... too sad as I would loved to see the best 8bit version on the CPC :-)  But thanks for trying, Elite was probably THE most impressive game for me on the CPC. 


The latest version is the one posted on Sep 21st? 

Would you consider it playable or are there major bugs which prevent that?

Fessor

Quote from: eto on 16:18, 23 May 24
Quote from: Fessor on 14:07, 23 May 24Unfortunately, I currently lack the enthusiasm to revive the project
I can imagine... too sad as I would loved to see the best 8bit version on the CPC :-)  But thanks for trying, Elite was probably THE most impressive game for me on the CPC.


The latest version is the one posted on Sep 21st?

Would you consider it playable or are there major bugs which prevent that?
The version is completely playable. You just have to start a new game because I deactivated the encryption of the save game.

The only bugs I know of are that after a while it crashes in the second splash screen, which I expanded into a showroom to show the current shipset.

And that it crashes when using CubeMDOS. CubeMDOS doesn't seem to like it when Elite copies the firmware area with the floppy routines. But that's also the case with the "original" Elite.

GUNHED

Hope you'll find time and energy to go on with this great project one day!  :) :) :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Fessor

To a certain extent, almost all graphic functions, except for line drawing, have been converted to work with screen memory at address 0x4000.

Circles and space dust just don't clip properly in the viewport area and the position calculation of space dust is still too focused on addressing the linear offscreen buffer and the particles jump wildly back and forth between the lines.

It is a nice feature of ACE-DL to be able to open multiple GFX Explorer windows and monitor the screen memory and the offscreen buffer at the same time.
You cannot view this attachment.

xesrjb

Quote from: Fessor on 15:50, 09 June 24To a certain extent, almost all graphic functions, except for line drawing, have been converted to work with screen memory at address 0x4000.

Circles and space dust just don't clip properly in the viewport area and the position calculation of space dust is still too focused on addressing the linear offscreen buffer and the particles jump wildly back and forth between the lines.

It is a nice feature of ACE-DL to be able to open multiple GFX Explorer windows and monitor the screen memory and the offscreen buffer at the same time.
You cannot view this attachment.
Cool...

xesrjb 
,,The pellet with the poison's in the vessel with the pestle; the chalice from the palace has the brew that is true."

Fessor

#49
Quote from: Targhan on 08:38, 22 July 21Very cool. But since you now have more memory, maybe revamp the game a bit more and add, for example, music? Like "battle" music when enemies are encountered, "docking" music, "station" music, etc. Could be interesting. But that implies being able to detect such situation, which may not be so easy.
The detection for this Situations is already there: Docked-Mode and In-Flight-Mode with Conditions Green/Yellow/Red/Flashing Red, Fuel-Scooping, Station detected...

Actual Elite needs almost every byte of memory in the game loop and swaps code areas during takeoff and docking. There is currently no space in the RAM for a music player with data.

First of all, I have to get the double buffering to work. Once that's running, I can do code cleanup and see which routines are suitable for being moved to memory banks.
IMHO, all the routines for the info screens don't have to be kept in the central 64k at the same time and should be able to be changed so that they each use the same address range and can be overwritten at any time so i can see if it frees up space in the main 64k to replace also the built-in interrupt-driven SFX-Routines with something like Arkos.
But, as this is beyond my skills, someone would have to redefine all the SFX and Tracks for the different situations. At the moment I can't estimate how much space that would need and how much I can free up.

Powered by SMFPacks Menu Editor Mod