CPCWiki forum

General Category => Programming => Topic started by: Morri on 05:18, 12 July 15

Title: Let's Go! [First Major Release]
Post by: Morri on 05:18, 12 July 15
Hi,
I have been making a game over the past month using CPC BASIC 3 (http://www.cpcwiki.eu/index.php/CPC_Basic_3). I must say that it is an amazing tool for all of those people who never got past learning BASIC (like myself  :-[ ).
Basically, you type your BASIC program into CPC BASIC 3, use the "RUN" command to compile it into machine code, use ManageDsk (http://www.cpcwiki.eu/index.php/ManageDsk) to add it to a .DSK file and create a simple BASIC loader to load it all up. As I make changes, it literally takes me 30 seconds to compile, add and test with WinAPE. SIMPLE!!!

After learning from @AMSDOS (http://www.cpcwiki.eu/forum/index.php?action=profile;u=330) that it can be combined with other sprite drivers, I started experimenting with ESD2 from Sean McManus (http://www.sean.co.uk/books/amstrad/amstrad8.shtm). While not the most powerful sprite routine ever written, it is short and easy to understand with only a few CALL commands to achieve what you need.

Anyway, I have began coding a game I have called "Let's Go!" which is a clone of the mobile game Relic Rush (https://www.youtube.com/watch?v=6mQm-RLDz3k).
It features graphics in mode 0 (not my own but I can't remember where I got the tileset from) which are double pixelled vertically so that each pixel appears to be square. It gives the game a nice colourful, chunky retro feel. I actually like how they came out.
The gameplay is extremely simple being a one button game; press SPACEBAR (and eventually FIRE on a Joystick) to make your character stop (in order to avoid obstacles) and release to continue moving.
While not yet implemented I hope to make the following additions:
- Moving over an arrow will cause the player to jump, moving to a ladder will automatically climb etc until you reach a flag within the allowed time limit.
- Enemies will include falling and sliding blocks, enemies firing laser beams from their eyes and enemies hurling objects.

I have attached a .DSK file at the end of this post and will put any major updates here as I finish them. No doubt I will also run into heaps of problems and will probably have to ask for help from the experts  :-* . Here's hoping I can get this finished  ;) .

v1.0 - 12th July 2015 - Very early release. The player only moves left to right and has no reaction to any obstacles / ladders. Enemies do not move yet. SPACEBAR causes the player to stop. Working timer bar counts down and once reaches zero, the game is over and returns to the main menu.
v1.1 - 17th July 2015 - The player now jumps when passing over a "Jump arrow". Have attempted to add a sound effect but currently there is a delay.
v2.0 - 25th July 2015 - Player can now climb ladders. Block enemies now move. No player / enemy collision detection yet. Level completes when flag is reached and a tune is played. Removed jump sound effect.
v3.0 - 26th July 2015 - Collision detection added. Death sequence with sound effect added.
v4.0 - 26th September 2015 - First major release - All gameplay elements are present. 12 levels added. Ranking system added.
Title: Re: Let's Go! [WIP]
Post by: AMSDOS on 05:59, 12 July 15
That's looking great. I'm assuming you're using Double Buffering during the game? Don't know why I couldn't get that to work in CPC BASIC3 if that's the case.
Title: Re: Let's Go! [WIP]
Post by: Morri on 07:58, 12 July 15
Quote from: AMSDOS on 05:59, 12 July 15
That's looking great. I'm assuming you're using Double Buffering during the game? Don't know why I couldn't get that to work in CPC BASIC3 if that's the case.
No double buffering used, just a few well placed FRAME commands  ;D . I thought I might have to ask about buffering when I first started because it was so flickery it was nearly unwatchable  :-\ . Can't talk too soon as it may get worse once more sprites are moving at the same time. If you ever manage to figure buffering out with CPC BASIC 3, be sure to let me know.

Just FYI, here is my order of commands to achieve this flicker free version so far.

Title: Re: Let's Go! [WIP]
Post by: mr_lou on 08:46, 12 July 15
This is great!  :)
Seems like everyone is doing games for the CPC these days.  :)
I like how it's possible to develop for the CPC in so many different ways.

@Morri (http://www.cpcwiki.eu/forum/index.php?action=profile;u=95), are you planning on submitting this to the CPCRetroDev2015 too? You should!  :)

Not entirely sure about the rules though. @ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82), do you think it's ok to post the games here on the forum, if they are to be accepted by the CPCRetroDev2015 crew?
I remember them writing something about that the games shouldn't previously have been released. Maybe it's considered a release when posting it on the forum?
Title: Re: Let's Go! [WIP]
Post by: Trebmint on 08:52, 12 July 15
This looks really nice... please finish it. A very Bubble Bobble look to it, though I dont know what the game play is going to be. Seems like a bit of a renaissance in the past few months with CPCbasic and CPCtelera going on. I must admit that looking at the source CPCBasic was producing was a real eye opener as it's near perfect, and as quick as can be. Obviously the negative number stuff is an issue, but for games thats not really a problem at all. Actually I think this will claim due to not coping with negative values to be the fastest compiler of any language on the CPC... Im doing Unify at the moment and was hoping to out speed everything, but in this case its actually impossible.


Very good stuff. Great looking start to a game too.
Title: Re: Let's Go! [WIP]
Post by: Morri on 09:24, 12 July 15
Thanks everyone for the feedback. I will do my best to keep working on it.
In saying that I do get easily distracted and I just spent the last hour watching Rick Dangerous longplays on Youtube  ::) .
Title: Re: Let's Go! [WIP]
Post by: mr_lou on 09:29, 12 July 15
Quote from: Morri on 09:24, 12 July 15
Thanks everyone for the feedback. I will do my best to keep working on it.
In saying that I do get easily distracted and I just spent the last hour watching Rick Dangerous longplays on Youtube  ::) .

No worries. The deadline for CPCRetroDev2015 isn't till October 23rd, so there's plenty of time.  :)
And you can win 300 euro!!!
Title: Re: Let's Go! [WIP]
Post by: Morri on 09:58, 12 July 15
Quote from: mr_lou on 09:29, 12 July 15
No worries. The deadline for CPCRetroDev2015 isn't till October 23rd, so there's plenty of time.  :)
And you can win 300 euro!!!
A great incentive for sure. I did see the post from @ronaldo (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1227) and it's a wonderful idea to generate interest and support for games creation.
If my game meets the criteria I would happily summit it without really worrying about winning or losing. I just want to see more games for the CPC and that really seems to be happening atm. It's such a great thing to see.

Quote from: Trebmint on 08:52, 12 July 15
I must admit that looking at the source CPCBasic was producing was a real eye opener as it's near perfect, and as quick as can be. Obviously the negative number stuff is an issue, but for games thats not really a problem at all. Actually I think this will claim due to not coping with negative values to be the fastest compiler of any language on the CPC... Im doing Unify at the moment and was hoping to out speed everything, but in this case its actually impossible.
Very interesting to hear your thoughts on CPCBasic knowing you are an excellent Z80 coder. I was unsure myself how efficient the code being produced actually was so it's great to hear that @Dinoneno (http://www.cpcwiki.eu/forum/index.php?action=profile;u=236) did such a good job.

p.s. Thanks for all your efforts with Unify, it is sounding more and more exciting with every post re symbos. Can't wait.
Title: Re: Let's Go! [WIP]
Post by: Trebmint on 10:40, 12 July 15
Quote from: Morri on 09:58, 12 July 15
Very interesting to hear your thoughts on CPCBasic knowing you are an excellent Z80 coder. I was unsure myself how efficient the code being produced actually was so it's great to hear that @Dinoneno (http://www.cpcwiki.eu/forum/index.php?action=profile;u=236) did such a good job.
Yes I did look at the source for a while and it looks very nice indeed. I would deny however I'm a good Z80 coder, but you dont need to be to see its pretty tight with CPCBasic. So yes he did an excellent job, and the optimizations are well done too including INCs and DEC for +1 -1's etc. Most of its unrolled too so, which is a judgement call on the part of the compiler coder. When do you include unrolled code or a subroutine, as the speed increases but the size grows fast too.
Loops and expressions are the main area for speed, and TBH you on a z80 wont get results that hand coded will result in, as FOR's & WHILES just by the syntax tend to require saving and lookup of the loop value, when most coders cleverly save a register just for the purpose. However CPCBasic is an amazing bit of code though... I wont say as good as a compiler can get, but very very close. If you're game is too slow using this, you're either pushing too hard or your Basic code isnt good. I'd say that using CPCBasic and a Sprite package you should get speed results 95% as good as a pure z80 coded commercial game.
So yeah go for it... I'm loving the game devving thats going on :) I'd probably be involved if it wasnt for Unify, though saying that network Pong and Table Football is coming along :)
Title: Re: Let's Go! [WIP]
Post by: ervin on 13:24, 12 July 15
Quote from: Morri on 09:58, 12 July 15
A great incentive for sure. I did see the post from @ronaldo (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1227) and it's a wonderful idea to generate interest and support for games creation.
If my game meets the criteria I would happily summit it without really worrying about winning or losing. I just want to see more games for the CPC and that really seems to be happening atm. It's such a great thing to see.
Very interesting to hear your thoughts on CPCBasic knowing you are an excellent Z80 coder. I was unsure myself how efficient the code being produced actually was so it's great to hear that @Dinoneno (http://www.cpcwiki.eu/forum/index.php?action=profile;u=236) did such a good job.

p.s. Thanks for all your efforts with Unify, it is sounding more and more exciting with every post re symbos. Can't wait.

Yes indeed, Dinoneno has some serious talent.
I used his ccz80 compiler for 6 years, and loved every minute of it.
Really great compiler, and very easy to use.

The only reasons I've moved on are because cpctelera offers a wonderful environment with lots of tools/functions integrated nicely, and also the fact that (because cpctelera uses SDCC) I no longer have to write workarounds for negative numbers!
Title: Re: Let's Go! [WIP]
Post by: ervin on 03:19, 13 July 15
Quote from: mr_lou on 08:46, 12 July 15
This is great!  :)
Seems like everyone is doing games for the CPC these days.  :)
I like how it's possible to develop for the CPC in so many different ways.

@Morri (http://www.cpcwiki.eu/forum/index.php?action=profile;u=95), are you planning on submitting this to the CPCRetroDev2015 too? You should!  :)

Not entirely sure about the rules though. @ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82), do you think it's ok to post the games here on the forum, if they are to be accepted by the CPCRetroDev2015 crew?
I remember them writing something about that the games shouldn't previously have been released. Maybe it's considered a release when posting it on the forum?
My understanding is that it's ok to have a WIP thread for your game, but no final release prior to the competition deadline.
If you're not sure, @ronaldo (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1227) may be able to provide clarification.

I've got a development thread for my game RUN"CPC", but I'll be holding things back as it gets closer to completion.
My CPCRetroDev2015 entry - RUN"CPC" (http://www.cpcwiki.eu/forum/programming/my-cpcretrodev2015-entry-run'cpc'/)

In any case, there will be surprises in there that I don't want anyone to see until the competition is over!  :P

Title: Re: Let's Go! [WIP]
Post by: AMSDOS on 12:00, 13 July 15
Quote from: Morri on 07:58, 12 July 15
No double buffering used, just a few well placed FRAME commands  ;D . I thought I might have to ask about buffering when I first started because it was so flickery it was nearly unwatchable  :-\ . Can't talk too soon as it may get worse once more sprites are moving at the same time. If you ever manage to figure buffering out with CPC BASIC 3, be sure to let me know.

Just FYI, here is my order of commands to achieve this flicker free version so far.


       
  • Take a snapshot of the background the sprite is about to be placed and save it to ram. (Using the ESD2 CALL 40164,ram,xpos,ypos,xsize,ysize)
  • Place sprite over background (CALL 40053,sprite,xpos,ypos). Also use oldx=xpos and oldy=ypos (refer 7)
  • FRAME
  • Check for key press, reduce timer and check for obstacles (only the side walls done so far - If no obstacle then increase/decrease xpos or ypos)
  • Change sprite animation (only have 2 per direction to keep it easy)
  • FRAME
  • Place background back over sprite using CALL 40000,ram,oldx,oldy
  • Go back to 1.


It's been suggested to place other things between drawing and redrawing I think. It's something I struggle with for code which doesn't do much.


I'm trying to implement Sean's Overlay Sprite Driver, over the top of my Background Restore Routine, but I'm having trouble coming to grips with how Sean's Overlay Sprite Driver writes to screen. I was assuming his Fine Overlay Routine ignores 0s if found. So I thought if I had set another colour it would delete the edge when moved, but seems to be having the opposite effect. I'm assuming that because MODE 0 holds 2 pixels per byte, I need double 0 around the sprite for it to delete itself?
Title: Re: Let's Go! [WIP]
Post by: Morri on 02:02, 14 July 15
Quote from: AMSDOS on 12:00, 13 July 15
I'm trying to implement Sean's Overlay Sprite Driver, over the top of my Background Restore Routine, but I'm having trouble coming to grips with how Sean's Overlay Sprite Driver writes to screen. I was assuming his Fine Overlay Routine ignores 0s if found. So I thought if I had set another colour it would delete the edge when moved, but seems to be having the opposite effect. I'm assuming that because MODE 0 holds 2 pixels per byte, I need double 0 around the sprite for it to delete itself?
I too am using the overlay feature and the only way I could figure out to use it effectively was with the snapshot feature as I detailed (This technique was how Sean did his frog graphics demo). I haven't tried a double 0 around the sprites but that might work, not sure.

The only thing about the overlay feature is not all 0's are acting transparent. You'll notice it in my first release. The character walks over the cliff sprite and there are blue pixels around him. These are ink 0 and are supposed to be transparent. Maybe half the 0's work as they should. It's very weird. Any ideas?
Title: Re: Let's Go! [WIP]
Post by: Xifos on 08:18, 14 July 15
Quote from: Morri on 02:02, 14 July 15
I The character walks over the cliff sprite and there are blue pixels around him. These are ink 0 and are supposed to be transparent. Maybe half the 0's work as they should. It's very weird. Any ideas?

Masking done at byte level, not pixel ?
Title: Re: Let's Go! [WIP]
Post by: AMSDOS on 08:42, 14 July 15
Quote from: Xifos on 08:18, 14 July 15
Masking done at byte level, not pixel ?


Sean's Sprite Routines all use Encoded Ink, so is handled at Byte Level.


My Plot Image routines (http://www.cpcwiki.eu/forum/programming/silly-programming-ideas-turning-text-into-graphics/msg25428/#msg25428) use Graphics Pen colours, so can draw at Pixel Level, but because it's using Firmware, it's slow.
Title: Re: Let's Go! [WIP]
Post by: AMSDOS on 09:26, 14 July 15
Quote from: Morri on 02:02, 14 July 15
I too am using the overlay feature and the only way I could figure out to use it effectively was with the snapshot feature as I detailed (This technique was how Sean did his frog graphics demo). I haven't tried a double 0 around the sprites but that might work, not sure.

The only thing about the overlay feature is not all 0's are acting transparent. You'll notice it in my first release. The character walks over the cliff sprite and there are blue pixels around him. These are ink 0 and are supposed to be transparent. Maybe half the 0's work as they should. It's very weird. Any ideas?


From the experiment I did based on 0s around the image, the Overlay skips the 0s, so if an image is there, it remains there after the sprite is drawn. What I was looking to do was generate a blanking effect around the character, then use this other little routine I made for Filling in the Background, minimising it to a few pixels. I got excited when I only saw a couple of those blue pixels when the character walks over the cliff area.

I can only think what's happened in your case is the Left Most Pixel was another value, an invisible square around the character would do that and then you had a black character as the Right Most Pixel, I can confirm this when I put my invisible border along the outer edge of my sprite, for me it might mean part of the background is deleted from an 0 as well as the outer edge, which would be bad for my backdrop routine if that's the case.
Title: Re: Let's Go! [WIP]
Post by: AMSDOS on 10:29, 14 July 15
I cannot quite put my finger on what this overlay routine is doing, when I move by sprite down the edges which has a zero in it becomes the pixel from the next line down and I have this other line which when is first drawn is just a line of 0s, earlier I had my blanking value (ink 9), which almost worked until I moved across the screen, not deleting some pixels where the sprite is near the edge. I'd thought I tried it with as many of the blanking inks, but now I don't know.
Title: Re: Let's Go! [WIP]
Post by: Morri on 23:26, 16 July 15
New update v1.1! See OP for download. Main sprite can now jump when he passes over the arrow sprite.

I've also added a jump sound effect but there is a delay between the command and the execution. The SOUND command is given before the jump command but doesn't play until the sprite has landed. Can anyone help with why that is.
Title: Re: Let's Go! [WIP]
Post by: ervin on 00:26, 17 July 15
@Morri (http://www.cpcwiki.eu/forum/index.php?action=profile;u=95) - looking good!

The jump sound effect seems to be timed correctly.
Maybe (just temporarily) change it to a shorter, sharper sound effect, rather than the one you've got now.

The sound effect you are using starts quiet and gets louder near the apex of the jump.
Could that be affecting your perception of when the sound effect starts?

If you find that a temporary short sound effect is timed correctly, you can then be confident that everything is ok, and then you can put your actual sound effect back in.

Title: Re: Let's Go! [WIP]
Post by: AMSDOS on 02:42, 19 July 15
I tested the updated version in Winape and noticed there was some Graphical glitches appearing:


[attachimg=1]


Initially I thought this might of been occurring while I was in 464 settings, but this little graphical sprinkles seems to be occurring when I've CATaloged the Disk Image. A Memory dump was showing the results from the CAT resided around the same area ESD2 & Halfsize Fonts, unfortunately I wasn't able to resolve the problem & thought it might have something to do using an area which is normally 0, but not defining it as 0, which is resulting in all this stuff coming up because it's not being blanked out. Probably the easiest way to resolve that is save that area when it's all 0, then loading that which just ensures that problem won't happen in case someone does a CAT?
Title: Re: Let's Go! [WIP]
Post by: Morri on 02:51, 20 July 15
Quote from: AMSDOS on 02:42, 19 July 15
I tested the updated version in Winape and noticed there was some Graphical glitches appearing...
Interesting bug  ;D My latest build as of last night is now resetting after a CAT (no issues when no CAT is done) so the problem is becoming more serious.  :-\
I'll just keep soldiering on with it and see how far it will let me go. Once I know the exact size of the main file (currently at 8kb and growing) then I can try and move things to avoid this bug but I'm running out of space quick if this is going to stay a 64kb game.  :D
Title: Re: Let's Go! [WIP]
Post by: AMSDOS on 11:34, 20 July 15
Quote from: Morri on 02:51, 20 July 15
Interesting bug  ;D My latest build as of last night is now resetting after a CAT (no issues when no CAT is done) so the problem is becoming more serious.  :-\
I'll just keep soldiering on with it and see how far it will let me go. Once I know the exact size of the main file (currently at 8kb and growing) then I can try and move things to avoid this bug but I'm running out of space quick if this is going to stay a 64kb game.  :D


I noticed with your first prototype this wasn't occurring, though there weren't many files on the disk, so it seems it's getting worse the more files are being stored on disk, which would result in more memory being used.
Of course with ESD2 the first 2 bytes deal with the Width & Height of the Sprite, it doesn't like it when it doesn't find what it wants, but I don't see how a CATaloging the Disk to Memory would interfere with that since it's been loaded after all that.
Title: Re: Let's Go! [WIP]
Post by: arnoldemu on 13:35, 20 July 15

If the data/code goes past &a700 then a catalogue could destroy it because the catalogue is stored around here.
So it means you need to make your code smaller, or start it at a different location,  or load it lower and copy it up before running it.
Title: Re: Let's Go! [WIP]
Post by: Morri on 20:36, 24 July 15
New version update. See OP for download.

I have added a few things this time round. Climbing ladders, stage completion, enemy movement. See what you think. It's starting to resemble what I was going for so that's a bonus.

Last big gameplay addition may prove to be the trickiest and that is player / enemy collision detection. I'm not too sure how to go about this. Any suggestions would be appreciated. Once that's sorted, I would like to start adding different enemies.

I also created a .DSK file with all the redundant files removed. This seems to help with the CAT bug for now.
Title: Re: Let's Go! [WIP]
Post by: Axelay on 07:54, 25 July 15
Quote from: Morri on 20:36, 24 July 15
Last big gameplay addition may prove to be the trickiest and that is player / enemy collision detection. I'm not too sure how to go about this. Any suggestions would be appreciated. Once that's sorted, I would like to start adding different enemies.



If you have used some sort of map or grid for detecting platforms and ladders, you could perhaps use the same grid for enemy collision detection, but it might be too coarse.  Another way would be to use bounding boxes.  Here's a crude example of the bounding box approach in BASIC, use the cursor keys to move the player about:


10 plyWid=2:plyHgt=2
20 eneWid=3:eneHgt=3
30 CLS
35 DIM enemy(3,2)
40 FOR x=1 TO 3
50 READ enemy(x,1): READ enemy(x,2)
60 NEXT x
70 plyX=1:plyY=1
90 REM main loop
100 GOSUB 210
110 GOSUB 410
120 GOSUB 610
130 GOTO 100
200 REM refresh enemy display
210 PEN 2
215 FOR x=1 TO 3
220 FOR y=1 TO eneHgt
230 LOCATE enemy(x,1),enemy(x,2)+y-1
240 PRINT "***"
250 NEXT y
260 NEXT x
320 RETURN
400 REM bounding box collision check
410 bordercol=1
420 FOR x=1 TO 3
430 IF plyX+plyWid-1<enemy(x,1) THEN GOTO 500
440 IF plyX>enemy(x,1)+eneWid-1 THEN GOTO 500
450 IF plyY+plyHgt-1<enemy(x,2) THEN GOTO 500
460 IF plyY>enemy(x,2)+eneHgt-1 THEN GOTO 500
470 REM bounding box collision detected
480 bordercol=6
500 NEXT x
510 BORDER bordercol
520 RETURN
600 REM clear player, get input and move player, update player position
610 LOCATE plyX,plyY
620 PRINT "  "
630 LOCATE plyX,plyY+1
640 PRINT "  "
700 IF INKEY(0)=0 AND plyY>1 THEN plyY=plyY-1
710 IF INKEY(2)=0 AND plyY<23 THEN plyY=plyY+1 
720 IF INKEY(8)=0 AND plyX>1 THEN plyX=plyX-1
730 IF INKEY(1)=0 AND plyX<38 THEN plyX=plyX+1
750 LOCATE plyX,plyY
760 PEN 1
770 PRINT "++"
780 LOCATE plyX,plyY+1
790 PRINT "++"
800 RETURN
1000 DATA 7,5,15,10,20,15
[size=78%] [/size]
Title: Re: Let's Go! [WIP]
Post by: Morri on 03:08, 26 July 15
Quote from: Axelay on 07:54, 25 July 15
If you have used some sort of map or grid for detecting platforms and ladders, you could perhaps use the same grid for enemy collision detection, but it might be too coarse.  Another way would be to use bounding boxes.  Here's a crude example of the bounding box approach in BASIC, use the cursor keys to move the player about:
Oh man, it's so easy when you know how! Cheers @Axelay (http://www.cpcwiki.eu/forum/index.php?action=profile;u=84), this works perfectly and I only needed to add 5 lines of code.
I had a faint idea it needed to be something like this but I just couldn't quite nail it so this has saved me heaps of trial and error.

Now to add a death sequence...
Title: Re: Let's Go! [WIP]
Post by: mr_lou on 06:22, 26 July 15
This game is progressing fast!  :)

Nice work!
Title: Re: Let's Go! [WIP]
Post by: Morri on 10:45, 26 July 15
Quote from: mr_lou on 06:22, 26 July 15
This game is progressing fast!  :)

Nice work!
I'm in the groove now!  ;)
Just uploaded the latest version with collision detection and death sequence, so the game is basically complete gameplay wise.
All that's left to do are more levels and more enemies, load up screen and music. But I'm going to save those for when the game is complete so that it's more of a surprise.  :P
Title: Re: Let's Go! [WIP]
Post by: Morri on 21:00, 01 August 15
Let's go is continuing to progress well. I have successfully added another enemy and have it working well (animation and collision).

Just to change it up a bit I decided to have a go at adding music and I've run into a lot of trouble.
I have tried to use starkos with cpcbasic3 and they don't seem to want to play nice. I tried both the basic and the interrupt versions and loaded them within the recommended area around &9000, but when I called them from the compiled cpcbasic3 code I just get a few beeps (no crashes), no music.  :'(

Has anyone managed to use a music program with CPCBasic3??? Am I missing something or doing something wrong?
Title: Re: Let's Go! [WIP]
Post by: McKlain on 21:21, 01 August 15
Have you tried the Arkos player instead?
Title: Re: Let's Go! [WIP]
Post by: Morri on 21:55, 01 August 15
No, not yet. I'll give it a try this afternoon.

Sent from my SM-G900F using Tapatalk

Title: Re: Let's Go! [WIP]
Post by: mr_lou on 02:30, 02 August 15
If the music was created using STarKos, then playback should work fine using the supplied routines for STarKos.

But a STarKos track won't playback using the Arkos Player routines.

I had to load my STarKos track into Arkos Tracker and export it from there before it worked with CPCtelera (because CPCtelera has Arkos player routines). Otherwise it gave the same symptoms you're describing.
(I thought the two formats were compatible too, but apparently not).
Title: Re: Let's Go! [WIP]
Post by: Gryzor on 17:25, 16 August 15
Just saw this. A one-button game for the CPC! Looks great, and is very promising... I think it may be too fast or -alternatively- I'm getting too old, but I'm really looking forward to watching this progress!
Title: Re: Let's Go! [WIP]
Post by: Morri on 01:21, 17 August 15
Quote from: Gryzor on 17:25, 16 August 15
Just saw this. A one-button game for the CPC! Looks great, and is very promising... I think it may be too fast or -alternatively- I'm getting too old, but I'm really looking forward to watching this progress!
I'm glad you think it's a bit fast as I was worried it may have been too slow and therefore too easy.  ;)

Progress on Let's Go is a bit slow ATM as I optimise, space save, bug-fix and try and figure out level design. I've almost run out of space if this is going to stay a 64Kb game and have seriously thought about making it a 128Kb / disc multiload game so we'll see where that heads. Obviously if it does I wouldn't be eligible for the retrodev competition but that's OK as I'd rather release something I'm happy with and not stripped down just to suit.
Title: Re: Let's Go! [WIP]
Post by: Neil79 on 12:18, 17 August 15
 8)
Title: Re: Let's Go! [WIP]
Post by: Morri on 23:53, 18 September 15
Update time!

As I just mentioned in another thread I have made the decision to make this a 128kb disc game. I tried to keep it within the 64kb limit for the gamedev competition but it just became too big and while it would have been possible, I would have only had 3 - 4 stages which is far too easy. I am currently up to 9 levels with more being added. I am hoping for at least 30 by the time I'm finished with different themes and enemies.

I have added heaps of sound effects, a loading screen which also plays a tune and nearly eliminated all flickering.

The game looks and plays really well but I've still got heaps to do.

Wishlist:
If anyone can help with 1 and/or 2, I would be grateful.
Title: Re: Let's Go! [WIP]
Post by: TFM on 00:27, 19 September 15
What's about using Exomizer for compression? Maybe this would leave enough space in RAM.

Title: Re: Let's Go! [WIP]
Post by: Morri on 00:40, 19 September 15
Quote from: TFM on 00:27, 19 September 15
What's about using Exomizer for compression? Maybe this would leave enough space in RAM.
I don't know anything about compression tools  :-[
What exactly do you do? I assumed it compressed the size of the file but once decompressed it took up the same part of the memory. Am I incorrect?
Title: Re: Let's Go! [WIP]
Post by: ||C|-|E|| on 00:43, 19 September 15
I was trying the game for a little bit and I really like it! Good work!! You only need to add many more levels  :D
Title: Re: Let's Go! [WIP]
Post by: Morri on 00:47, 19 September 15
Quote from: ||C|-|E|| on 00:43, 19 September 15
I was trying the game for a little bit and I really like it! Good work!! You only need to add many more levels  :D
Wish granted.  8) Currently up to 9. Aiming for 12 levels per "theme". With sprites already made for 2 themes so that's 24 planned levels.
In a perfect world, I would like 4 themes of 12 levels = 48 levels. That would be awesome.
Title: Let's Go! [WIP]
Post by: ervin on 01:11, 19 September 15
I'll try putting together a little exomizer guide for you very shortly.

We should be able to figure this out. (http://emoji.tapatalk-cdn.com/emoji4.png)
Title: Re: Let's Go! [WIP]
Post by: TFM on 04:27, 19 September 15
Quote from: Morri on 00:40, 19 September 15
I don't know anything about compression tools  :-[
What exactly do you do? I assumed it compressed the size of the file but once decompressed it took up the same part of the memory. Am I incorrect?


That's about it, but what you can do is to compress single levels and only decompress temporarily the level you need. The Exomizer decompression routine is only 140 bytes long (iirc). And it usually saves 50-70% of space, sometimes even more.


So you start with having everything compressed and then you decompress what you actually need. In the next level you decompress other data (can overwrite previous decompressed data).


The CPCWiki has a nice article about Exomizer.  :)
Title: Re: Let's Go! [WIP]
Post by: Joseman on 08:34, 19 September 15
yes, compression is very important, you need to use this sometimes if you want to achieve memory requeriments.

I've made a 1 side disk / hdd working copy of un squadron that could be achieved only using compress data in no way i would achieve that without compression,  impossible.
Title: Re: Let's Go! [WIP]
Post by: ||C|-|E|| on 11:01, 19 September 15
Even our text adventure (also WIP) is compressed, but not the interpreter, just the database  :D
Title: Re: Let's Go! [WIP]
Post by: AMSDOS on 12:11, 19 September 15
Quote from: Morri on 23:53, 18 September 15
Wishlist:

       
  • Add a hiscore table of sorts - If you pass 3 stages within the time limit, you are given a "ranking". I was hoping to save these to disc but CPC BASIC's use of the OPENIN / OPENOUT commands is really bloated. One line of code including these commands equalled 4kb of compiled code. Too big!!![/l][/l]
I guess if you had the Firmware available, you could save & load the Hiscore data if you have the Start Address & Length of it. Otherwise I guess the information (e.g. Start address) could be obtain in Debug mode


To save the Data it could look like this:


[/list]
ld b,11 ;; Length of the Filename
ld hl,filename
ld de,&0040 ;; buffer space?
call &bc8c
ld hl,<start address> ;; Origin of the Hiscore table
ld de,<length> ;; Length of it = end address-start address
ld a,2 ;; File Type - 2=Binary (suitable for that means of information)
call &bc98
call &bc8f
ret
.filename db "HISCORE.DAT"



To load it back



ld b,11 ;; Length of the Filename

ld hl,filename
ld de,&0040 ;; buffer space?
call &bc77

ld hl,<start address> ;; Origin of the Hiscore table
call &bc83
call &bc7a
ret
.filename db "HISCORE.DAT"



I was also wondering, if it would be better to have the game as a multi-load for loading the levels in as DATA, though it would become tricky when dealing between 64k & 128k systems.
APB seems to be one of the few games I've played that detects how much memory the system has, which then either determines to load the entire code in, if memory is available, or to load the level code if a 64k system is being used during the game. Obviously the later would have to call the appropriate routine, move the data if a 128k system if being used, or load the data in if the system is 64k.
Title: Re: Let's Go! [WIP]
Post by: ervin on 13:04, 19 September 15
I just remembered that you are using CPC BASIC 3, and I have no idea how to include assembler in that...
Consequently, I don't know how to help.

If anyone can help with this, here's what has to happen:

- deexo (the exomizer decompress asm routine, or the compiled BIN version) is made resident in memory somewhere.
- all data for level 1 is compressed into a binary file using exomizer. That .exo file is somehow loaded into a particular location in memory.
- all data for level 2 is compressed using exomizer, and loaded into a location in memory.
- etc.
- at level transition, the appropriate level's compressed file is uncompressed into the "live level data" area. This can be overwritten again and again at level transition.
- this is done by putting the source data address into HL, the destination address into DE, and then calling the memory address where deexo lives.

And that's it!
But because I'm not familiar with loading .BIN/.EXO files using CPC BASIC 3, I'm not much more help.
Title: Re: Let's Go! [WIP]
Post by: Singaja on 13:11, 19 September 15
Couldn't the asm opcodes for the decompressing routine be loaded through DATA or POKEs like in regular basic?
Title: Re: Let's Go! [WIP]
Post by: ervin on 14:21, 19 September 15
Quote from: Singaja on 13:11, 19 September 15
Couldn't the asm opcodes for the decompressing routine be loaded through DATA or POKEs like in regular basic?

Yes, I think you are correct.
:)
Title: Re: Let's Go! [WIP]
Post by: AMSDOS on 23:00, 19 September 15
It should be possible to poke data from the program that way, or I normally just load the binary bits when loading the main program, but not from the main game (cause it won't work!).


The loading/saving routines could be treated in the same manner as the sprite routine, they could be modified to allow strings & values to be passed to them. If RSXs are already being used extensively, then they could still be "CALLed" from CPC BASIC 3 with the parameters following after it. If strings were to be used, it would be better to pass them through a string variable (for 464 compatibility).
Title: Re: Let's Go! [WIP]
Post by: Singaja on 10:02, 20 September 15
You're right, since CPC Basic 3 generates a binary , the place to load the decompressing routine is in the Amsdos  ;)  basic loader prior to loading the game cpc basic 3 binary output.
Title: Re: Let's Go! [WIP]
Post by: Morri on 20:05, 25 September 15
MAJOR UPDATE!!!!
I have now finished all of the "theme one" levels - 12 in all.
I am now struggling to figure out how to add anything else into the game, mainly music within the CPC BASIC 3 part of the game and loading new files from CPC BASIC 3 once the levels have been completed. Currently the game simply loops once completed.

Anyway, I have decided to release what I am up to in the hopes that people enjoy it and those with more knowledge then me are impressed enough to have a look at the source (which I am happy to make open source if need be - just PM me) and help me to move on to the next phase.

All feedback is also welcomed, however I have maxed out the memory and can't add much more at the moment. Perhaps if someone helps with the compression side of things (which has gone over my head).

Please note that this is now a 128Kb game which I've only tested through WinAPE. I'm hoping to try it on my 6128 at some stage but I've got alot of real world stuff coming up now and may not have a lot of free time for awhile.  :'(

Anyway, I hope you enjoy the game and it's simple yet additive gameplay.
You will find the latest file in the first post.

ENJOY!!!
Title: Re: Let's Go! [WIP]
Post by: TFM on 21:35, 25 September 15
I'm sure your game will rock! Liked what you showed at the beginning! Keep the good work going!  :)
Title: Re: Let's Go! [WIP]
Post by: majikeyric on 21:51, 25 September 15
Cute game!
Title: Re: Let's Go! [First Major Release]
Post by: Morri on 00:16, 26 September 15
Just changed the title to reflect the release. Might help people realise there has been a big update.
Title: Re: Let's Go! [First Major Release]
Post by: AMSDOS on 01:50, 26 September 15
Very Nice.
Title: Re: Let's Go! [First Major Release]
Post by: Morri on 01:59, 26 September 15
Have just tried on my real 6128 and it works a treat! Looks way better than I could have hoped on my CTM644.  :D
Also the intro tune sounds amazing coming out of my amp / speakers. YES!

Only small thing I noticed was the sound sync is different on a real machine. The jump sound effect is now perfect but the laser and falling blocks are slightly out. I may have to fix that at some stage.
Title: Re: Let's Go! [First Major Release]
Post by: AMSDOS on 02:07, 26 September 15
People usually point out to me that Winape isn't the best tool when doing your Sound, think they suggest JavaCPC, though there's also Flynn's WinCPC & CPCE which comes with CPC BASIC 3. Unsure how people rate those later Emulators.
Title: Re: Let's Go! [First Major Release]
Post by: Morri on 20:00, 26 September 15
Challenge time. Can you get gold ranking on all 4 levels???


(http://s12.postimg.org/qlhjidi71/Four_Golds.jpg)

You've got to watch the clock, and take some risks to pass each stage as quickly as possible.
Title: Re: Let's Go! [First Major Release]
Post by: AMSDOS on 21:54, 26 September 15
Quote from: Morri on 20:00, 26 September 15
Challenge time. Can you get gold ranking on all 4 levels???


(http://s12.postimg.org/qlhjidi71/Four_Golds.jpg)

You've got to watch the clock, and take some risks to pass each stage as quickly as possible.


Don't know how you cracked that Tower one quickly.  :D
Title: Re: Let's Go! [First Major Release]
Post by: CraigsBar on 12:13, 27 September 15
Good looking and fun little game. It works fine on both my plus and just CPC 128. But not with an expansion fitted. Strange but true.
Title: Re: Let's Go! [First Major Release]
Post by: AMSDOS on 23:36, 27 September 15
Quote from: CraigsBar on 12:13, 27 September 15
Good looking and fun little game. It works fine on both my plus and just CPC 128. But not with an expansion fitted. Strange but true.


So it's not working on an expanded 464?
Title: Re: Let's Go! [First Major Release]
Post by: CraigsBar on 23:39, 27 September 15
Quote from: AMSDOS on 23:36, 27 September 15

So it's not working on an expanded 464?
Well it works on my 464plus that Bryce upgraded to 6128plus spec, so long as I disconnect the minibooster and symbiface2... With it the screen rolls or a total black screen of death.

The just CPC 128k exhibits the same issues unless the xmem and xmass are removed. With no expansion it works fine on both.

Sent from my A3-A30 using Tapatalk

Title: Re: Let's Go! [First Major Release]
Post by: AMSDOS on 23:53, 27 September 15
Hmmm, I haven't seen the Let's Go source code, but it sounds like RSXs are putting a spanner in the works, perhaps a test with other ROMs like Protext or Maxam might confirm this?
Powered by SMFPacks Menu Editor Mod