Honeycomb Rapture (RGPC)

[Opry99er]

Ill post code later tonight so you all cam see/feel what I'm talking about. Thanks to Ben (ti99forever) and Marc for giving me input on the array variable concept!!!

[Opry99er]

Here is the code for the new coinc engine. I have not set up the array for the killer bees yet, but I will do that next. The issue is, I really need to put one or two of these arrays into assembly language--- CALL INIT, CALL LOAD, CALL LINK. I am not experienced enough to know how to do this right off the bat, but I am learning. Any help that any of you could lend in my learning process would be greatly appreciated. I tried to attach the FIAD format of the game to this post, but the system wouldn't allow it. You'll have to copy and paste code into Classic99 for now. I'll make a video sometime in the next couple weeks. Hopefully by then I'll be further along in the array variable implementation. Thanks for lookin'.

 

 

100 REM **INIT VARIABLES**

105 DIM SPR(5)

106 OFFSET=5

110 Q=3 :: LEV=1 :: DSPD=10 :: Z=10 :: ZX=8 :: D=6

120 REM ** INIT CUSTOM CHARACTERS **

130 RESTORE 530

140 FOR SP=96 TO 136 STEP 4 :: READ SP$ :: CALL CHAR(SP,SP$) :: NEXT SP

150 CALL CLEAR :: CALL SCREEN(2)

160 CALL HCHAR(8,1,136,544)

170 CALL COLOR(14,11,12) :: CALL SCREEN(

180 CALL SPRITE(#1,100,2,170,5) :: CALL SPRITE(#2,112,7,99,150,0,-15)

190 CALL SPRITE(#4,112,7,150,125,0,-15)

200 CALL SPRITE(#3,96,2,10,5,0,20)

210 CALL MAGNIFY(3)

220 DISPLAY AT(3,20):Q

230 DISPLAY AT(1,16):"LEVEL" :: DISPLAY AT(1,21):LEV

240 CC=0 :: FOR I=1 TO 5 :: IF SPR(I)THEN CALL COINC(#1,#I+OFFSET,15,C) :: CC=CC+C

242 NEXT I

244 IF CC THEN 340

250 DDT=RND*Z :: IF DDT>ZX THEN GOSUB 670

260 CALL POSITION(#1,XPOS,YPOS)

270 IF XPOS>185 THEN GOSUB 490

280 IF YPOS<10 THEN GOSUB 510

290 IF XPOS<58 THEN GOSUB 500

300 CALL JOYST(1,X,Y)

305 CALL KEY(1,KKK,SSS) :: IF KKK=18 THEN FG=1

310 CALL MOTION(#1,-Y*2.5,X*2.5)

320 CALL PATTERN(#1,Y*3+X+116)

330 GOTO 240

340 REM ** SPIN BEE & FLASH SCREEN **

350 CALL DELSPRITE(ALL) :: CALL SPRITE(#1,100,2,90,120) :: CALL MOTION(#1,0,0) :: RESTORE 650

360 FOR DEAD=1 TO 8

370 READ SPIN :: CALL PATTERN(#1,SPIN)

380 CALL SCREEN(7) :: FOR DELAY=1 TO 10 :: NEXT DELAY

390 READ SPIN :: CALL PATTERN(#1,SPIN)

400 CALL SCREEN( :: FOR DELAY=1 TO 10 :: NEXT DELAY

410 NEXT DEAD

420 Q=Q-1 :: IF Q<0 THEN GOTO 460

430 CALL SCREEN(7) :: DISPLAY AT(6,6):" YOU LOST A BEE!! " :: FOR X=1 TO 400 :: NEXT X

440 CALL CLEAR :: CALL CHARSET :: CALL SCREEN(2) :: DISPLAY AT(7,10):"GET READY" :: CALL SCREEN(7) :: FOR X=1 TO 400 :: NEXT X

450 GOTO 150

460 CALL CLEAR

470 FOR L=1 TO 16

480 FOR X=1 TO 30 :: NEXT X :: PRINT "GAME OVER" :: CALL SCREEN(L) :: NEXT L :: GOTO 100

490 CALL LOCATE(#1,185,YPOS) :: RETURN

500 CALL LOCATE(#1,58,YPOS) :: RETURN

510 CALL LOCATE(#1,XPOS,10) :: RETURN

520 REM ** CHARACTER INIT DATA **

530 DATA "000000783C1E4FE7E7FDFF03070F1E3C0000000000000181F15DF9C181000000"

540 DATA "0F7840404140406221281452AC1308108080C82410884427118101030282FE00"

550 DATA "31488780874023100B040100010204048C12E101E102C408F020800080402020"

560 DATA "01011324081122E4888180C040417F00F01E0202820202468414284A35C81008"

570 DATA "0000000001C221151521C301000000001C22418102145455555414028141221C"

580 DATA "040402010001040B102340878087483120204080008020D008C402E101E1128C"

590 DATA "3844828140282AAAAA2A2840818244380000000080C384A8A884438000000000"

600 DATA "100813AC52142821624040414040780F00FE8202030181112744881024C88080"

610 DATA "040402010001040B102340878087483120204080008020D008C402E101E1128C"

620 DATA "007F4140C0808188E4221108241301010810C8354A2814844602028202021EF0"

630 DATA "5CA5CA5CA5CA5CA5"

640 REM ** SPRITE SPIN DATA **

650 DATA 120,108,104,100,112,124,128,132

660 DATA 120,108,104,100,112,124,128,132

670 D,FL=0 :: FOR I=1 TO 5 :: IF SPR(I)THEN GOSUB 800! CHECK TO ERASE SPRITE

672 IF FL=0 THEN GOSUB 900! FIND NEXT UNUSED SPRITE

675 NEXT I

680 IF D>0 THEN CALL POSITION(#3,XPOS,YPOS) :: CALL SPRITE(#D+OFFSET,136,2,XPOS,YPOS,DSPD,0)

690 RETURN

800 CALL POSITION(#I+OFFSET,TY,TX) :: IF TY>186 THEN CALL DELSPRITE(#I+OFFSET) :: SPR(I)=0

810 RETURN! ERASE SPRITE THAT WENT OFF BOTTOM OF SCREEN

900 IF SPR(I)=0 THEN D=I :: FL,SPR(I)=1 :: RETURN! FIND NEXT UNUSED SPRITE

910 RETURN

[sometimes99er]

This is just my instant thoughts.

 

I’m NOT an experienced XB with assembly coder. I’ve got some stuff laying around, but I’ve always gone pure assembler.

 

One approach ...

 

That’s always been the problem with any XB sprite game I’ve ever seen – or done myself for that matter. The coincidence detection. You can’t have many sprites and then tell the difference of coincidences. If only the main character is what to look out for, then the “length” between the player and each of the other objects might be a “simple” loop. If any length gets below say 8 pixels, we have a hit and what object hit the player. There’s

CALL COINC( #sprite-number, #sprite-number, tolerance, numeric-variable )

and then

CALL DISTANCE( #sprite-number, #sprite-number, numeric-variable)

to choose from. A loop might be like this

800 CALL DISTANCE(#1,#2,DI2)

810 CALL DISTANCE(#1,#3,DI3)

820 CALL DISTANCE(#1,#4,DI4)

830 CALL DISTANCE(#1,#5,DI5)

840 if (DI2>8 and DI3>8 and DI4>8 and DI5> then 800

850 CALL MOTION(#1,0,0)

860 ...

 

Another approach ...

 

Maybe by looking at the vertical position of the player, you could ON OBJ GOSUB linenumbers, where obj is the obj “number” to check for. If the player is close to the top, only check distance between aircraft and player.

I kinda like this ON GOSUB idea, if objects (other than the player) are moving/arranged in vertical OR horizontal areas.

 

[Opry99er]

HEXing out the new and improved flower patterns, courtesy of sometimes99er. Thanks buddy. Anyway, had to scrap the other flower design... compared to the way this one looks, it wasn't going to make me happy to see it on the screen. Should have flower graphics up today or tomorrow... try to get the "honeycomb" done by then as well. Gracias!

 

 

[sometimes99er]

Recieved this from Owen ...

 

Check it out boys.... Can't upload to atariage, because I'm not near a computer... Just my iPhone. Wanted you guys to see it. You could post it for me tonight if you wish... I'd appreciate it, if you get the time.... This is pic #1 of 2. Thanks

 

 

Looks nice. Again, instead of all those CALL HCHAR you should really look into DISPLAY AT. You can construct a string using CHR$ like A$=CHR$(87)&CHR$(54)&"76"&CHR$(34)

 

[Kurt_Woloch]

Why so complicated? 87, 54 and 34 are all displayable characters. So, instead, you could save some memory by just typing:

 

A$="W676"""

 

At least that's how I think I did full-screen graphics in my later XBasic games. Doing it like this, you only need 6 statements to draw the entire screen. Plus the screen draws a lot faster than when using individual HCHAR and VCHAR calls. And you save a lot of memory since essentially each character only takes up one character in the code (plus the statement overhead).

 

Looks nice. Again, instead of all those CALL HCHAR you should really look into DISPLAY AT. You can construct a string using CHR$ like A$=CHR$(87)&CHR$(54)&"76"&CHR$(34)

[sometimes99er]

Why so complicated? 87, 54 and 34 are all displayable characters. So, instead, you could save some memory by just typing:

 

A$="W676"""

Yep, you’re right. It was just supposed to be an illustrative example. AFAIR some of the definable characters are not available through keyboard input (you would have to use CHR$, but then again you can try and avoid these).

 

At least that's how I think I did full-screen graphics in my later XBasic games. Doing it like this, you only need 6 statements to draw the entire screen. Plus the screen draws a lot faster than when using individual HCHAR and VCHAR calls. And you save a lot of memory since essentially each character only takes up one character in the code (plus the statement overhead).

Yep, think so too.

 

[sometimes99er]

This may not be the fastest way to draw some flowers and petals, but it sure it rather compact.

 

100 CALL CLEAR::FOR R=0 TO 1::FOR C=0 TO 5
110 DISPLAY AT(R*3+19,C*4-R*2+5):SEG$("123I",1,3+R);
120 DISPLAY AT(R*3+20,C*4-R*2+5):SEG$("4*5I",1,3+R);
130 DISPLAY AT(R*3+21,C*4-R*2+5):SEG$("678I",1,3+R);
140 NEXT C::NEXT R

 

Edited January 17, 2010 by sometimes99er

[+retroclouds]

I have made some modifications to the program source for speeding up things a little.

The main game loop should be as tight as possible. I will go into details later:

 

100 REM **INIT VARIABLES**
105 DIM SPR(5)
106 OFFSET=5
110 Q=3 :: LEV=1 :: DSPD=10 :: Z=10 :: ZX=8 :: D=6
120 REM ** INIT CUSTOM CHARACTERS **
130 RESTORE 530
140 FOR SP=96 TO 136 STEP 4 :: READ SP$ :: CALL CHAR(SP,SP$) :: NEXT SP
150 CALL CLEAR :: CALL SCREEN(2)
160 CALL HCHAR(8,1,136,544)
170 CALL COLOR(14,11,12) :: CALL SCREEN(
180 CALL SPRITE(#1,100,2,170,5) :: CALL SPRITE(#2,112,7,99,150,0,-15)
190 CALL SPRITE(#4,112,7,150,125,0,-15)
200 CALL SPRITE(#3,96,2,10,5,0,20)
210 CALL MAGNIFY(3)
220 DISPLAY AT(3,20):Q
230 DISPLAY AT(1,16):"LEVEL" :: DISPLAY AT(1,21):LEV
REM ***************
REM START GAME LOOP
REM ***************
250 A=0 :: DDT=RND*Z :: IF DDT>ZX THEN GOSUB 670
260 CALL POSITION(#1,XPOS,YPOS)
270 IF XPOS>175 THEN CALL LOCATE(#1,175,YPOS) :: GOTO 290
280 IF XPOS<58 THEN CALL LOCATE(#1,58,YPOS)
290 IF YPOS<10 THEN CALL LOCATE(#1,XPOS,10)
292 CALL COINC(ALL,C) :: IF C=0 THEN 300
REM   ***********************
REM   * START COLLISION CHECK
REM   ***********************
294 FOR I=1 TO 5 :: IF SPR(I)THEN CALL DISTANCE(#1,#SPR(I),C) 
REM 295 DISPLAY AT(5,15):"SPRITE:";I
296 IF (C>0) AND (C<32) THEN 340
297 NEXT I 
REM   *********************
REM   * END COLLISION CHECK
REM   *********************
300 CALL JOYST(1,X,Y)
310 CALL MOTION(#1,-Y*2.5,X*2.5)
320 CALL PATTERN(#1,Y*3+X+116)
330 A=A+1 :: IF A=10 THEN GOTO 250
335 GOTO 260
REM *************
REM END GAME LOOP
REM *************
340 REM ** SPIN BEE & FLASH SCREEN **
350 CALL DELSPRITE(ALL) :: CALL SPRITE(#1,100,2,90,120) :: RESTORE 650
360 FOR DEAD=1 TO 8
370 READ SPIN :: CALL PATTERN(#1,SPIN)
380 CALL SCREEN(7) :: FOR DELAY=1 TO 10 :: NEXT DELAY
390 READ SPIN :: CALL PATTERN(#1,SPIN)
400 CALL SCREEN( :: FOR DELAY=1 TO 10 :: NEXT DELAY
410 NEXT DEAD
420 Q=Q-1 :: IF Q<0 THEN GOTO 460
430 CALL SCREEN(7) :: DISPLAY AT(6,6):" YOU LOST A BEE!! " :: FOR X=1 TO 400 :: NEXT X
440 CALL CLEAR :: CALL CHARSET :: CALL SCREEN(2) :: DISPLAY AT(7,10):"GET READY" :: CALL SCREEN(7) :: FOR X=1 TO 400 :: NEXT X
450 GOTO 150
460 CALL CLEAR
470 FOR L=1 TO 16
480 FOR X=1 TO 30 :: NEXT X :: PRINT "GAME OVER" :: CALL SCREEN(L) :: NEXT L :: GOTO 100
520 REM ** CHARACTER INIT DATA **
530 DATA "000000783C1E4FE7E7FDFF03070F1E3C0000000000000181F15DF9C181000000"
540 DATA "0F7840404140406221281452AC1308108080C82410884427118101030282FE00"
550 DATA "31488780874023100B040100010204048C12E101E102C408F020800080402020"
560 DATA "01011324081122E4888180C040417F00F01E0202820202468414284A35C81008"
570 DATA "0000000001C221151521C301000000001C22418102145455555414028141221C"
580 DATA "040402010001040B102340878087483120204080008020D008C402E101E1128C"
590 DATA "3844828140282AAAAA2A2840818244380000000080C384A8A884438000000000"
600 DATA "100813AC52142821624040414040780F00FE8202030181112744881024C88080"
610 DATA "040402010001040B102340878087483120204080008020D008C402E101E1128C"
620 DATA "007F4140C0808188E4221108241301010810C8354A2814844602028202021EF0"
630 DATA "5CA5CA5CA5CA5CA5"
640 REM ** SPRITE SPIN DATA **
650 DATA 120,108,104,100,112,124,128,132
660 DATA 120,108,104,100,112,124,128,132
670 D,FL=0 :: FOR I=1 TO 5 :: IF SPR(I)THEN GOSUB 800! CHECK TO ERASE SPRITE
672 IF FL=0 THEN GOSUB 900! FIND NEXT UNUSED SPRITE
675 NEXT I
680 IF D>0 THEN CALL POSITION(#3,XPOS,YPOS) :: CALL SPRITE(#D+OFFSET,136,2,XPOS,YPOS,DSPD,0)
690 RETURN
800 CALL POSITION(#I+OFFSET,TY,TX) :: IF TY>186 THEN CALL DELSPRITE(#I+OFFSET) :: SPR(I)=0
810 RETURN! ERASE SPRITE THAT WENT OFF BOTTOM OF SCREEN
900 IF SPR(I)=0 THEN D=I :: FL,SPR(I)=1 :: RETURN! FIND NEXT UNUSED SPRITE
910 RETURN 

[+retroclouds]

Here are the modifications I did:

 

Line 250 seems to be expensive (RND function). I reduced the number of times this line gets executed.

Note this has an impact on the game difficulty (making the game a bit easier), but it still looks fine with me.

You could try to fiddle with "IF A=10" in line 330 selecting a different value for the later levels ?

250 A=0 :: DDT=RND*Z :: IF DDT>ZX THEN GOSUB 670
260 CALL POSITION(#1,XPOS,YPOS)
......
330 A=A+1 :: IF A=10 THEN GOTO 250
335 GOTO 260

 

Adjusted boundary checks, removed the lines 490,500,510, replaced the GOSUB's in line 270,280,290 with direct statements as these are faster. Also note the GOTO in line 270, no need to check line 280 if XPOS>175:

260 CALL POSITION(#1,XPOS,YPOS)
270 IF XPOS>175 THEN CALL LOCATE(#1,175,YPOS) :: GOTO 290
280 IF XPOS<58 THEN CALL LOCATE(#1,58,YPOS)
290 IF YPOS<10 THEN CALL LOCATE(#1,XPOS,10)
300 CALL JOYST(1,X,Y)

 

Changed collision detection. The main difference is that I first do a CALL COINC(ALL,C) in line 292.

There is no need in doing any further sprite collision checks if C equals 0.

292 CALL COINC(ALL,C) :: IF C=0 THEN 300
REM   ***********************
REM   * START COLLISION CHECK
REM   ***********************
294 FOR I=1 TO 5 :: IF SPR(I)THEN CALL DISTANCE(#1,#SPR(I),C) 
REM 295 DISPLAY AT(5,15):"SPRITE:";I
296 IF (C>0) AND (C<32) THEN 340
297 NEXT I 
REM   *********************
REM   * END COLLISION CHECK
REM   *********************

 

The CALL COINC(ALL,C) seems to be very reliable. The idea is that you first check if there is a sprite collision between

any of the sprites. If that is not the case you can just skip the rest. ok, I'm not an expert on this, but I presume

that the assembly language routine that is executed, just checks if the sprite collision bit in the VDP status register is set.

In other words the VDP itself checks if there is any sprite collision. Now, it doesn't get much faster than that.

The problem however is detecting which sprites have collided. There is no implementation in hardware for this.

I used the CALL DISTANCE instruction for testing. Not very pleased with that as this part is still too slow.

 

For debugging purposes you can add the below. However, don't forget this instruction takes a bit of time too.

295 DISPLAY AT(5,15):"SPRITE:";I

 

The game itself is now a lot more responsive, but there is still room for improvement in the collision detection routine.

You could work around the collision detection problem by just letting the bee die as soon as 2 sprites collide.

However, it would require a redesign of game play and I'm sure that is not what you are looking for

Edited January 17, 2010 by retroclouds

[Opry99er]

First of all, thank you guys for your input..... It is so encouraging to be in a forum where other programmers are enthusiastic about new game development. I was about to implement all the graphics and then shelf this project until I could learn assembly enough to write some subroutines.... With the new modifications, I think it will be possible to have a playable game by the end of the contest. Now, for responses..... Yes--- the CALL COINC(ALL,C) is most definitely the fastest and most reliable detection command in XB... It does, however, leave the obvious and inevitable problem of unwanted coincidences. Therefore, your "fix" of skipping all COINC detection routines if "0" is returned in the (ALL,C) line is damn brilliant. So--- thanks for that... I have a few ideas in optimizing the coinc routines.... Will post new code later. . I should have screenshots on the flowerbed later today... Trying to figure out the best way to draw it... I like the earlier suggestions.... It will take up a minimum of 2 character sets (for color) and 9 display at or hchars for each of the 9 characters making up the flower. Honeycomb graphics to be complete asap and the engine for detecting a COINC between the play piece (#1) and the honeycomb (HX,HY) will be done by the end if this upcoming week. Game WILL be complete by the deadline. Thank you guys so much for your help!!!

[sometimes99er]

... and 9 display at ... for each ...

Hmmm ... Have you tried and run “Post #58” ?

 

[Opry99er]

On my iPhone, it does not show post #s. However, if you are referring to your earlier post, then no-- I have not been able to get on my computer yet today. I am not 100% sure how to use that example, as I do not know what your variables are referring to... Perhaps I have just not had time to study it adequately yet.

[sometimes99er]

I am not 100% sure how to use that example, as I do not know what your variables are referring to... Perhaps I have just not had time to study it adequately yet.

Well, I think when you see what it does, then it's "easier" to understand.

 

Anyways, I’ll try and break it down ...

 

100 CALL CLEAR::FOR R=0 TO 1::FOR C=0 TO 5

 

Clear the screen. Go through 2 rows. And go through 6 columns.

That’s actually 2 rows and 6 columns of flowers.

 

110 DISPLAY AT(R*3+19,C*4-R*2+5):SEG$("123I",1,3+R);

120 DISPLAY AT(R*3+20,C*4-R*2+5):SEG$("4*5I",1,3+R);

130 DISPLAY AT(R*3+21,C*4-R*2+5):SEG$("678I",1,3+R);

 

The above displays a flower. Actually the leafs are numbers, the bud is an asterisk and stalk is capital i's.

 

110 DISPLAY AT(R*3+19,C*4-R*2+5)

 

First parameter is row and the next is column. First parameter ...

 

R*3+19

 

R only takes the value of 0 and 1. We multiply by 3 to make this distance between rows of flowers. We add 19 to adjust from the value 0 and 3 (both R*3) to go to row 19 and 22 on the screen (at the bottom of the screen).

 

Second parameter ...

 

C*4-R*2+5

 

Again R takes the value of 0 and 1. We use this to avoid drawing the flowers directly beneath the other. In other words we adjust the start of the column. In the first row the column adjustment is 0 (R*2). In the second row it is 2 (R*2).

 

C goes through 0, 1, 2, 3, 4 and 5 to draw 6 flowers per row. We start a flower every 4 column. Hence we multiply C with 4. To centre everything a bit we add 5.

 

110 DISPLAY AT(R*3+19,C*4-R*2+5):SEG$("123I",1,3+R);

 

So now we know _where_ something is displayed. Now we gotta know _what_ that something is (to display) ...

 

SEG$("123I",1,3+R);

 

SEG$ takes a segment from a string. First we got the string to operate on. Next parameter is the start position in the string. And the last parameter is the number of characters to get. So ...

 

SEG$("OWEN BRAND",3,5)

 

would return

 

"EN BR"

 

Since R goes though 0 and 1 then the first row will display

 

123

4*5

678

 

And the second row of flowers will display

 

123I

4*5I

678I

 

Hence getting the stalks drawn for support of flowers in the first row.

 

The output ...

 

  123 123 123 123 123 123
 4*5 4*5 4*5 4*5 4*5 4*5
 678 678 678 678 678 678
123I123I123I123I123I123I
4*5I4*5I4*5I4*5I4*5I4*5I
678I678I678I678I678I678I

 

[Opry99er]

Pretty awesome stuff... I'm just figuring out how to use the SEG$ with the character definitions... Obviously it works great with--->SEG$("123I)... Now just to figure out how to take my character definitions and plug them in. Sorry I'm so slow today... rough couple of days and NO TI time makes Owen a dull boy....

 

Your suggestions, as always, are spot on and very helpful, sir.

[Willsy]

Pretty awesome stuff... I'm just figuring out how to use the SEG$ with the character definitions... Obviously it works great with--->SEG$("123I)... Now just to figure out how to take my character definitions and plug them in. Sorry I'm so slow today... rough couple of days and NO TI time makes Owen a dull boy....

 

Your suggestions, as always, are spot on and very helpful, sir.

 

I think I would do a CALL COINC(ALL) and then only check WHICH sprites are in collision if ALL returns a positive.

 

Wonky.

 

(Today I am mostly eating hat-stands)

[+retroclouds]

I think I would do a CALL COINC(ALL) and then only check WHICH sprites are in collision if ALL returns a positive.

 

That's what I did in my update on Owens' program. Works pretty well, game is a lot more responsible.

However, finding out which sprites have collided does not always work 100% as that part is still rather slow.

[sometimes99er]

That's what I did in my update on Owens' program. Works pretty well, game is a lot more responsible.

However, finding out which sprites have collided does not always work 100% as that part is still rather slow.

I guess that would be responsive and not responsible ...

 

[Opry99er]

It is much more "responsive" and much more manageable... I'm getting down on some graphics today--- watch for some screenshots as soon as they're done.

[sometimes99er]

I was thinking ... If all the “enemy” sprites to check for are travelling in separate horizontal and separate vertical corridors respectively, then ... when a collision has occurred ... then the x and y position of the player indicates what horizontal and vertical corridors to check. We could end up only having to check for one horizontal and one vertical enemy.

 

[Opry99er]

I was thinking ... If all the “enemy” sprites to check for are travelling in separate horizontal and separate vertical corridors respectively, then ... when a collision has occurred ... then the x and y position of the player indicates what horizontal and vertical corridors to check. We could end up only having to check for one horizontal and one vertical enemy.

 

 

 

Interesting... this WOULD make much more sense... what would the code look like? As of now, collisions that occur between two non-play pieces sometimes cause a "screen of death"... and this is due to the CALL COINC(ALL,C) I think... It just needs to be tweaked to tighten it up... My original concept for the coinc routine was something like this...

 

200 FOR I=2 TO 10 :: CALL COINC(#1,#I,10):: NEXT I

 

However this caused significant drag as well... Your suggestion might solve all this sh**... but more than likely it will just get us "closer." =) Maybe I'm just not having enough fun yet. B) As far as the DDT erasure routine, it works specifically because the DDT sprites fall at the same rate and in the same order every time... That being true, you can check specifically for ONE at a time, in order, every time. I'm thinking of maybe setting up the DDT drop to offset the enemy bee sprites going horizontally to absolutely MAKE SURE they never touch each other... This would allow us to use CALL COINC(ALL,C) and nothing else to detect coincidences. That immediately solves the speed and COINC problem..... Whatcha think>?

[Opry99er]

I am not 100% sure how to use that example, as I do not know what your variables are referring to... Perhaps I have just not had time to study it adequately yet.

Well, I think when you see what it does, then it's "easier" to understand.

 

Anyways, I’ll try and break it down ...

 

100 CALL CLEAR::FOR R=0 TO 1::FOR C=0 TO 5

 

Clear the screen. Go through 2 rows. And go through 6 columns.

That’s actually 2 rows and 6 columns of flowers.

 

110 DISPLAY AT(R*3+19,C*4-R*2+5):SEG$("123I",1,3+R);

120 DISPLAY AT(R*3+20,C*4-R*2+5):SEG$("4*5I",1,3+R);

130 DISPLAY AT(R*3+21,C*4-R*2+5):SEG$("678I",1,3+R);

 

The above displays a flower. Actually the leafs are numbers, the bud is an asterisk and stalk is capital i's.

 

110 DISPLAY AT(R*3+19,C*4-R*2+5)

 

First parameter is row and the next is column. First parameter ...

 

R*3+19

 

R only takes the value of 0 and 1. We multiply by 3 to make this distance between rows of flowers. We add 19 to adjust from the value 0 and 3 (both R*3) to go to row 19 and 22 on the screen (at the bottom of the screen).

 

Second parameter ...

 

C*4-R*2+5

 

Again R takes the value of 0 and 1. We use this to avoid drawing the flowers directly beneath the other. In other words we adjust the start of the column. In the first row the column adjustment is 0 (R*2). In the second row it is 2 (R*2).

 

C goes through 0, 1, 2, 3, 4 and 5 to draw 6 flowers per row. We start a flower every 4 column. Hence we multiply C with 4. To centre everything a bit we add 5.

 

110 DISPLAY AT(R*3+19,C*4-R*2+5):SEG$("123I",1,3+R);

 

So now we know _where_ something is displayed. Now we gotta know _what_ that something is (to display) ...

 

SEG$("123I",1,3+R);

 

SEG$ takes a segment from a string. First we got the string to operate on. Next parameter is the start position in the string. And the last parameter is the number of characters to get. So ...

 

SEG$("OWEN BRAND",3,5)

 

would return

 

"EN BR"

 

Since R goes though 0 and 1 then the first row will display

 

123

4*5

678

 

And the second row of flowers will display

 

123I

4*5I

678I

 

Hence getting the stalks drawn for support of flowers in the first row.

 

The output ...

 

  123 123 123 123 123 123
 4*5 4*5 4*5 4*5 4*5 4*5
 678 678 678 678 678 678
123I123I123I123I123I123I
4*5I4*5I4*5I4*5I4*5I4*5I
678I678I678I678I678I678I

 

 

 

Karsten... if I'm not using a string like ("123") but instead wanting to display my redefined petals and whatnot, could a SEG$(CHR$(49),CHR$(50),CHR$(51)) be used??? I don't think it can--- pretty sure not... but if not, then how can I use the SEG$ function to display as you suggest here? A string of pre-defined characters works great, as your example shows, but getting THERE from HERE is vexing me. Sorry if this seems elementary... I've always just used FOR NEXT loops and HCHARs to display repetetive characters... this is a new technique for me. Thanks. =)

[sometimes99er]

Karsten... if I'm not using a string like ("123") but instead wanting to display my redefined petals and whatnot, could a SEG$(CHR$(49),CHR$(50),CHR$(51)) be used??? I don't think it can--- pretty sure not... but if not, then how can I use the SEG$ function to display as you suggest here? A string of pre-defined characters works great, as your example shows, but getting THERE from HERE is vexing me. Sorry if this seems elementary... I've always just used FOR NEXT loops and HCHARs to display repetetive characters... this is a new technique for me. Thanks. =)

You _are_ using "123", "jhUa", "xySixx" or whatever ... If you’re setting up your very own special string it could be something like

A$ = CHR$(30)&CHR$(127)

 

Read up on SEG$. Parameters are string, numeric, numeric. SEG$(CHR$(49),CHR$(50),CHR$(51)) would give an error.

 

Hope that helps.

 

Edited January 18, 2010 by sometimes99er

[Opry99er]

I see now.... Very VERY cool... Alright.... I feel like an ass--- I read page 166 of the XB manual over and over, but until you mentioned that A$ can be "CHR$(XX)&CHR$(XY)&....., it never clicked. . Exciting stuff. I keep on learning every day.

[sometimes99er]

If the killer bees and DDT just moves in the own corridors, it doesn’t matter what position. If you had like 6 DDT predefined corridors, they could all fall at the same time, they just have to stay in they own corridors. Then when there’s a coincidence, the players x position will determine which single DDT to check for.

 

If you have 6 fixed DDT x positions like 20, 60, 100, 140, 180 and 220. Let’s say that’s sprite no. 11, 12, 13, 14, 15 and 16. You’re having a collision. The player is at x position 102, then it should be obvious, that you should only check further between player and DDT fixed at x position 100. So clever calculations could go from player x position to sprite no. Something like spr.no. = (x+20)/40+10.