My new project

[Retrospect]

Hi all.

 

I have a little project under way, it's in it's concept stage right now. It's based on another game released in the early 80s by UK company "Firefly" .... named Castle Conquer.

 

The original game was for Extended Basic and I must say was one of the better XB games out there. My game will be compiled, and in the end will either be done with XB or XB256 depending if it NEEDS xb256 to do what it does.

 

The game will have ideally 10 screens ... at the moment, in it's prototype stage, 6 are present - but these will not be as they are for the final release. They are just tests, to be played around with.

 

I'm happy with how the little guy moves around on screen, he kind of hobbles with a pitter patter and he can jump either straight up, or jump the way he is facing ..... the game is designed so the player can move backwards as well as forwards, which the original did NOT do!

 

Keys for playing : <yes keys .... I realise some of you want to hang me publically for that>

 

S - Move left

D - Move right

E - Jump straight up

SPACE - Jump across, the way you are facing

 

Press SPACE to start game.

 

Note that you can't jump if you are still holding S or D down. You have to let go first then do the jump.

 

CASTLE1.zip <- prototype of game. Needs Ext. Basic

 

 

Edited March 18, 2015 by Retrospect

[sometimes99er]

Very nice. Quite cute. I don't know, but jumping the soldiers seems more of chance than pixel perfection, and it seems tight as is.

 

[Retrospect]

Very nice. Quite cute. I don't know, but jumping the soldiers seems more of chance than pixel perfection, and it seems tight as is.

 

Thanks .... yeah the soldiers is pretty much a pixel-perfect jump as it is, actually I wanted those soldiers animated, the original game had them hurl the spears up and down just like the game "Hunchback" in the arcade.

 

I figure a counter and a switch variable will be needed for that.

 

I gave the player * just * enough of a jump to get around the soldiers, I suppose if it's too tight I could let him jump a little longer.

 

The biggest headache of all will be if I want a rope across a gap. I won't even get into the mathematics required for that. It is beyond me. lol.

[sometimes99er]

I gave the player * just * enough of a jump to get around the soldiers, I suppose if it's too tight I could let him jump a little longer.

I'll give it another go. Argh.

[Retrospect]

I'll give it another go. Argh.

haha .... that's the spirit.

 

Did you make the jumps?

[sometimes99er]

I thought I had the "points" from where to leap with the first two soldiers, but suddenly jumping over the first guy and I hit him on his helmet. Damn !

[Retrospect]

lol !

 

Must admit it is pretty tight. It's almost as tight as the bridge screen on the 1st Dizzy game.

 

 

 

[+Vorticon]

Looking forward to it Hey, why not a Dizzy game?!

[Retrospect]

Looking forward to it Hey, why not a Dizzy game?!

I've been looking into that ..... I thought about it often ..... now, Dizzy requires I would say about 8 frames of animation per jump, and that's 8 left, 8 right, so we would probably want to store the hex char patterns in strings .... It's not impossible but it would probably mean making the game with only about 4 screens due to lack of memory?

[Retrospect]

I've been trying a bit of code that will hopefully make the guards animate at random.

 

At first, I used two random numbers with 30 in each RND .... the idea was that if both numbers equal the same, it triggers a switch to animate the guards.

When compiled I found that the speed in which it finds two of the same within the number 30 was astounding so I changed it to 300 and it seems to do the job right.

 

10 DIM A$(2)

20 A$(1)="0000000000030343E743417F7F4747470000000000C0C0C0E0C080E0F8ECE6E6"

30 A$(2)="40E04040404343436733190F070707070000000000C0C0C0E0C080E0F8ECE6E6"

100 CALL CLEAR

110 RANDOMIZE :: CALL MAGNIFY(3)

112 SW=1 :: CALL CHAR(60,A$(SW))

115 CALL SPRITE(#1,60,5,120,120)

120 CALL KEY(0,K,ST)

130 M1=INT(300*RND)+1::M2=INT(300*RND)+1

140 IF M1=M2 THEN 1000

150 IF ST=0 THEN 120

160 STOP

1000 SW=SW+1::IF SW>2 THEN 112

1010 SW=2::CALL CHAR(60,A$(SW))::GOTO 115

ANIM2.zip < this is the above code compiled. In ordinary Extended Basic, the instances of two of the same number within a RND of 300 would be few and far between but not with this!

[+Vorticon]

I've been looking into that ..... I thought about it often ..... now, Dizzy requires I would say about 8 frames of animation per jump, and that's 8 left, 8 right, so we would probably want to store the hex char patterns in strings .... It's not impossible but it would probably mean making the game with only about 4 screens due to lack of memory?

 

If you use RXB, then you will have access to the SAMS card and up to 1MB of memory That's a lot of screens for you!

[Retrospect]

 

If you use RXB, then you will have access to the SAMS card and up to 1MB of memory That's a lot of screens for you!

Ok, cool ... you've got me thinking about that .... so, is there a way to compile RXB yet? ... if not, it could be done anyhow, just use more references to a sprite collision detection subroutine at a specific line in the program.

[Retrospect]

Can anyone tell me why this program has ended up like it is?

 

I've made a little program that tests sound values for me (because I'm hideously crap at coding sound)

 

It can store, and play, a sequence of notes (up to 32 just for the sake of a limit)

 

It plays all the stored notes - but then seems to pad the rest of the way to the 32 limit with little BEEPs .... wtf ???

 

Here's the Ext.Basic list and the program file itself .

(program has been compiled, and as such, has appropriate FOR-NEXT delays in the source)

 

SOUNDTEST.zip < compiled program

 

TESTER.zip < Extended Basic uncompiled program

 

----------------------------------------------------------------------------------------------------------------------------------------------------

 

 

! Texas Sound Tester thing.

! Turn screen blue, clear screen, white font

100 CALL CLEAR::CALL SCREEN(6)::FOR L=1 TO 14::CALL COLOR(L,16,6)::NEXT L

105 CALL CHAR(91,"0408101010100804") :: CALL CHAR(93,"2010080808081020")

! The text underline graphic

110 CALL CHAR(35,"00FF00FF00FF00FF")

! Strings with CHAR codes in them for the new letters.

120 DIM L$(26)

130 L$(1)="3C4242427E424242"

140 L$(2)="7C22223C2222227C"

150 L$(3)="3C4240404040423C"

160 L$(4)="7C2222222222227C"

170 L$(5)="7E4040784040407E"

180 L$(6)="7E40407840404040"

190 L$(7)="3C4240404E42423C"

200 L$( ="4242427E42424242"

210 L$(9)="3E0808080808083E"

220 L$(10)="020202020202221C"

230 L$(11)="4448506050484442"

240 L$(12)="202020202020203E"

250 L$(13)="42665A4242424242"

260 L$(14)="4262524A46424242"

270 L$(15)="7E4242424242427E"

280 L$(16)="7C4242427C404040"

290 L$(17)="3C424242424A443E"

300 L$(18)="7C4242427C484442"

310 L$(19)="3C42403C0202423C"

320 L$(20)="3E08080808080808"

330 L$(21)="424242424242423C"

340 L$(22)="2222222214140808"

350 L$(23)="4242424242425A24"

360 L$(24)="4242241818244242"

370 L$(25)="2222140808080808"

380 L$(26)="7E0204081020407E"

! Tall numbers are assigned to overwrite the original numbers

390 FOR L=1 TO 10 :: READ Q$ :: B$(L)=Q$ :: CALL CHAR(L+47,B$(L)):: NEXT L

400 DATA "1C2222222222221C","081828080808083E","3C4202040810207E","3C42021C0202423C"

410 DATA "060A12223E020202","7C40407C0202423C","3C42407C4242423C","7E02020408102020"

420 DATA "3C42423C4242423C","3C4242423E02023C"

! This is for the Texas logo

430 CALL CHAR(65,"0103030303030303")! TI TOP 1

440 CALL CHAR(66,"FC0405050406020C")! TI TOP 2

450 CALL CHAR(67,"0080404080000C12")! TI TOP 3

460 CALL CHAR(68,"FF80C04060381C0E")! TI MID 1

470 CALL CHAR(69,"1921213D050505C4")! TI MID 2

480 CALL CHAR(70,"BA8A8ABAA1A1A122")! TI MID 3

490 CALL CHAR(71,"0702000000000000")! TI BOT 1

500 CALL CHAR(72,"C4632030180E0700")! TI BOT 2

510 CALL CHAR(73,"4C9020404020E000")! TI BOT 3

! This bit's clever. It puts the string info into the relevant CHAR values to overwrite the original font.

520 CP=97

530 FOR L=1 TO 26

540 CALL CHAR(CP,L$(L))

550 CP=CP+1

560 NEXT L

! Save memory in stack by clearing unwanted variables

570 FOR L=1 TO 26 :: L$(L)="" :: NEXT L

580 FOR L=1 TO 10 :: B$(L)="" :: NEXT L

! Introduce the array for the notes

590 DIM N(32)

! This bit is the main screen

590 ch=0::nc=0

600 DISPLAY AT(2,3):"sound tester"

620 DISPLAY AT(3,3):"############"

630 DISPLAY AT(10,1):"[1] store a sequence"

640 DISPLAY At(12,1):"[2] erase a sequence"

650 DISPLAY AT(14,1):"[3] play a sequence"

660 DISPLAY AT(16,1):"[4] test single notes"

670 CALL HCHAR(1,1,65)::CALL HCHAR(1,2,66)::CALL HCHAR(1,3,67)

680 CALL HCHAR(2,1,68)::CALL HCHAR(2,2,69)::CALL HCHAR(2,3,70)

690 CALL HCHAR(3,1,71)::CALL HCHAR(3,2,72)::CALL HCHAR(3,3,73)

700 !

! User must now choose an option so call key and goto wherever

710 CALL KEY(0,K,ST) :: IF ST=0 THEN 710

720 IF K=49 THEN 1000

730 IF K=50 THEN 2000

740 IF K=51 THEN 3000

750 IF K=52 THEN 4000

760 CALL SOUND(200,110,1) :: GOTO 710

! Store a sequence of notes

! Check first to see how many notes are free to use

1000 CH=0

1005 FOR L=1 TO 32

1010 IF N(L)>0 THEN 1100

1015 NEXT L

1020 IF CH=32 THEN 1200

1030 GOTO 1300

! Increment CH variable by 1, to indicate a note is stored in an array already

1100 CH=CH+1

1110 GOTO 1015

! Tell user the array is full, then get rid of message

1200 DISPLAY AT(24,1):"note memory full"::call sound(300,110,0)

1210 FOR DE=1 TO 5000::NEXT DE

1220 DISPLAY AT(24,1):" "::GOTO 710

! Store a note

1300 CALL CLEAR

1310 DISPLAY AT(1,1):"notes used :" ;CH;" of 32"

1320 NT=CH+1

1330 DISPLAY AT(24,1):"enter note ";NT;"?"

1340 ACCEPT AT(24,24):NV

1350 IF NV>4250 THEN 1340

1360 IF NV<110 THEN 1630

! play the note and ask to store or not

1370 display at(3,1):"playing note"::CALL SOUND(700,nv,0)::for de=1 to 500::next de::display at(3,1):" "

1380 DISPLAY AT(24,1):"store yn :"

1390 ACCEPT AT(24,24):YN$

1400 IF YN$="Y" THEN 1500

1410 IF YN$="y" THEN 1500

! not stored

1420 CALL SOUND(250,110,0)::GOTO 1330

! stored

1500 N(NT)=NV

1510 ch=ch+1

1520 IF NT=32 THEN 1600

1530 GOTO 1310

! note memory full

1600 DISPLAY AT(3,1):"note memory full"

1610 CALL SOUND(500,110,0)

1620 FOR DE=1 TO 5000::NEXT DE

1630 CALL CLEAR :: GOTO 600

! Erase a sequence

2000 for l=1 to 32::n(l)=0::next l

2010 call sound(250,1450,0)::goto 710

! Play a sequence

! first check how many notes are in array so we don't hit a zero val when playing

3000 for l=1 to 32

3010 if n(l)>0 then 3100

3015 next l

! now play however many notes we have according to nc variable

3020 for l=1 to nc

3030 call sound(250,n(l),0))::call sound(125,110,30)

3040 next l

3050 for de=1 to 500::next de

3060 call clear :: goto 600

! increment nc variable by 1

3100 nc=nc+1::goto 3015

! test single notes

4000 call clear

4010 display at(1,1):"enter note value [110 to 4250]"

4020 display at(3,1):"press 0 for main menu"

4020 accept at(6,1):nv

4025 if nv<110 then 3060

4030 call sound(500,nv,1)

4040 for de=1 to 250::next de

4050 goto 4020

 

Edited March 18, 2015 by Retrospect

[sometimes99er]

At 3000, do you control the initial value of nc ?

[Retrospect]

At 3000, do you control the initial value of nc ?

No, it increments up 1 every time there is a value recognised in the array of N.

 

In fact, my program is stacked with problems, when you start the program, you will have to choose the ERASE NOTES option because it seems there are already 22 in there (?) .... looking back at my code after sleep is still no better than it was last night.

 

So after clearing the sequence, I start a new sequence and it asks for a value, I type one, it asks to save it or not, I say yes, I do this only 10 times then type a value below 110 to get back to the main menu .... I choose the "play sequence" option and it indeed does play the sequence of values I chose, but it then does something really unexpected and whacky .... instead of cutting off after my last value entered, it goes right to the max limit of 32 with little white noise beep type tones. Strange, really strange.

[+Lee Stewart]

No, it increments up 1 every time there is a value recognised in the array of N.

 

In fact, my program is stacked with problems, when you start the program, you will have to choose the ERASE NOTES option because it seems there are already 22 in there (?) .... looking back at my code after sleep is still no better than it was last night.

 

So after clearing the sequence, I start a new sequence and it asks for a value, I type one, it asks to save it or not, I say yes, I do this only 10 times then type a value below 110 to get back to the main menu .... I choose the "play sequence" option and it indeed does play the sequence of values I chose, but it then does something really unexpected and whacky .... instead of cutting off after my last value entered, it goes right to the max limit of 32 with little white noise beep type tones. Strange, really strange.

 

You have two lines labelled “590”. When the code goes back to the menu (line 600) from line 1630, the second line 590 (initialization code) never gets executed.

 

...lee

[Willsy]

3100 nc=nc+1::goto 3015

 

That *can't* be right. Look at line 3015:

 

3000 for l=1 to 32

3010 if n(l)>0 then 3100

3015 next l

When you jump back to 3015 the loop (started in 3000) has expired.

[+Lee Stewart]

 

3100 nc=nc+1::goto 3015

 

That *can't* be right. Look at line 3015:

 

3000 for l=1 to 32

3010 if n(l)>0 then 3100

3015 next l

When you jump back to 3015 the loop (started in 3000) has expired.

 

 

Actually, that is often not the case here; but, it is better form to avoid explicitly jumping out of a loop and back into it. That is probably better programmed inside the loop:

! first check how many notes are in array so we don't hit a zero val when playing
 
3000 for l=1 to 32
3010 if n(l)>0 then nc=nc+1
3015 next l
 
   —or— 
 
3000 for l=1 to 32
3010 if n(l)<=0 then 3015
3012 nc=nc+1
3015 next l

or as a CALL or GOSUB.

 

Otherwise, it becomes the classic, difficult-to-read-and-debug, spaghetti code.

 

...lee

Edited March 19, 2015 by Lee Stewart

[Retrospect]

Lee & Willsy ... thanks, you are both on the nail ..... You know what, I have some really really bad coding habits! ..... I really do ... Lee your second example would be the one I should choose, since this program is meant to be for the Wilhelm Compiler and as such, I can't put logic after a THEN statement, I would do as your 2nd example does and branch the logic to another line .... but yeah if you wanna show anyone how NOT to code, just grab one of my lists. lol

 

I bet you lot despair of me sometimes.

[+Lee Stewart]

Lee & Willsy ... thanks, you are both on the nail ..... You know what, I have some really really bad coding habits! ..... I really do ... Lee your second example would be the one I should choose, since this program is meant to be for the Wilhelm Compiler and as such, I can't put logic after a THEN statement, I would do as your 2nd example does and branch the logic to another line .... but yeah if you wanna show anyone how NOT to code, just grab one of my lists. lol

 

I bet you lot despair of me sometimes.

 

Don't be so hard on yourself—you’re learning.

 

...lee

[Retrospect]

 

3100 nc=nc+1::goto 3015

 

That *can't* be right. Look at line 3015:

 

3000 for l=1 to 32

3010 if n(l)>0 then 3100

3015 next l

When you jump back to 3015 the loop (started in 3000) has expired.

 

So, does NEXT L actually * expire * the loop if it's not hit 32 yet? .... I was thinking, in my strange twisted logic, that if I point it back to line 3015 after it's incremented NC up one, that it would simply bounce back to the FOR until the loop reaches the number 32 ?

 

 

[senior_falcon]

No need to speculate. Change line 3015:

3015 PRINT I; :: NEXT I

and see what it goes to. Like you, I think it will go up to 32, but it's easy enough to test.

[+Lee Stewart]

So, does NEXT L actually * expire * the loop if it's not hit 32 yet? .... I was thinking, in my strange twisted logic, that if I point it back to line 3015 after it's incremented NC up one, that it would simply bounce back to the FOR until the loop reaches the number 32 ?

 

 

 

Your thinking is correct—at least, for TI Basic and TI Extended Basic. The variable names are global to the program; so, even though the loop index (L) may first occur in the loop, it is known and valid outside the loop. Nothing (except good sense ) prevents a TIB/XB programmer from jumping into an unfinished loop.

 

The only situation in XB where variables have only local scope is a SUB subprogram.

 

...lee

Edited March 19, 2015 by Lee Stewart

[+Lee Stewart]

H-m-m-m—it would appear that you cannot jump into a FOR..NEXT loop without incurring an error

1. if the loop was never run or
2. if the loop expired.

However, jumping back into an unexpired FOR..NEXT loop can apparently be done with impunity—even if you have more than one loop with the same index variable—until one of them finishes. Then you get the error “* NEXT WITHOUT FOR IN <statement #>”. There is no sanity check until you run the program. All the more reason to avoid GOTOs to return to a loop.

 

...lee

[Willsy]

Yes I didn't quite read your code correctly. You are jumping out of the loop to do a simple increment then jumping back in. However as has been pointed out, it's pointless to do that. Just put your code inside the loop. It will be faster. If you must jump out then use a GOSUB/RETURN. That's what's they're for. Even better than that, use SUBs (though I think I'm a voice in the wilderness on that one. Nobody seems to use them )