Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

retroclouds

+AtariAge Subscriber
 View Profile  See their activity

  • Content Count

    2,118

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by retroclouds

  4. Posted

    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 ;)

  6. Posted

    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.

     

    :|

     

     

    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: :thumbsup: :thumbsup:

  7. Posted

    Assuming the game is worthy, and turns out as well as I hope, I'm making plans to make a small number of actual, physical copies of the game for sale, in a box, with printed instruction manual. The plan is to make no more than 100, and probably a lot less, depending on how I decide to print up boxes and manuals. I'm going to number each one and when they're gone, that's it. (I suppose I should say "if" they're gone...)

     

    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 :D

  11. Posted

    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.

  15. Posted · Edited by 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 ;)

  16. Posted

    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

  17. Posted

    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!

  19. Posted

    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 :ponder:

     

    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 :cool:

    • Like 1

  21. Posted

    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 :cool:

     

    oh, are still planning on having a seabed in the game ?

     

    Looking forward seeing more ;)

    • Like 1

  22. Posted

    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 :cool:

  23. Posted

    Does anybody remember a movie from the mid-'80s called "Cloak & Dagger?" There was a 2600 game in there called "Cloak & Dagger" that was the focus of most of the movie. I bet the code from this demo could be used in a TI version of that game. ^_^

     

    Edit: I wouldn't recommend putting stolen plans for top-secret military hardware prototypes in the cartridge, though... ^_~

     

     

    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

  24. Posted

    I can't use CALL MOTION, CALL POSITION, etc because these are all graphic characters, not sprites. There are actually no sprites being used in the game right now, though I may utilize them for an animation when a cat hits the "cat-a-pult."

     

    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 :D

     

    Just out of curiosity, how many cats will there be on-screen ?

     

    Keep up the good work! :cool:

  25. Posted

    Yeah, sometimes carefully planning can lead to some nice effects - even in Basic. I looked through some of my Basic tests. I’m sure I have a sideway brick scroller there - somewhere. Found lots of nice ideas and effects for demos and games - both Basic and assembler. Try this one out ...

     

    100 CALL CLEAR :: CALL SCREEN(5) :: CALL COLOR(1,6,1,2,16,1)
110 CALL CHAR(32,"000004000000000040E04")
120 CALL CHAR(40,"040E1F0404040C0404041C0404040C0404041F0404")
130 CALL CHAR(43,"0000FF44040000000406FF4604")
140 CALL HCHAR(1,1,40) :: CALL VCHAR(2,1,41,22) :: CALL HCHAR(24,1,42)
150 CALL HCHAR(24,2,43,30) :: CALL HCHAR(24,32,44)
160 FOR X=1 TO 28 :: CALL SOUND(400,110,30)
170 CALL SPRITE(#X,33,16,186,130+SIN(Y)*80+COS(Z)*26,-4,0)
180 Y=Y+.11 :: Z=Z+.39 :: NEXT X :: GOTO 160

     

    :)

     

    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 ;)

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...