|
Post by alessandro on Jan 10, 2013 9:34:42 GMT
Is there a way to determine whether a game ends in failure (all lives lost) or success (ENDGAME event), so that when returning to BASIC you could, for instance, load a new level or display a "game over" or "congratulations" screen previously stored in memory?
|
|
|
Post by nra on Jan 10, 2013 12:25:30 GMT
You need some flagged address? Fancy...
Actually, I don't see why not use the AGD message or screen; unless they ALL are used.
|
|
|
Post by alessandro on Jan 10, 2013 14:05:14 GMT
I'll try to explain my request better with an example. Let's suppose I make a game split across different levels. Once the player manages to reach the end of the first one, the machine code returns to the BASIC housekeeping program, which checks whether the previous part has been successfully completed (ENDGAME event) or not, and in the first case it loads the following level from tape or RAMdisk.
Would that be possible, then?
|
|
|
Post by nra on Jan 10, 2013 15:14:28 GMT
Alessandro, it's like a BASIC equivalent of ENDGAME command, right?
Then I would suggest checking (PEEKing) the LIVES variable or setting any A,B,C,D... to a specific keycode, which also can be traced via PEEKing.
Indeed, providing the AGD doesn't reset all the variables at exit.
|
|
|
Post by alessandro on Jan 11, 2013 13:05:40 GMT
Poking memory in a certain location from the game itself as soon as the player reaches the end-of-game screen, could, as far as I know, be possible. The problem is, this would probably require to "hack" the game code and I just don't know how to do this.
|
|
|
Post by nra on Jan 11, 2013 13:14:31 GMT
Alessandro, isn't the AGD code like LET M 10 work like POKEing?
|
|
|
Post by alessandro on Jan 11, 2013 14:55:31 GMT
Alessandro, isn't the AGD code like LET M 10 work like POKEing? All AGD commands POKE something in the Spectrum memory, I guess The problem is, I don't know how to tell exactly which memory address corresponds to each variable in the game script, neither I know whether all variables are deleted after the return to BASIC or not.
|
|
|
Post by nra on Jan 11, 2013 16:40:16 GMT
Alessandro, in a few seconds SpecEmu showed that AGD 3.3 variable LIVES is located at 32031. Although I'm not sure about BASIC...
|
|
|
Post by alessandro on Jan 11, 2013 17:56:17 GMT
It looks quite like so. But how did you manage to discover that the 32031 address holds the LIVES variable? I would never have made it for the life of me Anyway, it seems that variables are not reset once the program returns to BASIC. I ran Apulija-13 and intentionally lost all of my lives. Back to the BASIC frontend program, 32031 contained a value of 0. By starting the game again, 32031 was again set to 3. So variables are defined at the start of game in the Game Initialization event, it seems. EDIT: By playing a bit with the Spin debugger, I managed at least to understand that in Apulija-13 the G (ammunition) variable is located at 32038 and the H variable (health) is located at 32039. However if you hadn't pointed me in the right direction I would hardly have been able to find them myself EDIT 2: It looks like the addresses between 32032 and 32047 hold the values for the variables from 'a' to 'p' respectively. Now, if I could understand where the score is located...
|
|
|
Post by Jonathan Cauldwell on Jan 12, 2013 13:33:36 GMT
The ENDGAME command ends a game successfully. The Completed game script can be used to display a victory screen.
If you want to test for a victory in the calling code/BASIC, the victory flag is 9 bytes on from the last variable. It will be set to zero for failure, non-zero for success.
The byte before the lives counter contains the current screen number, so you could look at this in BASIC and establish just how far the player got into your game before dying, and give him a rating.
The player's score is easy. Instead of starting your game with RANDOMIZE USR 32000, use LET sc=USR 32000. When the game ends the variable sc will point to the score, a six-digit ASCII string.
|
|