Jump to content

retroclouds

+AtariAge Subscriber
  • Content Count

    2,284
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by retroclouds

  1. Made a few updates and added several new resources
  2. 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
  3. 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
  4. 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!
  5. 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
  6. 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
  7. Nice! Looking forward seeing this game in action.
  8. I've noticed that you have the SAT right before the screen tiles. I have been studying Colecovision Galaxians and they have a similar VDP setup. SAT at >1B80 Tiles at >1C00 It allows them to write updated sprites AND tiles, without having to set the VDP write address twice. That's kinda cool oh, are still planning on having a seabed in the game ? Looking forward seeing more
  9. I just ordered my 3rd one For those who don't know this device. It has 32K RAM memory and reads compact flash cards that contain TI-99 disk images. This little piece of equipment replaces my peripheral expansion box for most of my requirements. Combined with TI-DIR (file manager running on windows, looks like norton commander), it's a piece of cake transferring TI-99/4A software between your PC and TI-99/4A. All development I do is done on a PC with emulator and then tested on the TI-99/4A itself using this device. A very cool device
  10. Didn't know Cloak & Dagger, but searched a bit and youtube came up with the below. The descending elevator looks doable. Gameplay itself reminds me of Robotron:2084 http://www.youtube.com/watch?v=ltjQU3DNjj8
  11. Working with graphic characters is not necessarily bad. One benefit is you don't have to worry about "invisible" cats if you get 4 of them lined up in a row Just out of curiosity, how many cats will there be on-screen ? Keep up the good work!
  12. Nice! This is fun. We should put those little snippets up on a special page. These kind of small demos have the exact size for being published in TI magazines. I remember typing these in like 25 years ago
  13. thanks. It was just an attempt to do some scrolling in extended basic. yeah, Elevator Action is real nice and quite doable on the TI. Ofcourse I would opt for writing it in assembly language However, I think having a game with a "wall" in extended basic and scrolling left/right during gameplay could be doable. You are basically only redefining one character.
  14. Very nice! I like the one with "HERDING CATS" letters below the eyes
  15. Excellent! Looking forward seeing screen photos and pictures of the notes. This is cool
  16. no not at all, kinda hoping someone picks it up and turns it into a real game
  17. hmmm... not really, too much work. Although I must admit I like Elevator Action a lot and it was the main inspiration for doing this little demo http://www.youtube.com/watch?v=uoR3gaAsHFY
  18. Last week (and this afternoon) I had a little fun playing around with Extended Basic. I tried to see if I could do a scroll simulation and came up with the descending elevator. Dunno what I'm gonna do with it, as it's just a little demo. But thought of posting it here anyway. Enjoy REM ################## REM # INITIALISATION # REM ################## 10 CALL CLEAR :: CALL SCREEN(1) :: CALL COLOR(1,5,8,2,16,2,3,16,2,4,16,2,5,16,2,6,16,2,7,16,2) 15 CALL CHAR(32,"00FEFEFE007F7F7F", 33, "00FEFEFE007F7F7F",34,"0000000000000000", 63, "1818181818181818") 16 CALL CHAR(47,"0000000000000000") :: CALL HCHAR(24,1,33,32) :: CALL MAGNIFY(4) 17 CALL CHAR(36,"1FFFFFFFFFFFFFFF",37,"FFFFFFFFFFFFFFFF",38,"F8FFFFFFFFFFFFFF",39,"FFFFFFFFFFFFFFFF") 18 CALL CHAR(64,"3F7F7F7F7F7F7F7F",65,"7F7F7F7F7F7F7F7F",66,"FCFEFEFEFEFEFEFE",67,"FEFEFEFEFEFEFEFE") 19 CALL VCHAR(1,5,47,120) :: CALL VCHAR(1,1,34,48) :: CALL VCHAR(1,31,34,48) :: CALL HCHAR(1,1,47,32) 20 DISPLAY AT(1,:"POINTS/00000//LIVES/3" 21 CALL SPRITE(#1,64,7,25,37,9,0,#2,64,7,45,37,9,0,#3,36,10,21,37,9,0,#4,36,10,50,37,9,0) 22 CALL POSITION(#1,A,B) :: CALL VCHAR(2,7,63,A/5) :: IF A<50 THEN GOTO 22 23 CALL VCHAR(8,7,63,6) :: CALL MOTION(#1,3,0,#2,3,0,#3,3,0,#4,3,0) REM ################# REM # SCROLL BRICKS # REM ################# 100 CALL CHAR(32,"00FEFEFE007F7F7F",33,"00FEFEFE007F7F7F") 101 CALL CHAR(32,"FEFEFE007F7F7F00",33,"FEFEFE007F7F7F00") 102 CALL CHAR(32,"FEFE007F7F7F00FE",33,"FEFE007F7F7F00FE") 103 CALL CHAR(32,"FE007F7F7F00FEFE",33,"FE007F7F7F00FEFE") 104 CALL CHAR(32,"007F7F7F00FEFEFE",33,"007F7F7F00FEFEFE") 105 CALL CHAR(32,"7F7F7F00FEFEFE00",33,"7F7F7F00FEFEFE00") 106 CALL CHAR(32,"7F7F00FEFEFE007F",33,"7F7F00FEFEFE007F") 107 CALL CHAR(32,"7F00FEFEFE007F7F",33,"7F00FEFEFE007F7F") 108 CALL POSITION(#1,A,B) :: IF A>83 THEN CALL VCHAR(14,7,63,3) 109 IF A<110 THEN GOTO 100 REM ############################ REM # SCROLL BRICKS AND GROUND # REM ############################ 110 CALL CHAR(32,"00FEFEFE007F7F7F",33,"00FEFEFE007F7F00") 111 CALL CHAR(32,"FEFEFE007F7F7F00",33,"FEFEFE007F7F0000") 112 CALL CHAR(32,"FEFE007F7F7F00FE",33,"FEFE007F7F000000") 113 CALL CHAR(32,"FE007F7F7F00FEFE",33,"FE007F7F00000000") 114 CALL CHAR(32,"007F7F7F00FEFEFE",33,"007F7F0000000000") 115 CALL CHAR(32,"7F7F7F00FEFEFE00",33,"7F7F000000000000") 116 CALL CHAR(32,"7F7F00FEFEFE007F",33,"7F00000000000000") 117 CALL CHAR(32,"7F00FEFEFE007F7F",33,"0000000000000000") 118 CALL POSITION(#1,A,B) :: IF A<124 THEN GOTO 110 119 CALL MOTION(#1,0,0,#2,0,0,#3,0,0,#4,0,0) 120 GOTO 120
  19. Just watched the vid. Nice, nice, very nice :thumbsup: Looking forward seeing more Actually I played around with Extended Basic last week. The first time in 22 years or so. I forgot how powerful it is. It's not really lightning fast, but you can really do some amazing stuff with it
  20. Beautiful, very beautiful :thumbsup: By the way: I'm currently finishing my utility+tutorial for handling realignment issues & code references accross multiple banks
  21. Very nice. So does this mean a cartridge EPROM is planned ? Would love to play this game on my barebone console I have in my living room
  22. Just gave it a spin in classic99. Collision detection works real nice :thumbsup: Just an idea: Do you think it's possible to let the bees flap their wings or would that bee to cumbersome in extended basic ? I'm looking forward seeing the flower bed
  23. Now, that is what I call interesting stuff As the clouds will move rather slowly would having a decompressed version in VDP be an option ? You could work on it in "parts" divided accross multiple frames and once complete, move it into the pattern table. Then again, such logic would also take some code space to implement. What I did in the cartridge version of Pitfall was to "page-out" certain parts of scratch-pad memory to the VDP, use the new free space as work-buffer and when finished "page-in" into scratch pad again. That works pretty well. However, I did not use any compression techniques in Pitfall! so looking forward learning on how you proceed
  24. Thanks for the detailed description on how you proceed. That is very interesting stuff. Oh on a sidenote, did you know a TMS9918 VDP implementation was done in javascript (using canvas for drawing). It's part of an MSX emulator written in javascript. Check here I have some plans for doing a utility that will be using this VDP implementation. As far as the RGPC naming is concerned, no use in changing its name now, with only a few more weeks remaining
  25. Interesting stuff Just out of curiosity. How do you test the animations and convert them to patterns ? Have you written an own converter for that ?
×
×
  • Create New...