Started by Morri, 07:18, 12 July 15
0 Members and 1 Guest are viewing this topic.
Quote from: AMSDOS on 07:59, 12 July 15That'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.
Quote from: Morri on 11:24, 12 July 15Thanks 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 .
Quote from: mr_lou on 11:29, 12 July 15No worries. The deadline for CPCRetroDev2015 isn't till October 23rd, so there's plenty of time. And you can win 300 euro!!!
Quote from: Trebmint on 10:52, 12 July 15I 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.
Quote from: Morri on 11:58, 12 July 15Very 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 did such a good job.
Quote from: Morri on 11:58, 12 July 15A great incentive for sure. I did see the post from @ronaldo 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 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.
Quote from: mr_lou on 10:46, 12 July 15This 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, are you planning on submitting this to the CPCRetroDev2015 too? You should! Not entirely sure about the rules though. @ervin, 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?
Quote from: Morri on 09:58, 12 July 15No double buffering used, just a few well placed FRAME commands . 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)FRAMECheck 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)FRAMEPlace background back over sprite using CALL 40000,ram,oldx,oldyGo back to 1.
Quote from: AMSDOS on 14:00, 13 July 15I'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?
Quote from: Morri on 04:02, 14 July 15I 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?
Quote from: Xifos on 10:18, 14 July 15Masking done at byte level, not pixel ?
Quote from: Morri on 04:02, 14 July 15I 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?
Quote from: AMSDOS on 04:42, 19 July 15I tested the updated version in Winape and noticed there was some Graphical glitches appearing...
Quote from: Morri on 04:51, 20 July 15Interesting bug 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.
Quote from: Morri on 22:36, 24 July 15Last 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.
10 plyWid=2:plyHgt=220 eneWid=3:eneHgt=330 CLS35 DIM enemy(3,2)40 FOR x=1 TO 350 READ enemy(x,1): READ enemy(x,2)60 NEXT x70 plyX=1:plyY=190 REM main loop100 GOSUB 210110 GOSUB 410120 GOSUB 610130 GOTO 100200 REM refresh enemy display210 PEN 2215 FOR x=1 TO 3220 FOR y=1 TO eneHgt230 LOCATE enemy(x,1),enemy(x,2)+y-1240 PRINT "***"250 NEXT y260 NEXT x320 RETURN400 REM bounding box collision check410 bordercol=1420 FOR x=1 TO 3430 IF plyX+plyWid-1<enemy(x,1) THEN GOTO 500440 IF plyX>enemy(x,1)+eneWid-1 THEN GOTO 500450 IF plyY+plyHgt-1<enemy(x,2) THEN GOTO 500460 IF plyY>enemy(x,2)+eneHgt-1 THEN GOTO 500470 REM bounding box collision detected480 bordercol=6500 NEXT x510 BORDER bordercol520 RETURN600 REM clear player, get input and move player, update player position610 LOCATE plyX,plyY620 PRINT " "630 LOCATE plyX,plyY+1640 PRINT " " 700 IF INKEY(0)=0 AND plyY>1 THEN plyY=plyY-1710 IF INKEY(2)=0 AND plyY<23 THEN plyY=plyY+1 720 IF INKEY(8)=0 AND plyX>1 THEN plyX=plyX-1730 IF INKEY(1)=0 AND plyX<38 THEN plyX=plyX+1750 LOCATE plyX,plyY760 PEN 1770 PRINT "++"780 LOCATE plyX,plyY+1790 PRINT "++"800 RETURN1000 DATA 7,5,15,10,20,15
Page created in 0.127 seconds with 52 queries.