retroclouds

Same here. I do my editing in a text-editor and copy/paste it into classic99 while having "CPU Overdrive" mode active. Small modifications I then do directly in extended basic. Works real well.

Thanks, this may come in handy one day Does anyone know the cheapest way to get good-quality cartboard boxes ? For my next game I really would like to have a cartboard box to go with it.

Will try it out this evening By the way, I just saw following folks in the TI-99/4A programming forum * +retroclouds, * sometimes99er, * TI99Kitty, * Willsy I'm seriously thinking about setting up or using an online chat functionality

Excellent! Another entry for the RGPC competition, now that is great news Will give it a try this evening

Note that you can also do stuff like: 100 CALL SCREEN(2) :: CALL CHAR(33,"C0C0C0C0C0C0C0C0C0C") 110 CALL MAGNIFY(2) :: CALL SPRITE(#1,33,16,60,1,#2,34,16,110,120,#3,33,16,90,253) For reference purposes I've posted a link to the extended basic manual. You might want to check the "development resources" sticky thread.

Very very cool! "Best performance with MESS. Only for use in Europe" .... Did you notice? this is post#100

You are #7 on the pre-order list for the first batch, you will be contacted

Just tried it out, and it's very good! I can't wait to see more These are fun times

This week I received all components required for doing the first batch of cartridges. So I'm pretty excited about that. Bad news is that I did have some unexpected costs for the first batch, that is the reason I haven't contacted anyone on the preorder list yet. Trying to keep costs to a minimum, but have to make sure I don't loose too much money on it. I'll be contacting the people on the preorder list, once I have most of the carts assembled and know about the shipping costs. Planning on posting some pictures of the assembled carts soon

Looking forward giving it a spin this evening

Excellent idea! You can keep the CALL COINC(ALL,C) and if 2 sprites collide you use your calculation. I think this should be really fast and a lot more reliable then my CALL DISTANCE usage. Very good :thumbsup:

I would be interested.... it's also a sign of a maturing TI homebrew scene. Also think that the TI scene needs a publisher, like they for example have for colecovision

Now that is great news! I can't wait to play your mystery game

Thanks for the hint, I'll update the list Still not there ? ooopps, sorry about that Will add it this evening, I promise ok, I've just added the reference to TIasm

Thanks for the hint, I'll update the list Still not there ? ooopps, sorry about that Will add it this evening, I promise

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.

Added my new tutorial "how to build a multi-bank ROM image". Enjoy

The Extended Basic reference manual (PDF version) is now online. Check here.

Made a few updates and added several new resources

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

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

wow, seems you are really pushing your game development progress I had many times while developing my game, where I wanted everything done at once. And then it is so nice to step back for a second and see how the pieces slowly start to fit together and watch how the game comes to life. That made quite an impression on me, and yes getting feedback sure helps Anyway, keep up the good work!

Hi there! It's nice seeing new games being written for the TI-99/4A :thumbsup: It's a nice little machine really. Do you have an Extended Basic instruction manual ? If not, I'll see if I can send you a PDF version Keep up the good work! retrocluds EDIT: in the meantime you might want to check here: Extended Basic online manual

Regarding the clouds; as this is a graphics mode 1 screen. Would it be possible to unroll the cloud patterns to the VDP before game start (while screen is off) ? You still have about 8K free space between >2000->3FFF, guess you could save on ROM space when combined with 256 clouds width. During gameplay you then copy the patterns from VDP memory into the pattern table. Dunno if that would be fast enough though, then again clouds move slowly Yes, there are quite some challenges when writing a game like this. Dealing with velocity, handling game parameters/screen boundaries, etc. This is interesting stuff