Coolbox [New Game in Basic]

[Morri]

It's curious that it only happens at the start of the scroll. Once you go 5 or 6 steps into the scroll, everything works again.

I still think it could be due to some kind of bug in the implementation of control codes in BASIC 1.0. Have you tried using no control codes? What about a drawing subroutine instead of a control-coded string? It may work.

Yes, it seems it is the control codes fault. Once I removed all the control codes the game works fine. No colour yet, I'd have to work on something that redraws using transparent sprites but without control codes.

[ronaldo]

You can use transparency with control codes, but don't embed it the middle of a string. Activate transparency then draw with control codes, deactivate it then clear. It should work this way.

[Morri]

You can use transparency with control codes, but don't embed it the middle of a string. Activate transparency then draw with control codes, deactivate it then clear. It should work this way.

I'm sure this is what I did in the cool464.bas file but the problem remained.

The bug in BASIC 1.0 seems to be for every control code you embed in a string, you lose a column in the window. i.e. string has 5 control codes then anything past LOCATE 35,XX won't work. 10 cc's would be LOCATE 30,XX etc... I think that's why the character returned to normal after 5 or so moves because he had wrapped around the screen back to XPOS 1 after glitching through XPOS 35 - 40.

[AMSDOS]

I remember having some problems, which related to my positioning of my LOCATE, when I was writing my Block Editor (which is in my Silly Programming Ideas Thread) last year. In that situation I had a LOCATE, followed by the Control Code for turning off the Transparency Mode, Printing the relevant colour block in that spot & then turning the Transparency Mode back on. I was finding in that situation my Cursor (X) was working fine until I went to the far right of screen, the correction I made was to use the Control Code, followed by the LOCATE, PRINT the relevant colour block, turn Transparency back on.


But I think circumstances in your program are different in the way you're managing your program, so the resolution in your case maybe to simply LOCATE before the control code, it could be placed in another window like window 1, I was going to try that to see if that would make a difference, though I'm not 100% certain if this will correct what's happening.

[ronaldo]

The bug in BASIC 1.0 seems to be for every control code you embed in a string, you lose a column in the window. i.e. string has 5 control codes then anything past LOCATE 35,XX won't work. 10 cc's would be LOCATE 30,XX etc... I think that's why the character returned to normal after 5 or so moves because he had wrapped around the screen back to XPOS 1 after glitching through XPOS 35 - 40.

Is not exactly related to the number of control codes embeded, but to the length of the string itself (counting the control codes). I have created a proof of concept that you can use for testing and understanding what really happens.

Code Select Expand


''' Setup
10 defint a-z:ox=1:x=1:y=3:m=0:l=8:pm=0
20 mode 0
30 gosub 2000:gosub 1000:gosub 1200

''' Main Loop: Read keyboard and perform actions
''' O, P: move left-right
''' Z, X: Shrink-Enlarge control-code string
''' Space: Change printing method
'''
40 k$="":while k$="":k$=upper$(inkey$):WEND
50 if k$="O" then if x>1 then x=x-1:m=1
60 if k$="P" then if x<20 then x=x+1:m=1
70 if k$="Z" then if l>1 then l=l-1:gosub 2000
80 if k$="X" then if l<40 then l=l+1:gosub 2000
90 if k$=" " then gosub 1200
100 if m then m=0:if pm then gosub 1000 else gosub 1100
110 goto 40

'''' Print Character (Method 1: Control Codes)
1000 locate 1,1:print x;y;"  ":locate ox,y:print" "
1010 locate x,y:print p$
1020 ox=x:return

'''' Print Character (Method 2: Standard print)
1100 locate 1,1:print x;y;"  ":locate ox,y:print" "
1110 locate x,y:print "A";chr$(;"B";chr$(;"C";chr$(;"D";chr$(
1120 ox=x:return

'''' Change Print Method
1200 pm=not(pm):locate 1,5
1210 if pm then print "CONTROL CODES " else print "STANDARD PRINT"
1220 return

'''' Create character string with control codes
2000 p$=""
2010 for i=1 to l:if i mod 2<>0 then p$=p$+chr$(64+i/2) else p$=p$+chr$(
2020 next:locate 10,1:print "LEN:";len(p$);" "
2030 return

In this proof of concept, I also show you an alternate method to print your characters using control codes. Create a subroutine that prints your character instead of a string, then use GOSUB instead of print string$. In this case, I print the string character by character, but you may use several strings joined by semicolons, being sure that the length of your strings (counting control codes) added to your x-coordinate do not sum more than screenwidth+1.

That should solve your issues, at the cost of a little bit of speed loss.

[VincentGR]

Finally after some days I finished this fantastic game.
I had no spare time so I did a level or two per day.
The last two were the easiest 

Thanks again.

[Bytebreaker]

Yes, very amazing. The Youtube publication maybe attracts more people who might get interested in Amstrad Retro stuff and its superior Basic abilities.

[Gryzor]

What a cool, cute little game!! Very clever use of the large pixels, and great puzzles too. Imagine if this was a type in back in the day...

[mr_lou]

I notice in the video that the audio channels are out of sync in the title tune. It's not supposed to sound like that.

The ingame tune seems to be fine.

[VincentGR]

I notice in the video that the audio channels are out of sync in the title tune. It's not supposed to sound like that.

The ingame tune seems to be fine.

Maybe it messed up while I was editing with VDub, dunno 

[Morri]

I notice in the video that the audio channels are out of sync in the title tune. It's not supposed to sound like that.

The ingame tune seems to be fine.

This may have been something I did wrong. I used the MERGE command to get your code into the game and had to change the variable names to avoid clashes. The title tune seems to work OK the 1st time it plays, then when you play the game and return to the title screen, it slowly starts to go out of sync. I tried to fix it but couldn't pinpoint anything.

[ukmarkh]

I love this game:


http://classicreplay.blogspot.com/2016/10/coolbox-amstrad-cpc.html

[Sykobee (Briggsy)]

Neat little game! Great use of BASIC (although I can see you're getting hit hard by the column redraw - are you PRINTing solid blocks? Might be better to POKE solid data into screen memory instead...

[roudoudou]

Hope you guys have fun and give feedback here.

I discover the game yesterday, woaaaaaaah! Huge work, pure basic, very nice! And playable!


It was a real pleasure to play with your game!


Thank you!

[Puresox]

It's definitely the finest Basic game I have come across. Please let us know if there are any other good Basic examples.

[Morri]

Neat little game! Great use of BASIC (although I can see you're getting hit hard by the column redraw - are you PRINTing solid blocks? Might be better to POKE solid data into screen memory instead...

Yes, it is simply a PRINT command to get the next lot of screen. Not sure how easy it would be to POKE things onto the screen. This was discussed some time this year but the tests made showed POKEing pixels in BASIC wasn't any faster so I never bothered to try. Machine code would definitely be faster but my goal was 100% BASIC.