Hello all, good to see something is running again...
I have almost finished my BASIC / Sprites alive game "Eternal light" it's actually not too bad considering it's only BASIC and that I haven't programmed anything in over 15 years...
I'm just a little stuck with my end credits.
My main code is full. So full that if I add 1 more line of basic I get "memory full" messages. If you complete the game I run a file which has a screen, tune and messages.
My problem is that I get "improper argument" messages if I use a "symbol after" command (I have a font I want to use in the credits)...
I can't fix it. And I sort of guess it has to do with already using "memory" commands in the other files.
Does anyone have any ideas of how to fix it. Once this problem is solved I can release the game...
Thanx
You surely work fast mate.
How about just loading the end credits when you complete the game?
Hey Mr Lou...I do, it goes :if items=10 then run"endgame": but thats when I get the error message.
Quote from: Morri on 12:48, 08 March 09
Hey Mr Lou...I do, it goes :if items=10 then run"endgame": but thats when I get the error message.
Oh... what about...
if items=10 then clear:run"endgame"
Does that make a difference?
Hi Morri
Really looking forward to your production ..
If you intend to make the game run from disc only. You could chain merge the different parts of the game. Eventually store vital game data to temporary data files. This way you wouldn't have to have all of the program in memory once and only limit is the amount of disk space.
Quote from: Morri on 12:11, 08 March 09
My problem is that I get "improper argument" messages if I use a "symbol after" command (I have a font I want to use in the credits)...
I can't fix it. And I sort of guess it has to do with already using "memory" commands in the other files.
Does anyone have any ideas of how to fix it. Once this problem is solved I can release the game...
Once a MEMORY command is used, the font matrix table (if it exists) cannot be redefined or moved to another location.
However, you should be able to get around this by using the command SYMBOL AFTER 256 before using the MEMORY command. This will erase the current font matrix table. When you run the credits program, you can then use SYMBOL AFTER 32 to create a new font matrix table without getting an "Improper argument" error.
Hopefully this will solve your problem, and I look forward to seeing the final release!
]
QuoteOnce a MEMORY command is used, the font matrix table (if it exists) cannot be redefined or moved to another location.
However, you should be able to get around this by using the command SYMBOL AFTER 256 before using the MEMORY command. This will erase the current font matrix table. When you run the credits program, you can then use SYMBOL AFTER 32 to create a new font matrix table without getting an "Improper argument" error.
Yes thanks that worked, I knew it was something like that. ::) But now I get a memory full (again!!!) >:( from the symbol after 32 command. I have tried clear but it makes no difference. Is there any other techniques to flush the memory.It is a completely separate file to the main code using ...clear:run"endgame"If not I will have to have a password system to run the end credits but that isn't ideal. (sounds pretty rubbish actually)[/]
I figured it out!!! All working start to finish. I just want to play it right thru and make sure as much is right as possible. Hopefully post tonight or else tomorrow.
You should put some betatesters to test it before releasing it. It's 100% certain there are many things you as the developer will never spot.
Betatesters can give you feedback and suggestions to alternative ways of doing certain things.
I'll sign-up for a beta :P
Count me in :)
Quote from: psychris on 11:01, 09 March 09
I'll sign-up for a beta :P
Me, too, please ;)
thank you for all the interest. I am happy with testing done by Mr Lou. who also helped compose tune/s for the game. You all will get a chance to play soon enough because after tweaking a few small things I'll post the dsk. Just give me a couple of days :)
well here it is, I've finished the game.It took me about 6 months total. A complete nervous breakdown and a couple of nice cold beers, but it's done. phew. In all honesty, it would have been better if I was actually a coder but for a complete dumb dumb it's OK.Now, before everyone rips me a new one about the games failings please remember, it's all BASIC so I ran out of memory after writing the intro screen!!! Please enjoy it for what it is, and please code more stuff yourselves for our beloved CPC's.Thanx...http://www.megaupload.com/?d=18D5K7NI (http://www.megaupload.com/?d=18D5K7NI)
Yay - it's released! I'm getting ready for work at the moment. So I may just have to have a quick play when I get there ;D
Ha! This is so cute!!! I'll play a while in the afternoon but it looks sweet :)
Things I've noticed: the player sprite should probably move a bit faster, and the screen should update a tad quicker, too (yeah, I know, Basic, but still...).
I'm attaching here, if you don't mind. I'll also announce it on the wiki :)
Ha, I didn't realise you could just attach files, cool.
Quote from: Gryzor on 08:15, 10 March 09
Things I've noticed: the player sprite should probably move a bit faster
I know, it is possible but weird stuff starts happening ??? For instance one time I shot myself by running into the bullet which was going in the same direction as me. So I offset the missile a bit further away but then the missile missed anything too close to you if you were standing still.The other thing that happened was you could push the enemies around if you were moving, the collision detention would only work half the time. I couldn't get that right either. Therefore the speed that the character goes...
Quote from: Gryzor on 08:15, 10 March 09
and the screen should update a tad quicker, too (yeah, I know, Basic, but still...).
Yes, I worked hard to get that going faster but couldn't do it with BASIC. I'm actually using an RSX command so it's partly machine code with scenery poked and peeked in all the right places ;) but alas this was the fastest I could get it...
Quote from: Morri on 08:58, 10 March 09The other thing that happened was you could push the enemies around if you were moving, the collision detention would only work half the time.
I owned Sprites Alive which is why I was keen to complete Space Froggy. That game suffers from exactly the same issues - slow moving main character, iffy collision detection which means enemies can be pushed around, etc.
I'm guessing Eternal Light is made entirely using the Sprites Alive extensions? Any chance of releasing the source code? I'd really love to load this up myself with Sprites Alive.
I had a quick play for a few minutes and it looks good, I'm gonna have fun playing this. One feature request, please could keyboard alternative controls be added? The reason being that using Arnold emulator on the Mac, I haven't been able to get the joystick mapped to the keyboard. It kind of works, but uses very strange keys which only a contortionist would be comfortable with.
yes sprites alive pretty much runs the whole show.As for the source code, it's not really that well protected. I just used the utility managedsk - http://amstrad.cpc.free.fr/download.php?op=mydown&did=8 to hide and protect files. I never used the sprites alive compiler because I couldn't get it to work. Everything is still in Basic.
Some are getting an error message when using run"-story" I corrected that bug.New dsk image here.
Hi Morri, I was previously getting the error message when using run "-story". I'd assumed this was intended and used run "eternal" instead. Anyway, the updated dsk image fixed this, thanks.
I've had a fun evening. I found a "type in" to unprotect the source code and I changed code.bas to use sprite 1 instead of sprite 0 for the main character. By default, this uses the cursor keys + space bar instead of the joystick and worked perfectly.
Great game! I really enjoyed playing this. I'm deliberately avoiding posting any spoilers here for now :)
When endgame.bas loads, the "typewriter" text doesn't show using the Arnold emulator on the Mac (Intel) with default settings. The image appears and music plays. If I set the emulator to run as fast as possible, the text does show, albeit rather quickly. I'm guessing this is a timing issue.
Anyway, thanks for making the game.
Quote from: psychris on 01:05, 11 March 09
Hi Morri, I was previously getting the error message when using run "-story". I'd assumed this was intended and used run "eternal" instead. Anyway, the updated dsk image fixed this, thanks.
I've had a fun evening. I found a "type in" to unprotect the source code and I changed code.bas to use sprite 1 instead of sprite 0 for the main character. By default, this uses the cursor keys + space bar instead of the joystick and worked perfectly.
Great game! I really enjoyed playing this. I'm deliberately avoiding posting any spoilers here for now :)
When endgame.bas loads, the "typewriter" text doesn't show using the Arnold emulator on the Mac (Intel) with default settings. The image appears and music plays. If I set the emulator to run as fast as possible, the text does show, albeit rather quickly. I'm guessing this is a timing issue.
Anyway, thanks for making the game.
cool. I think you might be the first to complete it. Mr lou may have cos he had it a day earlier than everyone else but I'm not sure... glad you figured out how to change the code for keyboard. Maybe you could post the dsk image for those who have the same problem with the joystick. A keyboard hack version if you will. :) Weird how the text doesn't work, I didn't test it with Arnold, I used WinApe and JavaCPC and it worked on those so I assumed it was OK.
Also speaking about the tunes and the images, I want to publicly thank Mr Lou for his two contributions in the sound department. He is an amazing composer and the tunes he wrote suited the game down to the ground. They really lifted the game and set the mood. Thanks again mate, you're a champion... ;) So if you haven't done it already check out his websites and some of the stuff he's done.
http://www.dewfall.dk/ (http://www.dewfall.dk/)
http://www.lublu.dk/ (http://www.lublu.dk/)
http://www.indiegamemusic.com/ (http://www.indiegamemusic.com/)
Thanks for the nice words Morri. :)
I haven't completed the game yet. Been a little busy lately, so I'm saving it for a cozy evening with the real machines. That way it's easier to get in touch with the atmosphere and the story. So I'm looking forward to that. :)
Congrats Morri :) Pretty cool game, with a nice design... :)
Agreed that the overall design is really good, including the music, graphics and levels.
I thought Arnold would be updating the dsk image as I made changes last night. Otherwise, I would have expected a read-only error message. When I exited the emulator, it offered to save and I accepted. However, the dsk image wasn't modified at all so all my changes were lost. It was late, I wasn't that bothered and I'm not sure anyone else would benefit from non-joystick support anyway. Arnold is almost great but just doesn't make sense (to me) at times. Although, it's way better than nothing when it comes to CPC emulation on the Mac.
Eternal Light has inspired me to make my own game which is pretty cool. I haven't decided which platform yet or what form it'll take. I do know that all the crazy memory juggling on the CPC makes me nervous ;D
Haven't had much time (been renovating an apartment, sigh...), but I've been dipping in and out and I have to say, except for the issues I mentioned, it's a top-class little game... Congrats again!
@Psychris Well, you could always do it on the PC but with CPC-style gfx, as we've seen before! That's be sweeeet!
Quote from: psychris on 11:45, 11 March 09
I thought Arnold would be updating the dsk image as I made changes last night. Otherwise, I would have expected a read-only error message. When I exited the emulator, it offered to save and I accepted. However, the dsk image wasn't modified at all so all my changes were lost.
Yea, it seems to be a Linux issue. The same happens when using Caprice.
I already informed the author of Arnold about this, and I believe it's on his Look-Into list.
Quote from: psychris on 11:45, 11 March 09
Eternal Light has inspired me to make my own game which is pretty cool. I haven't decided which platform yet or what form it'll take. I do know that all the crazy memory juggling on the CPC makes me nervous ;D
That's great! What languages do you know? For CPC development, if you know a little C and/or Assembly, you should take a look at z88dk.org (http://www.z88dk.org/forum/) and CPCRSLIB (http://www.amstrad.es/programacion/cpcrslib_eng.htm) to go with it. Building it in C makes it relative easier to port to another platform later.
What platforms are interesting for you? Mobile phones? Gamepark? Flash? Java?
Make a new thread about your development when you get started. :)
Homebrew rocks. I'm looking forward to spending some evenings with Eternal Light. Morri, you could write to Retro Gamer Mag (http://www.retrogamer.net) at retrogamer AT imagine-publishing DOT co DOT uk (e-mail address to write to for suggesting homebrew projects for them to review). Someone must have written them, because surprisingly they reviewed our game Sort'em (http://lublu.dk/filer/sortem.dsk) in issue 61 on page 105. That was neat! :)
Quote from: mr_lou on 12:30, 11 March 09
That's great! What languages do you know? For CPC development, if you know a little C and/or Assembly, you should take a look at z88dk.org (http://www.z88dk.org/forum/) and CPCRSLIB (http://www.amstrad.es/programacion/cpcrslib_eng.htm) to go with it. Building it in C makes it relative easier to port to another platform later.
Hmmm... Not sure. A modern alternative to Sprites Alive for the Mac would be ideal.
Nice work Morri, and Mr_Lou! :)
@psychris: What version of Arnold are you using? The previous version had a bug where you couldn't save to disk images, but this was fixed late last year ( v1.7.8 ). Also, crazy memory juggling is fun! ;)
If Eternal Light is to be ported to e.g. the Gamepark, then here's a MOD version (http://dewfall.dk/other/Forge.mod) of the main theme ready. :) It sounds about 94% like the CPC version.
Quote from: mr_lou on 14:23, 11 March 09
If Eternal Light is to be ported to e.g. the Gamepark, then here's a MOD version (http://dewfall.dk/other/Forge.mod) of the main theme ready. :) It sounds about 94% like the CPC version.
Heh, lovely mod... made me all cheerful :)
Quote from: Axelay on 13:40, 11 March 09
@psychris: What version of Arnold are you using? The previous version had a bug where you couldn't save to disk images, but this was fixed late last year ( v1.7.8 ).
Yep, using version 1.7.8, downloaded yesterday. I think the problem was caused because I ran Arnold directly from the DMG file. I didn't extract the application in my excitement to play Eternal Light. Anyway, now I'm running Arnold properly, it's updating the disk image fine so I'm guessing it's something to do with security.
Hi,
Did someone actually managed to play this game on a real CPC ? I tried both DSKs :
- On the first one, I couldn't run the story, but the game ran *almost* fine (with a buggy music, far too slow, and some artifacts on the screen).
- The second one, the story works fine, but the game crashed when initialising the levels (artifacts on the screen, then freeze). I thought it was because of the Ramcard or the CPCBooster, so I disconnected everything, but it still doesn't work.
Is there a third version available ? :)
Thanks,
Targhan/Arkos.
Hm, interesting, I think I'll try it tomorrow... What machine did you run it on?
CPC 6128.
Quote from: Targhan on 19:35, 13 March 09
CPC 6128.
Same as Targhan here... I tested in 2 CPCs 6128 (crtc type 0 and type 1). Game displays the intro-screen and when it tries to load the whole game in memory, it just crashes...
Hello,
I have tried the game on my CPC Plus, and, like other players, it crashes.
You should not initialize the Sprite routines before putting datas in extended memory (file EXTERNEL.BAS), Sprite Alive seems not to like it :-).
So, to correct the bug, put your CALL &7000 in the line 16. Doing that, the game loads correctly and seems to be ok.
T&J/GPA
thanx for the feedback on the real CPC's. I haven't had a machine for over 15 years :'( so I never could've tested for that little bug without your help. :) New version 1.02 below with a few changes in the intro screen because of what the call 7000 did.
No real CPC? Oh man, you need to change that... :D
Hello,
The game seems now to be ok. I say "seems" because I have experienced several crashes in the menu, but this time, I have no "software" explanation. The problem seems to stop when my Hacker is physically unplugged...
So, I managed to play the game and finish it. You have made a good job for a first game : nice graphics, nice music, the only big lake is the animation (damned Sprite Alive) that is too slow and not very smooth. Anyway, thanks for this good time on my cpc. Hope to see in a near future another production from you :-).
T&J/GPA
Quote from: Morri on 20:19, 14 March 09
thanx for the feedback on the real CPC's. I haven't had a machine for over 15 years :'( so I never could've tested for that little bug without your help. :) New version 1.02 below with a few changes in the intro screen because of what the call 7000 did.
So I finally tried it on my real CPC, but I can't get it working neither on my CPC6128 or my CPC464 with 64k expansion.
On the CPC6128 it crashes/resets just as the menu music begins. By deleting line 80, it doesn't crash - until I press fire. It doesn't reset though. The screen just freeze with different colors.
The CPC464 will never run it, due to CPC6128-only commands, like CLEAR INPUT and such. The very first |draw,"sprites" doesn't work on the 464 either for some reason. But never mind the CPC464. It could be neat, but not insanely important.
Why doesn't it work on my CPC6128? :(
Hi there :) Great game, morri, but I have the same problem as Mr_Lou in CPC6128, the game hangs in the main menu when music starts to sound. Some corrupt lines appear too.
Yes great game!
Runs in emulator! But not when transfered to old faithfull 6128
/Ygdrazil
Quote from: MiguelSky on 12:16, 09 April 09
Hi there :) Great game, morri, but I have the same problem as Mr_Lou in CPC6128, the game hangs in the main menu when music starts to sound. Some corrupt lines appear too.
Hmmm, I am sorry the game doesn't seem to work on real machines. I don't have a real cpc so i could never test the game to work out all the bugs. I really have no idea :-[ . It may have to stay as it is unless someone is willing to look at it and make their own changes to make it go...
Hey, when is someone going to fix this game so it's playable on a real CPC?
Anyway, I've made a MIDI version of the theme (http://dewfall.dk/other/Forge.mid), so now it's ready for a JavaME port. 8) (Note: Not all soundcards support the chip-sound emulation).
I also have a MOD version (http://dewfall.dk/other/Forge.mod) for a Smartphone port.
Get to work coders! :)
Just recently got a 3 1/2 drive on my 6128, so thought I'd have a bit of a look at this. I'm afraid it looks like Sprites Alive itself is the issue, as my 6128 will crash with just this part of the loader, followed by what I presume would be necessary to begin playing the music if it were loaded:
memory &5b00
load"sprite.1",&7000
call &7000
memory &3fff
out &7f00,&c5
Just doesnt like that memory being banked, though all appears well when I try this in Winape set to a 6128.
Quote from: Axelay on 16:39, 26 May 09
Just recently got a 3 1/2 drive on my 6128, so thought I'd have a bit of a look at this. I'm afraid it looks like Sprites Alive itself is the issue, as my 6128 will crash with just this part of the loader, followed by what I presume would be necessary to begin playing the music if it were loaded:
memory &5b00
load"sprite.1",&7000
call &7000
memory &3fff
out &7f00,&c5
Just doesnt like that memory being banked, though all appears well when I try this in Winape set to a 6128.
Hmmm.. good work to find this. Maybe "sprites alive" is using interrupts?
Maybe it is possible to move the initialisation of the music and then setup a new function to call the music.
I'm a bit confused, I've seen a few versions of this game floating around. I downloaded Eternal102.DSK from here, though I also had a Modified Disc from CPC-Power with a slightly altered game which made it possible to collect 9 of the 10 Lanterns without getting help from the Lady, though I got to the endgame bit and it was buggy. :(
Anyhow I made a 464 Compatible Version (it still needs 128k), wasn't sure how the issue with the Real Amstrads was settled (looked like it was), though I'm not sure if I've just used an old Emulator compatible version of the program. Of course I don't have a Real 464 to test it on. ??? It's just annoying the endgame bit isn't working. :(
I didn't even know the game has been fixed to work on the real machines. I'd love to play this game, but never have because it initially only worked on emulators. I've tried it on the CPC464, CPC6128 and my new CPCplus, and it doesn't run on any of those machines. Are you telling me it does now? If so, please gimme a link or two.
Quote from: mr_lou on 15:14, 09 February 13
I didn't even know the game has been fixed to work on the real machines. I'd love to play this game, but never have because it initially only worked on emulators. I've tried it on the CPC464, CPC6128 and my new CPCplus, and it doesn't run on any of those machines. Are you telling me it does now? If so, please gimme a link or two.
I'm sorry, I'm not sure, I was reading [user]TomEtJerry[/user] response and got the impression the program was fixed to work on a Real Amstrad. I downloaded "ETERNAL102.DSK" which I thought was the fix, now I'm not sure. That Disk Image though is different from the one on CPC-Power (http://www.cpc-power.com/index.php?page=detail&onglet=dsk&num=3905), I downloaded the Modified Disk Image which presented me with a File which asked me if I wanted to Read the Story & Allow Infinite Lives. It was that Disk Image I used to run on a 464 in Winape, though like the author don't have any way of testing it on a real 464. :( Obviously the 464 Still needs 128k, I've only made the program BASIC 1.0 Compatible.
I guess if programs like this are exposing flaws which don't normally work on a Real Amstrad, then I guess they will have to start simulating these sorts of bugs - dare I say, that sounds difficult. :(
As a JavaME developer, I quickly learned a golden rule: Never ever trust emulators when developing. ALWAYS test on the real device(s).
The same is true for CPC development, when developing games and composing music.
Well, let's see if anyone else knows the answer to the question: Is there a version of the game Eternal Light out there, that works on a real CPC?
I got some weird results with this on the Winape emulator, probably because I was loading code into the main area of memory and not the extra 64k, though it continued to persist with it even after I reset the emulator, though closing that and opening it again corrected the fault. As I seem to recall the Extra 64k has a way of keeping stuff there (even after a soft reset).
I made this one to work for BASIC 1.0, though I suspect the real machine will have trouble with it, let me know.
Tested on my CPC464 with 128k
I got as far as the start screen where the main character is surrounded by the 10 lanterns, and it says PRESS FIRE TO BEGIN.
Pressing whatever does nothing.
Quote from: mr_lou on 10:06, 10 February 13
Tested on my CPC464 with 128k
I got as far as the start screen where the main character is surrounded by the 10 lanterns, and it says PRESS FIRE TO BEGIN.
Pressing whatever does nothing.
Hmm, during that screen did you pick up any little pixelated bleeps, when the game was crashing for me it these glitches showed up. I was even ESCing to BASIC and listing the BASIC and they were coming up on that too before the system froze.
The original code in the game was using a Clear Input followed by WHILE INKEY$="X":WEND for the game to begin or when you need to press fire to continue with the messages. I've changed this to "WHILE INKEY$<>"":WEND" which I think is the 464 Equivalent of "Clear Input", cause the theory is the Loop will continue until there is nothing in the Keyboard Buffer, which is what Clear Input Does. For the Fire Sequencing I've changed it to INKEY(76)<>0. According to my 6128 Manual it's supposed to be Fire Button 2 and Fire Button 1 is 77, but I think this is a misprint cause Winape is using Fire Button 1 as 76.
Bringing back this old thread to ask: Did anyone ever fix this game so it runs on a real CPC? I would really like that.
Quote from: mr_lou on 15:55, 01 February 14
Bringing back this old thread to ask: Did anyone ever fix this game so it runs on a real CPC? I would really like that.
I remember having a good look at the game at the time, though I found a lot of memory seems to be occupied, I thought the game might of had a better chance of running on a real CPC if it was 64k, though large volumes of memory seems to be taken up by Sprites Alive (Sprites1.pck) - &5C00 -> &A8E6? The Sprites file is also huge, it appears it's overwriting Sprites Alive &266B -> &5F6A?, I maybe wrong about that. Next there's the "player" file which sits in the &C4 Memory area occupying &4000 -> &49FA & the "forge" file which sits in &C5 Memory area at &5000 -> &5B51. I'm not quite sure what those files do though.
Has the author thought about writing it in something else, perhaps the game might stand a better chance and more likely be 64k if it's done in SDCC, CCZ80 or CPC BASIC 3 perhaps?
Quote from: AMSDOS on 00:48, 02 February 14
I remember having a good look at the game at the time, though I found a lot of memory seems to be occupied, I thought the game might of had a better chance of running on a real CPC if it was 64k, though large volumes of memory seems to be taken up by Sprites Alive (Sprites1.pck) - &5C00 -> &A8E6? The Sprites file is also huge, it appears it's overwriting Sprites Alive &266B -> &5F6A?, I maybe wrong about that. Next there's the "player" file which sits in the &C4 Memory area occupying &4000 -> &49FA & the "forge" file which sits in &C5 Memory area at &5000 -> &5B51. I'm not quite sure what those files do though.
Has the author thought about writing it in something else, perhaps the game might stand a better chance and more likely be 64k if it's done in SDCC, CCZ80 or CPC BASIC 3 perhaps?
I think it's fine that it's for 128k CPC only. My only problem is that it won't run on a real CPC.
I can tell you that the "Forge" file is the title music, composed in STarKos. I know, because I'm the one who composed it.
So the "Player" file is most likely the STarKos playback code.
These two files can be moved anywhere we like, if it will help get the game running?
Quote from: mr_lou on 07:02, 02 February 14
I think it's fine that it's for 128k CPC only. My only problem is that it won't run on a real CPC.
I can tell you that the "Forge" file is the title music, composed in STarKos. I know, because I'm the one who composed it.
So the "Player" file is most likely the STarKos playback code.
These two files can be moved anywhere we like, if it will help get the game running?
Well I've come up with this nuts & bolts (464) edit, I've taken the tune stuff out (sorry), and edited the program (disc.bas which was originally eternal.bas), the game is still 128k because the file code.bin needs to reside in banked area &c4. I cannot test it on real machine, but it was working when I tested it on an expanded 464 in Winape, however was getting a different story when I tested it on an expanded 464 in Marco Vieth's CPCEMU v1.5 with the game getting to the opening screen and then crashing back to BASIC as soon as pressing the Fire Button (Numeric pad 5). However if I load DISC.BAS and then write this patch:
openout"d":memory &2671:out &7f00,&c4:load"code.bin":call &4f80:out &7f00,&c0:load"sprite1.pck":call &a640:call &7000:mode 0:run 210the game works in CPCEMU, so may be worth a try on a Real Expanded 464, if the crash in CPCEMU is the same as what's happening on the actual machine.
Nope. Not working.
"Memory full in 200" after the loading picture has been loaded.
Running on my CPC6128.
Quote from: mr_lou on 10:42, 02 February 14
Nope. Not working.
"Memory full in 200" after the loading picture has been loaded.
Running on my CPC6128.
It would have to be tested on a 464 if that's not a hassle, cause I haven't tested it on a 6128. On the first line I noticed a poke to turn on the Caps Lock which is a 464 Poke - don't know what it'll do on a 6128. Otherwise "LOAD" (not RUN) "DISC.BAS" and use that Code I posted above to load the other components followed by "RUN 210".
Quote from: AMSDOS on 10:52, 02 February 14
It would have to be tested on a 464 if that's not a hassle, cause I haven't tested it on a 6128. On the first line I noticed a poke to turn on the Caps Lock which is a 464 Poke - don't know what it'll do on a 6128. Otherwise "LOAD" (not RUN) "DISC.BAS" and use that Code I posted above to load the other components followed by "RUN 210".
My CPC464 isn't hooked up at the moment.
But I really think the game should work on a standard CPC6128.
The developer said from the start that it's a 128k game. So logically it wouldn't work on a standard CPC464, even if the music has been removed.
Quote from: mr_lou on 12:12, 02 February 14
My CPC464 isn't hooked up at the moment.
But I really think the game should work on a standard CPC6128.
The developer said from the start that it's a 128k game. So logically it wouldn't work on a standard CPC464, even if the music has been removed.
I modified that 6128 game to work on a 464 (BASIC 1.0), though I have given it 128k which, I assumed you had for your 464. If it hasn't got it, then I can see why it won't work.
Understand the game is 128k even without the music because code.bin is loaded into Memory Bank C4, if you follow my loading code you will see that. Originally I thought if I could remove some of the components such as the Music which appears to be interrupt driven, it might work on a Real CPC.
I'm unsure why the Real 6128 is returning a memory full in 200 error. The DISC.BAS file I made is only 8k, so MEMORY &2671 should be legitimate, I even did a OPENOUT"d" which should prevent it. OUT &7F00,&C4 will take me to the extended memory area where I should be able to LOAD CODE.BIN which starts at &4BFF, calling the execution address will unpack that file so it sits between &4000 & &5D4F, OUT &7F00,&C0 will take me back to the main Bank where I should be able to LOAD Sprite1.PCK which when unpacked sits at &5C00 & &A8E6, I can then execute Sprites alive at &7000 go into MODE 0 and run 210. If you get a Memory Full error by trying that I don't know what's happening, perhaps if there are other ROMs installed on your 6128 then it would be better to disable those, I'm not sure how friendly 128k programs are when ROMs are installed.
Quote from: AMSDOS on 03:55, 08 February 14
I modified that 6128 game to work on a 464 (BASIC 1.0), though I have given it 128k which, I assumed you had for your 464. If it hasn't got it, then I can see why it won't work.
I do have a 64kb expansion for it.
I'll try to remember to check out your mod next time I hook it up then.
Quote from: AMSDOS on 03:55, 08 February 14
I'm unsure why the Real 6128 is returning a memory full in 200 error. The DISC.BAS file I made is only 8k, so MEMORY &2671 should be legitimate, I even did a OPENOUT"d" which should prevent it. OUT &7F00,&C4 will take me to the extended memory area where I should be able to LOAD CODE.BIN which starts at &4BFF, calling the execution address will unpack that file so it sits between &4000 & &5D4F, OUT &7F00,&C0 will take me back to the main Bank where I should be able to LOAD Sprite1.PCK which when unpacked sits at &5C00 & &A8E6, I can then execute Sprites alive at &7000 go into MODE 0 and run 210. If you get a Memory Full error by trying that I don't know what's happening, perhaps if there are other ROMs installed on your 6128 then it would be better to disable those, I'm not sure how friendly 128k programs are when ROMs are installed.
Well, I did get a MegaFlash installed internally not long ago. So that might explain it.
Will try to remove a few ROMs and then try again.
But it'll be later, because we're in the middle of some home re-arrangements at the moment.
I tried my Disk Image with the no$cpc and got the memory full in 200 error. Once I was able to eliminate that I've been getting errors associated with the Sprites Alive |SCENERY commands that begin in Line 750. So I haven't been able to get this game working in with that Emulator, though I'm unsure if has issues similar to what happens on a Real CPC.
I've been doing some more tests with Sprites Alive on Winape & no$cpc and I've been getting different results with these emulators. Again I'm not sure if this relates to why this game won't work on a Real CPC, but it would be worthwhile testing it (using Sprites Alive) on the real thing to see what the outcome is.
I was simply loading the Sprites Alive in and executing it:
memory &2671:load"sprite1.pck"
call &a640:call &7000
which will setup the screen inks, load in the sprites using Sprites Alive
|draw,"sprites"
then setup a screen to draw the sprites to:
mode 0:locate 1,8
you can now use the Sprites Alive Scenery command to display those sprites.
|scenery,0,0,99
0-15 seem to relate to the main character in the game which goes through a whole animation process.
What's interesting though about this Scenery command is it's doing different things depending on the emulator, in Winape the Sprite Appears as normal, but with no$cpc there are two horizontal gaps breaking up the main character for example, this seems to be happening with all the sprites in no$cpc using that command, I'm not sure if it's a flaw in no$cpc, or it's just something else to do with the sprite file.
Also those errors which have been occurring in no$cpc seem to be a result of an out-of-range error in this case the sprite is simply being displayed off the screen resulting in an Error 11 which is the error I mentioned in my last post.
Upon testing in no$cpc I found numbers greater than 99 would be displayed off the top of the screen, the reason for that error, however in Winape it simply showed the sprite to be displayed half way down the screen, I could go as high as 199 on the y-axis which is considered legitimate in Winape, but not no$cpc.
So perhaps to work out what's legitimate and what's not, it would be best to test this on a real CPC by simply loading up Sprites Alive, Loading the Sprites (using Sprites Alive), and testing their scenery command, that command I have above posts Sprite 0 which is the start of the main character and working out where it goes on the screen on a Real CPC (it will be on the Left hand site regardless), but if it's only part of the way up the screen instead of up the top, then we should know (maybe) where the problem is I guess.
I've attached the latest Disk Image which now works in the no$cpc emulator.
To make this game work in no$cpc I've thrown out the old Sprite Alive sprites1.pck which was compressed and I think it was this compressed program which was causing all the issues from Sprites broken up, to Sprites Alive Error Messages from legitimate commands.
I've gone back to the original Sprites Alive program and used "sprite.1" file there, so now everything looks fine with no$cpc. The game looks a bit different now though because I was playing around with the Windows and Stuff earlier and I've extended the Black Line across the screen to the Black Blobs or your Bullet Doesn't go into that area and the Tune is still out, unfortunately I don't have any way of testing it on no$cpc because my computer I'm using doesn't have a Sound card.
I suggest testing this on a Real CPC if anyone has any time and can do it. I'm not sure if the Compression of Sprites Alive is the problem, I mentioned this because I tried to get Scooby & Scrappy Doo working on my 6128 years ago from a hacked Disk Image and it just wouldn't work, so I'm not a big fan of Compressing Actual Programs. The compressed "code.bin" seems to work fine though.
Doesn't work on my CPC+
Freezes on the sprites alive text screen.
Quote from: mr_lou on 08:01, 02 March 14
Doesn't work on my CPC+
Freezes on the sprites alive text screen.
Unfortunately I can only test this with Winape with the settings on CPC6128 with Parados, on reset I'm getting V4 in the opening text, though I'm unsure if I'm using this beast correctly & my Disk Image also works under those settings.
A couple of things could be occurring:-
* Is the CPC+ crashing when Sprites Alive is being executed?
memory &3fff
load"sprite.1",&7000
call &7000
That will give the opening message.
* Is the CPC+ crashing because system becomes unstable when loading code into extra 64k?
This follows the loading of Sprites Alive. Is 'out &7f00,&c4' from BASIC not allowed, or it's allowed, but it needs some machine code in the extra 64k to get it back to area &c0 or order to resume, thus the problem of getting information from the extra 64k into a BASIC variable. It's being so long, I cannot remember if 'out &7f00,&c4' takes one away from command line and the program making it appear as if it's crashed. So you type something but you cannot see it onscreen, however if you type in 'out &7f00,&c0' you're back with the command prompt? I think I've only noticed that with 'out &7f00,&c1', but command inputs can still be entered. On the emulators typing 'out &7f00,&c4' just lets the emulator carry on typing in commands, but the area &4000-&7fff is now 16Kb into the extra 64k. The basic program is only 8kb and won't be occupying any area &4000 onwards. I'm just wondering if a Plus Machine handles extra 64k differently from an old CPC?
I've managed to revise the program again and have uncompressed the CODE.BIN file and saved it as a straight DATA file. I disassembled the CODE.BIN in it's packed format and found it was Disabling Interrupts at the execution address &4F80.
I was looking up some Issues of AA and found that using the specified OUT &7F00,&C4 to access the extra 64k is legitimate from BASIC and that PEEK & POKE can be used as well, they (AA) don't mention LOAD"<filename>",&4000 though and the Manual doesn't say anything about only using it for the first 64k of main memory, if it turned out that LOAD only loads programs to Bank Area C0 - main memory, then it could easily be loaded first into high memory, move to area C4 & move the code there.
hehe, I see that you have one or two of the same illnesses as myself: Either the Don't-Know-How-To-Quit decease, or the Can't-Give-Up illness. The two are strongly related.
Thanks. The DSK is downloaded. Will test it when I find the time. :-)
Quote from: arnoldemu on 11:03, 29 May 09
Hmmm.. good work to find this. Maybe "sprites alive" is using interrupts?
Maybe it is possible to move the initialisation of the music and then setup a new function to call the music.
Sprites Alive is using a bit of firmware called "KL NEW FRAME FLY" (&BCD7), to setup a New Frame Flyback Event Block, but I suspect it's the event routine which DE points to which is the problem because that routine disables some Interrupts, I'm unsure where that is now, but if you start disassembling Sprites Alive while it's at &7000, you don't have to go very far into that before you see &BCD7. If you:
poke &7011,0
poke &7012,0
poke &7013,0
to remove that call &BCD7, I got the program to work on my Real 6128. I've attached a patched version, though I've been playing around with this program so much, I don't know why I couldn't get to the last lantern, so perhaps someone can download an earlier disk image that doesn't have the memory issues and apply the patch - just don't call &7000 before doing the patch, though you'll need to call &a640 to uncompress Sprites Alive.
Quote from: AMSDOS on 11:36, 10 August 14I got the program to work on my Real 6128.
Sadly I'm too hung up at the moment to test, but if you really got the game working on a real CPC, you deserve a reward.
Quote from: mr_lou on 14:54, 10 August 14
Sadly I'm too hung up at the moment to test, but if you really got the game working on a real CPC, you deserve a reward.
No Worries. I've gone back to the "eternal102.dsk" download, applied the patch, and got it up and running on my CPC6128. The game does become a little bit faster as a result of removing the event block, though it's still playable and perhaps better off without the event block.
Works fine on my CPC+ now yes!
Thanks a lot! :)
Damn, those black bastards are tricky.
(I haven't played the game before now. Have been saving it to play on a real CPC)
WOW!!! Thanks AMSDOS for all your work in getting my game going on a real CPC. Who would have known how much grief I would give poor Mr Lou in trying to get this thing going. I hope it isn't a big let down after all this anticipation :P
Quote from: AMSDOS on 11:36, 10 August 14
Sprites Alive is using a bit of firmware called "KL NEW FRAME FLY" (&BCD7), to setup a New Frame Flyback Event Block, but I suspect it's the event routine which DE points to which is the problem because that routine disables some Interrupts
With my limited knowledge on interrupts, ??? am I right in thinking that using starkos was causing the conflict and crash?
Quote from: AMSDOS on 11:36, 10 August 14
I don't know why I couldn't get to the last lantern
Was this because of memory or because you couldn't work it out? ;) I know I designed 2 of them to be event related in order to get them. (Clue - They both have to do with the boy / girl characters in the game helping you). I would have loved to have made more event based collections but I just ran out of memory. :(
Also I thought I would mention that I had time to play around with Eternal Light while flying between holiday destinations 8) and managed to tweak a few things that had been bugging me about the game.
First I sped up the main guy by making him move 2 pixels at a time instead of 1 and changed his starting position.
I also figured out how to drop the loading time by saving the levels data as a binary file and loading the file directly into the extra memory. Saves heaps of time and is much tidier.
This had already been done when the game was first made by whoever "cracked" my game but I was so happy that I did it all by myself. ;D
The DSK is at home on my laptop so I'll see if I can apply the new patch and post it later on tonight.
Quote from: Morri on 02:59, 12 August 14
WOW!!! Thanks AMSDOS for all your work in getting my game going on a real CPC. Who would have known how much grief I would give poor Mr Lou in trying to get this thing going. I hope it isn't a big let down after all this anticipation :P
Thanks. :D
QuoteWith my limited knowledge on interrupts, ??? am I right in thinking that using starkos was causing the conflict and crash?
No the music player and tune seems to be all good on my Amstrad.
The crash was happening where the screen was being drawn (line 290) with "OUT &7F00,&C4" causing the crash. So I just disassembled Sprites Alive and found KL NEW FRAME FLY after KL LOG EXT.
I don't know a great deal about KL NEW FRAME FLY, though the firmware manual was able to tell me it sets up an event block whenever a frame flyback occurs. Specifically I don't think this was the problem, but the routine it was pointing to, might of been causing the Real Hardware to crash if it was in the extra 64k.
So what @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) said earlier is on the money. :D
Fortunately removing the Event Block is the easiest solution, it maybe a component Sprites Alive uses to determine the Speed of the game, I was playing "Space Froggy" and even though it's a Compiled game, the various Rooms seem to have their own individual Speed Settings, I'm not sure specifically if that is what KL NEW FRAME FLY is about, though once I removed KL NEW FRAME FLY, the Eternal Light runs a little bit faster, fortunately it's not a critical component for it. :D
QuoteWas this because of memory or because you couldn't work it out? ;) I know I designed 2 of them to be event related in order to get them. (Clue - They both have to do with the boy / girl characters in the game helping you). I would have loved to have made more event based collections but I just ran out of memory. :(
I did complete the game once (ages ago though), but initially it was the version which had one of the lanterns repositioned behind the Girl, usually I go to the Girl when I have 1 or 2 lanterns and while I went to the boy after that to get him to say I'm scared of the dark (or something), I thought I went back to him when I had 8 Lanterns and got no response, it might be the bugged version I had, but I'd done various things along the way, so it might be that which might be doing something.
But I've applied the patch to your ETERNAL102.DSK, I haven't been able to get to that amount, so hopefully it'll work.
Quote from: AMSDOS on 04:43, 12 August 14
The crash was happening where the screen was being drawn (line 290) with "OUT &7F00,&C4" causing the crash. So I just disassembled Sprites Alive and found KL NEW FRAME FLY after KL LOG EXT.
I don't know a great deal about KL NEW FRAME FLY, though the firmware manual was able to tell me it sets up an event block whenever a frame flyback occurs. Specifically I don't think this was the problem, but the routine it was pointing to, might of been causing the Real Hardware to crash if it was in the extra 64k.
Ah OK, I'm glad that means sprites alive and starkos can co-exist on real software. If I ever use SA again, I'll be sure to use the patched driver.
I've attached the revised version I've been working on lately in case anyone might prefer it. It loads / plays way faster and feels better paced to me. I should mention it does the odd strange thing (dodgy collision detection sometimes) but nothing game breaking that I found. I tried to finish it to make sure everything works beginning to end but I died after 9 lanterns with the 10th in sight. :o Can't even beat my own game. ::)
Should work on real CPCs as I've used the patched driver but confirmation would be cool.
EDIT: The modified files are "-story2" and "eternal2"
:? Is it possible to change that in the rsx? I mean create the sprite alive RSX so every one can benfit fom it, or is it specific to eternal light game?
Sorry, maybe it's a stupid question...
Mr Lou: I've printed the basic listing of eternal light (by pressing esc during intro) and, I'm impressed by the maths that generates the levels.
Quote from: Morri on 02:59, 12 August 14
Who would have known how much grief I would give poor Mr Lou in trying to get this thing going. I hope it isn't a big let down after all this anticipation :P
hehe, well, "grief" is kind of a strong word.
But I admit I was a bit sad when I discovered the game didn't run on a real CPC. :)
Quote from: Morri on 03:09, 12 August 14Also I thought I would mention that I had time to play around with Eternal Light while flying between holiday destinations 8) and managed to tweak a few things that had been bugging me about the game.
First I sped up the main guy by making him move 2 pixels at a time instead of 1 and changed his starting position.
I also figured out how to drop the loading time by saving the levels data as a binary file and loading the file directly into the extra memory. Saves heaps of time and is much tidier.
This had already been done when the game was first made by whoever "cracked" my game but I was so happy that I did it all by myself. ;D
It's really awesome to hear that you've been working on improving the game.
I think it's a very good idea to have the main character move faster. :)
Looking forward to play this version!
EDIT: Any room for in-game music now? :D
Quote from: mr_lou on 07:39, 12 August 14
It's really awesome to hear that you've been working on improving the game.
I think it's a very good idea to have the main character move faster. :)
Looking forward to play this version!
EDIT: Any room for in-game music now? :D
Check post # 77 for new DSK file. ;D
Re in-game music, that would be so cool. Currently the music is loading into the extra memory along with the levels data and I couldn't figure out how to reference both at the same time as well as the SA commands. Not sure if I'm just missing something easy and it is possible with a few tweaks?
Quote from: jbaudrand on 07:29, 12 August 14
Mr Lou: I've printed the basic listing of eternal light (by pressing esc during intro) and, I'm impressed by the maths that generates the levels.
hehe, Mr Lou is the brilliant mind behind the "forge" intro music. TBH the maths I used was just a lot of hit and miss until it worked stuff. Sprites alive looks after everything to do with graphics. You just have to follow the manuals instructions on setting it up and it nearly runs itself. For drawing each level it is as simple as placing tiles at spaced intervals with the |scenery command. Very easy and I would recommend any non-asm coders to use it to produce great projects for the CPC.
Quote from: Morri on 07:25, 12 August 14
Ah OK, I'm glad that means sprites alive and starkos can co-exist on real software. If I ever use SA again, I'll be sure to use the patched driver.
I've attached the revised version I've been working on lately in case anyone might prefer it. It loads / plays way faster and feels better paced to me. I should mention it does the odd strange thing (dodgy collision detection sometimes) but nothing game breaking that I found. I tried to finish it to make sure everything works beginning to end but I died after 9 lanterns with the 10th in sight. :o Can't even beat my own game. ::)
Should work on real CPCs as I've used the patched driver but confirmation would be cool.
EDIT: The modified files are "-story2" and "eternal2"
Yes, this is working on my 6128. Your Wizard can literally Run away from those Black Blobs, I didn't feel like Shooting much, where's earlier I felt like I was waggling the Star Cursor more frantically! :D
I got to the end of the game and I was prompted with a Question Mark "?" Pressing Enter I got a shock horror Syntax error, i don't know if this is a glitch when I was transferring the files from my PC to my CPC, or if the file is at fault on your Disk Image. I loaded endgame.bas on my machine and got a Syntax Error when I tried Listing it.
Quote from: jbaudrand on 07:29, 12 August 14
:? Is it possible to change that in the rsx? I mean create the sprite alive RSX so every one can benfit fom it, or is it specific to eternal light game?
Sorry, maybe it's a stupid question...
Not quite sure I follow. The patch I made was done to Sprites Alive. If anyone were to make an 128Kb game using Sprites Alive, then that patch can be used to make games work on the real hardware.
Quote from: AMSDOS on 11:36, 12 August 14
I got to the end of the game and I was prompted with a Question Mark "?" Pressing Enter I got a shock horror Syntax error, i don't know if this is a glitch when I was transferring the files from my PC to my CPC, or if the file is at fault on your Disk Image. I loaded endgame.bas on my machine and got a Syntax Error when I tried Listing it.
Hmm, not sure either. I have attached a snapshot of endgame.bas running. Maybe you could transfer that file to disk?
Quote from: Morri on 08:57, 14 August 14
Hmm, not sure either. I have attached a snapshot of endgame.bas running. Maybe you could transfer that file to disk?
It appears to have happened when I downloaded your eternlig.dsk file, but the game was ok up till it loaded endgame.bas.
I was having some problems on this forum uploading some of my attachments, so I'm thinking my web browser is the culprit because I was having the same problem with the endgame.bas file in Winape. I can download it through Chrome.
It's just been annoying that things have been working just fine up till recently. :(
;D I will try with XMEM and sprites alives could be fun
Quote from: jbaudrand on 19:11, 14 August 14
;D I will try with XMEM and sprites alives could be fun
It should work, though I maybe struggling to test on my Amstrad if something is created, my limited imagination usually dictates extra memory can be set aside for Music & Level Data, which is what the extra 64k can handle. I guess with 512K you can have it all sorted in one load, might need something bigger than a 3" Disc.