Eternal Light 2 - done!

[Morri]

Hi all,
I have been playing around with the sprites alive compiler for the last couple of weeks and have been enjoying the one step up from my low basic programming skills  . I must say it has been very cool seeing my code running at a quicker pace  and this playing around with the program quite unintentionally turned into a simple platform game.
Having next to zero imagination (and being extremely lazy  ) I reused a couple of the sprites from my last game Eternal Light so therefore I have decided to name it the incredibly original "Eternal Light 2" 
Anyway, it has mostly gone well with the compiler producing quite a fast game but I need to ask a few questions.

I have been having trouble with the collision detection. Mainly the main sprite won't trigger collision if he comes from the right hand side (that is while walking left) yet it is fine from the left (walking right). Animation also turns wonky when walking left missing out sequences in the animation, but is fine when walking right. To avoid the problem for now, I have no main sprite animation and have designed my one and only level so that the items can only be collected while walking right but I would like to solve this if possible.

I also have a loading screen I made using convimgcpc and want to add a scrolly to it using BASIC. Does anyone have a routine I could steal  .
I would like to use a font which looks like it's on fire or something similar.

UPDATE! Game is now finished and available for download below... Enjoy!

Cheers,
Morri

[AMSDOS]

I also have a loading screen I made using convimgcpc and want to add a scrolly to it using BASIC. Does anyone have a routine I could steal  .

I'm not quite clear about what sort of scrolly you want. Do you want to Scroll Text on your loading Screen or Scroll the Screen itself using BASIC?


If it's a BASIC Text Scroll you can find one in the June 1991 Issue of ACU. Nich suggests Deleting Line 40 of the Program to Remove the Box & perhaps some Credit where Credit is due, I wouldn't think someone would pull you up on a 10 Liner?

[Morri]

Sorry for not being clear, but yes I meant text scroll. I'll take a look, thanks for the tip.

Also, talking about type-ins, I remember somewhere in AA there being a three colour font routine. Does anyone remember which issue that is in?

[AMSDOS]

Sorry for not being clear, but yes I meant text scroll. I'll take a look, thanks for the tip.

No Worries.

Also, talking about type-ins, I remember somewhere in AA there being a three colour font routine. Does anyone remember which issue that is in?

The one I'm thinking of is in AA56, but that only worked in MODE 1. I'm unsure if they ever did one for MODE 0. Otherwise there's a Split Modes program in AA54 and later on when AA gave away the Devpac Assembler/Monitor on their covertape, there was a Split Modes Source Code Program in their Mastering Machine Code guide (AA75 I'm guessing).

[Morri]

Sweet, thanks for all the leads... Since asking the question I have also had a few other ideas involving sprites alive. Watch this space...

[AMSDOS]

Sorry for not being clear, but yes I meant text scroll. I'll take a look, thanks for the tip.

Actually it's been a while since I've seen that text scroll program, but I suspect it maybe limited to a text string variable (" a$" ?), I think you can extend it if you need more space with something like:

Code Select Expand


a$=a$+"This is my second line of Text"



The other way would be to make an array and have BASIC read it from DATA statements.

[Nich]

Also, talking about type-ins, I remember somewhere in AA there being a three colour font routine. Does anyone remember which issue that is in?

As AMSDOS said, it was published in issue 56 of Amstrad Action. I've attached a DSK file.

It's quite a nice effect if you use a good choice of colours, and it prints faster than the standard MODE 1 firmware routine. The only problems with it are that it only works in MODE 1, and it also sits relatively low in memory (at &6000).

[AMSDOS]

It's quite a nice effect if you use a good choice of colours, and it prints faster than the standard MODE 1 firmware routine. The only problems with it are that it only works in MODE 1, and it also sits relatively low in memory (at &6000).

I was naughty and disassembled the program due to that memory location, I don't think that program in particular has to be within certain memory locations, I had it running up at &9000 I think, though it makes use of &B90B and &B906 and patches &BDD3 to &BDD5 with the address of the routine.


I can hunt down the source I made if &6000 is going to be a problem.

[Morri]

Thank you. I'll take a look at it and see if I can use it somewhere.

[AMSDOS]

Sweet, thanks for all the leads... Since asking the question I have also had a few other ideas involving sprites alive. Watch this space...

Sadly I don't know Sprites Alive well enough to answer your Collision Detection problem, but I thought it might be interesting to run your Sprites Alive program through CBASIC 3.
I was using CBASIC 3 to compile my BASIC source code and using Sean McManus ESD and got great results from it. CBASIC 3 is a little bit limited in that it doesn't support all Locomotive BASIC features, the main one being Floating Numbers, but was very good with RSX routines I found in that case.

[Morri]

I have managed to get a nice simple text scroller working for my intro screen. I found it in AA # 20 and it is basically only 1 line. Very simple.
I modified it to print using the TAG command meaning you can scroll smoothly pixel by pixel (but it is very slow). I choose every 4 pixels as this was the best choice for speed but it is easily adjustable. See below if anyone would like to have a play with it and perhaps improve upon it. I will run the end result through a compiler to optimize it once I am completely happy with it.

Code Select Expand

5 tag
10 a$="              Your text here *"
20 gosub 60
30 a$="              Next bit of text here *"
40 gosub 60
50 goto 10
60 if left$(a$,1)="*" then return else a$=a$+mid$(a$,1,1):a$=right$(a$,len(a$)-1):for a=32 to 1 step -16:move a+64,16;print " "+left$(a$,14);" ";
70 next
80 goto 60

The spaces at the front of each a$ is the length of the string you are printing, in this case 14 chars.
The step -16 is the increments wanted to move the text (smaller numbers = slower, smoother scroll)
The move command is where you want it to be displayed on the screen.

[AMSDOS]

I have managed to get a nice simple text scroller working for my intro screen. I found it in AA # 20 and it is basically only 1 line. Very simple.
I modified it to print using the TAG command meaning you can scroll smoothly pixel by pixel (but it is very slow). I choose every 4 pixels as this was the best choice for speed but it is easily adjustable. See below if anyone would like to have a play with it and perhaps improve upon it. I will run the end result through a compiler to optimize it once I am completely happy with it.

Code Select Expand

5 tag
10 a$="              Your text here *"
20 gosub 60
30 a$="              Next bit of text here *"
40 gosub 60
50 goto 10
60 if left$(a$,1)="*" then return else a$=a$+mid$(a$,1,1):a$=right$(a$,len(a$)-1):for a=32 to 1 step -16:move a+64,16;print " "+left$(a$,14);" ";
70 next
80 goto 60

The spaces at the front of each a$ is the length of the string you are printing, in this case 14 chars.
The step -16 is the increments wanted to move the text (smaller numbers = slower, smoother scroll)
The move command is where you want it to be displayed on the screen.

I was having the "*" appear within that scroll and I'm just wondering if there's a better way of writing that routine. For example the program GOSUB to that routine, but the RETURN is a part of the IF check as it shows and that Subroutine simply loops around (Line 80) until "*" is reached. Would it be better to use WHILE...WEND instead?

[Morri]

I've had a go with the while:wend but can't seem to get it right.  Any suggestions?

[Axelay]

Been ages since I did BASIC coding for anything other than loading... decades in fact!  So, this is bound to awful.

Code Select Expand

5 TAG
10 READ a$
20 WHILE a$<>"*"
30 GOSUB 60
40 READ a$
50 WEND
53 RESTORE 100
55 GOTO 10
60 a$=STRING$(13," ")+a$+STRING$(14," ")
63 FOR b=1 TO LEN(a$)-14
64 FOR a=16 TO 1 STEP -8
66 MOVE a+64,16
67 PRINT " ";MID$(a$,b,14);" ";
68 NEXT
70 NEXT
80 RETURN
100 DATA Your text here
110 DATA Next bit of text here
120 DATA *



If you scroll by entire character steps, you can drop the leading and trailing spaces on line 67 and drop lines 64 & 68.  I thought it should be faster with less string manipulation, so I've used a single MID and a FOR loop to work through the length of the string.

[Morri]

Been ages since I did BASIC coding for anything other than loading... decades in fact!  So, this is bound to awful.

Not a bad effort actually. The Tag version doesn't work unfortunately and for some reason prints down the screen as per the pic.  I think there's meant to be a semi-colon somewhere but when I tried it come up with Syntax errors.



However the non tag version (using locate instead) works nicely. I played around with my routine a bit more last night and got it working good enough to make me happy. But I am always interested in other routines which may / may not improve speeds and smoothness etc...

EDIT: Can't get pic to upload but the text just scrolls down the screen while slowly printing more characters from the string.

[Axelay]

The Tag version doesn't work unfortunately and for some reason prints down the screen as per the pic.  I think there's meant to be a semi-colon somewhere but when I tried it come up with Syntax errors.

Hmm, well I did have to remove the semi colon after the MOVE in your original sample code to get it to run in BASIC.   I'm just using normal BASIC though rather than any compiler, maybe some kind of weird difference there?

[AMSDOS]

Been ages since I did BASIC coding for anything other than loading... decades in fact!  So, this is bound to awful.

Code Select Expand

5 TAG
10 READ a$
20 WHILE a$<>"*"
30 GOSUB 60
40 READ a$
50 WEND
53 RESTORE 100
55 GOTO 10
60 a$=STRING$(13," ")+a$+STRING$(14," ")
63 FOR b=1 TO LEN(a$)-14
64 FOR a=16 TO 1 STEP -8
66 MOVE a+64,16
67 PRINT " ";MID$(a$,b,14);" ";
68 NEXT
70 NEXT
80 RETURN
100 DATA Your text here
110 DATA Next bit of text here
120 DATA *



If you scroll by entire character steps, you can drop the leading and trailing spaces on line 67 and drop lines 64 & 68.  I thought it should be faster with less string manipulation, so I've used a single MID and a FOR loop to work through the length of the string.

I couldn't find anything wrong with that program when I was running it (even the star wasn't printed which I thought was good). Where's this so-called LOCATE version that @Morri mentions?

[Morri]

I couldn't find anything wrong with that program when I was running it (even the star wasn't printed which I thought was good). Where's this so-called LOCATE version that @Morri mentions?

You're right, it works fine. I must have typed it in slightly wrong.  Apologies for this, must have been too many beers when I typed it in. 
The locate version is simply deleting lines 5, 64,66 & 68 and putting in a LOCATE x,y just before line 67.

[arnoldemu]

@Morri:

What functions are you using to check for the collision?
And which for playing the animations?

It would help to narrow down where the problem is.

Can you post a small piece of code?

[Morri]

@arnoldemu

I will do my best to explain how Sprites Alive works for animation. I like using SA as a non-coder because it uses most basic commands (which I'm not even that good at). This is my first go using the compiler version, the first eternal light game used the fully basic version. It might be a bug with the compiler version, as I didn't have this issue with the basic version but the animation and collision detection don't seem to work with the main sprite moving left (right is fine for both).

The commands used to set up the animation are the SEQUENCE and ANIMATE command. SEQUENCE assigns drawings to the several directions (up, upleft, left etc..) and ANIMATE links that sequence to a sprite. i.e ANIMATE 0,0 links sprite 0 (the joystick controlled sprite) to sequence 0.

Collision detection is used with the REPON (reporting on) command. The main sprite, enemy sprites, items to collect etc must all use the REPON command for collision detection to work. COLLTEST, HIT and SMOVEHIT are commands used to determine which sprites have collided.

Below is the part of my code that sets this all up, along with added comments.

Code Select Expand


7 .SPRITES:' Compiler version uses labels. i.e. goto SPRITES instead of GOTO 7
8 STIX 12:' Control Sprite 0 with Joystick. Value 12 = Left and right only.
9 SGET 0,2:' Assigned drawing 2 to sprite 0 (main sprite). Drawing 2 is the sprite facing right.
10 REPON 0:' Turns on collision detection for sprite 0.
12 STIXSPEED 1,1,1,1:XEDGE 0,2: 'The number of pixels the joystick controlled sprite will move in the four directions. xedge tells sprite 0 to stop at the edge of the screen, other values can be wrap or disappear.
13 WINDOW 0,1,190,0,167:' The screen are sprite 0 can move within.
14 SEQUENCE 0,0,1,0,1,0,1,0,1,2,3,2,3,2,3,2,3:' assigns drawings for all 8 directions to sequence 0. This sequence only defines left and right movements. Every direction must have values even if not used.
15 ANIMATE 0,0:' Links sprite 0 with sequence 0.


If you are interested, I can also PM you a DSK with all of my source code, sprites alive compiler so you can see the problem yourself.

[arnoldemu]

Please can you send me a download for a compiled runnable version of the game? It makes it easy for me to debug.

[Morri]

Well this is embarrassing.  I compiled the code to give to you and now everything (both the animation and coll detect is working! Very puzzling. I can't work out what's going on.  The only difference is I have been writing and compiling the program on my desktop whereas today I compiled on my laptop, but I downloaded the same version from the CPCWiki.

Thanks for the offer to help and debug but while it's working I'll think I'll just carry on. I'll update if anything else weird happens.

[AMSDOS]

Well this is embarrassing.  I compiled the code to give to you and now everything (both the animation and coll detect is working! Very puzzling. I can't work out what's going on.  The only difference is I have been writing and compiling the program on my desktop whereas today I compiled on my laptop, but I downloaded the same version from the CPCWiki.

Thanks for the offer to help and debug but while it's working I'll think I'll just carry on. I'll update if anything else weird happens.

If the file was downloaded at different times then you might have picked up a corrupt copy. That's what happened to me when I tried Downloading your Patched version of The Eternal Light, though the disk image in that case was getting corrupt when I tried downloading from Safari, but had no problems with Google Chrome.


Just a thought though.

[Gryzor]

You mean from the wiki? Highly unlikely. I've downloaded countless files and I never, ever had a problem, with various browsers and from different systems.

[arnoldemu]

Different emulator on each or different versions of the same emulator?