Bones-69

December 14, 2021

Hey guys,

Been fooling with the idea of shaping the Beamrider concept into something with a similar theme for the TI. Intent would be to write in XB and compile.

Initially I thought this would be pretty simple to throw together until I invested some time and realised the horizontal scrolling scanline/s were a lot more difficult to replicate than I first thought.

If the scanline was to start just below the red sprite and move downward, every time it comes in contact with a Blue Lined character and passes on through - this would require an additional 8 characters definitions to produce the illusion. I've worked out a way to do it which basically involves a temporary row being overlaid and then every character in that row is redefined to produce the effect of a solid scanline passing through (actually pretty efficient as there are only ever between 9 and 3 characters that need to be defined at any one time in any given row). However it turns out I need 120 character definitions to do this (15 individual characters that each themselves have 8 variations), and a bunch of strings to make it all work. Seems I am going to be out 3-4K just for the price of this effect although the code will only be like 6 lines or something and should run pretty darn quick.

Has anyone got any thoughts on how this might be streamlined? I considered using a sprite overlay on each line intersection to negate all the above, but I would need anywhere between 6 and 2 sprites in a row which apart from the 4 sprites in a row "ïssue", I feel this is an unwholesome solution anyway. The only other option is I don't cross the lines, which makes the whole problem go away but I feel it looses something in the process. Below shows this super easy solution that could all be achieved with one character that SIMPLY goes FF, 00FF, 0000FF, 000000FF and then jumps to the next row after 00000000000000FF.

The only other thing I can think of is to manipulate the existing character strings by inserting a "FF" and controlling the string/char value as the FF moves its way down each Charcode. This would save a stack of memory, but I think performance would take a massive hit as instead of pulling the predefined characters definitions from memory and defining them in a single statement, I would have to perform several hundred (I calculated just under 600) string manipulations to complete one full screen pass.

Must be an easier way?

March 6, 2021

About 12 months ago I discovered FPV and haven't looked back. I have found it to be an amazing hobby. What is FPV? Probably easier just to watch a short video;

Part of the FPV attraction is the whole video aspect, which is understandable given it's cousin-type relationship with cinematic filming - and the general ability to film things from a perspective which would be otherwise impossible. Personally I have found it enjoyable to combine music and my videos together. Which got me to thinking....

I thought it would be super cool to come up with some type of TI inspired/programmed cockpit that I could overlay onto some of my videos. Maybe something like this;

I figured for it to look reasonable there would have to be some type of cockpit/scenery interaction. Maybe the cockpit needs to bank in time with the flight, maybe some instrument needs to respond accordingly, maybe it would just be enough for the controls to simply be in the right place at the right time.... Some experimenting would need to be done. I figure the cockpit could show fuel and thrust etc.... My initial idea would be to select a flight, learn it by heart, and then capture a video of me flying my FPV Cockpit program in synch with the video. Then I would just have to overlay the two and should end up with something rather silly but fun, and which has an overwhelming TI feel about it. It really was a shame there were no great cockpit type TI games or I would simply gravitate towards something classic.

I am behind with all things TI, but I guess I would lean towards writing something that can be run on the compiler.

Interested in input and ideas!

December 17, 2019

On 12/12/2019 at 7:21 PM, sometimes99er said:

Lately I've got this headache. Right now the plan is;

Headaches, Migranes, Cluster Headaches; I know this is probably not the appropriate place to make such a suggestion so some apologies in advance - But magic mushrooms can work wonders for this type of ailment if you continue to struggle. BTW, before I get shot down for making such an unorthodox suggestion, do be aware that they are non addictive and you can't OD on them. This is more than can be said for most prescription medicines....

December 17, 2019

Definitely XB. My whole world changed the first time I ever witnessed a sprite in XB. Excluding this I guess it would come down to Parsec, Return to Pirates Isle, or Tombstone City (Tombstone was the only cartridge I had for the first 3 months so it got hammered).

Special mention to Hopper and TOD!

July 23, 2019

On 7/22/2019 at 11:43 PM, senior_falcon said:

"Programs should be submitted as a disk image for ease of access by all." Can I upload a disk image from Win994a? Other than that I have no idea how a disk image is made.

Thank goodness - I was too embarrassed to ask.

June 23, 2019

This is great. Love it!

June 6, 2019

Submission: Boat Bomber

Platform: RXB

Written by: Darren Bellia

Instructions: Use joystick to avoid attacking plane, edge of space, and mountains. Use fire to bomb boat as it speeds by.

BBOMBER.dsk

June 6, 2019

Joystick or arrow keys move plane up and down and fire launches a missile at the boat. Don't fly off into space, don't fly into the mountains, and avoid the other plane. Although the COINC on the plane collision is pretty average....

100 U=124 :: CALL CHAR(36,"000307070F3F3F7F008080C0C0F0FCFF",U,"1C1E1F3F3F1F3F000",126,"0030C8FFFE8",33,"3C0C1E7F40407F000",35,"00F088FE0204F8")
110 CALL CLEAR :: X,W,Y,R=64 :: Q=12 :: A$=RPT$("$((%",:: CALL MAGNIFY(3):: CALL CHAR(92,RPT$("0",48),136,"AA55AA55AA55AA55"):: RANDOMIZE :: DIM E(33),P(33),S$(33)
120 CALL SCREEN(16):: CALL COLOR(1,3,5,2,3,3,8,Q,Q):: E(6),E(12),E(18)=1 :: FOR I=1 TO 33 :: P(I)=RND*30+5 :: A$=SEG$(A$,2,31)&SEG$(A$,1,1):: S$(I)=A$ :: NEXT I
130 E(24),E(30)=1 :: CALL SPRITE(#1,U,8,Y,X,#2,32,2,U,W,O,Q):: CALL HCHAR(13,1,40,R,15,1,92,R,22,1,92,96,1,1,136,128)
140 FOR I=1 TO 32 :: CALL HPUT(Q,1,S$(I)):: CALL JOYST(1,G,H):: CALL MOTION(#1,-H*2,0,#2,0,P(I)):: CALL POSITION(#1,Y,X)
150 CALL KEY(1,D,H):: IF Y<32 THEN Z$="ARE LOST IN SPACE" ELSE IF Y>83 THEN Z$="CRASHED" ELSE IF E(I)=1 THEN CALL SPRITE(#3,U,7,RND*49+36,1,0,21)
160 IF Z$="" THEN 170 :: CALL DELSPRITE(ALL):: PRINT "GAME OVER YOU ";Z$;"WITH A SCORE OF "&STR$(L)&".": :"TYPE RUN TO PLAY AGAIN." :: STOP
170 IF D=18 THEN CALL POSITION(#1,Y,X):: CALL SPRITE(#4,92,16,Y,X,100,25):: CALL MOTION(#4,0,0):: CALL LOCATE(#4,120,69+(100-Y))
180 CALL COINC(#4,#2,13,Q1,#1,#3,9,Q2):: IF Q2=-1 THEN Z$="COLLIDED" ELSE IF Q1=-1 THEN L=L+1 :: DISPLAY AT(2,27)SIZE(LEN(STR$(L)))BEEP:(STR$(L)):: CALL LOCATE(#2,U,1)
190 CALL DELSPRITE(#4):: CALL JOYST(1,G,H):: CALL MOTION(#1,-H*2,0,#2,0,P(I)):: CALL SOUND(-800,-6,20):: NEXT I :: GOTO 140

June 4, 2019

I let it run overnight, appears there may have been some excess generosity with the payout levels set..... :lol:

It is disturbing how mind-numbingly entertaining it is just to watch it - and even weirder the undeserved feeling of satisfaction/accomplishment when four of a kind spin up.

June 4, 2019

Here is a silly little XB slot machine 10 liner I threw together.... Let me know if anyone pulls off the jackpot (space invader, man, pacman & ghost - in this order).

100 RANDOMIZE :: DIM B(13):: CALL MAGNIFY(2):: FOR I=1 TO 4 :: READ A(I):: B(I)=A(I)::B(I+4)=A(I)::B(I+=A(I):: NEXT I :: READ W$ :: X=1000::S=1::CALL CLEAR::PRINT "YOU START WITH $1,000." : :
105 CALL CHAR(97,"00003C5A7E2442000018003C5A18242400003E6C787C3E0000003C5A7E7E5A"):: INPUT "WHAT IS YOUR MAXIMUM BET PERGAME? $":C :: IF C<=1000 THEN 110 ELSE PRINT "TRY AGAIN"::GOTO 105 
110 GOSUB 900::IF X-C>=0 THEN 130 ! WIN *MEGA JACKPOT* BY SPINNING SPACE INVADER, MAN, PACMAN & GHOST - IN THIS ORDER.
120 PRINT "INSUFFICIENT FUNDS TO       CONTINUE." : : "         GAME OVER     ": :"STARTING BALANCE WAS $1,000":"YOU LOST ALL YOUR CASH":"IN "&STR$(S)&" SPINS.   LOSER."::STOP
130 X=X-C :: GOSUB 900 :: s=s+1::DISPLAY AT(14,10)BEEP:"GOOD LUCK!" :: FOR D=1 TO 4 :: CALL COLOR(#D,2):: FOR I=1 TO 12 :: CALL PATTERN(#D,B(I)):: CALL SOUND(30,110+I*30,I):: NEXT I
140 I=INT((RND*4)+1):: CALL PATTERN(#D,A(I)):: A$=A$&CHR$(A(I)):: Z$(D)="-"&A$&RPT$("!",4-D):: NEXT D :: FOR D=1 TO 4 :: WI(D)=POS(W$,Z$(D),1):: NEXT D :: FOR D=4 TO 1 STEP -1 :: IF WI(D)<>0 THEN 170
160 NEXT D :: DISPLAY AT(14,10):"* NO WIN *" :: FOR I=1 TO 100 :: NEXT I :: GOTO 110
170 E=VAL(SEG$(W$,WI(D)+5,4))*C :: DISPLAY AT(14,4):"CONGRATS! YOU WIN $"&STR$(E)&"." :: FOR I=1 TO 10 STEP .5 :: CALL SOUND(-500,I*110,0):: NEXT I :: X=X+E :: FOR I=1 TO 500 :: NEXT I :: GOTO 110
900 CALL CLEAR :: DISPLAY AT(1,1):"AVAILABLE FUNDS $"&STR$(X):"BETTING AMOUNT $"&STR$(C)&"    " :: FOR I=1 TO 4 :: CALL SPRITE(#I,45,2,80,70+I*20):: NEXT I :: A$="" :: DISPLAY AT(24,1):S::RETURN
1000 DATA 97,98,99,100,-aa!!0001-bb!!0001-cc!!0001-dd!!0001-aaa!0010-bbb!0010-ccc!0010-ddd!0010-aaaa0100-bbbb0100-cccc0100-dddd0100-abcd1000

June 3, 2019

Very Clever!

Did it a few times, 130 seems to be my best.

May 23, 2019

Would be great if sprites could be positioned on the 256 x 192 grid rather than the clunkier 32 x 24. Is this something that is workable?

April 3, 2019

Have been throwing more time at this idea and it is evolving. Pretty much got all the sprites and character map sorted. Started working on the background graphics and general rules for how to move around in the environment. Worked out how I am going to set triggers during the game to create certain events, reveal secrets etc.

While it will come with a loading delay between screens, I have decided to load each screen from disc. This will require fetching 4 records which will total 768 bytes every time player moves into a new screen. Doing this allows me to keep the graphics prettier and I shouldn't have to worry about memory issues. My current concept has a total of 133 screens. 19 above ground and 114 below although I am still flexible regarding this mix (with a preference for creating more screens above ground and less below). Above ground screens will resemble something like pitfall game-play and the below ground screens will be more like a traditional platform style appearance. That's the current thought process.

Would be great if the old TI supported two fire buttons. One to jump and one to fire.... I feel just a jumping game has some limitations and will get old quick. Thinking about if it would be feasible to have two modes.... When in mode one you can jump and when in mode two you can fire. I do feel that having to use the keyboard to select each mode would be painful so not sure if this idea is worth pursuing.

February 24, 2019

Du bist n ferkel..... I'll be in my bunk.

Posted February 13, 2019 · February 13, 2019

I have a whole bunch from TISHUG (Texas Instruments Sydney Home Users Group) from the mid 80's. I will do my best to scan and upload some of these over the coming weeks.

January 20, 2019

A tileset for the F18A. Some of it my own design, some of it (green) borrowed from the net.

tileset.png

Wow That looks so nice.

January 16, 2019

You are absolutely right. In fixing the inside of the cross I forgot about the 4 "quadrants". It's an easy fix, just need to add 4 more coordinates to the string.

I will get around to clarifying the challenge with an image in the next day or two. Thanks Sometimes.

January 16, 2019

Interesting. Looking good. Unfortunately it will miss more than what's mentioned. And I'm thinking these are then rather simple sprites.

FarmerPotato might have something that can be used in XB256. Like when ALL has detected a collision (could be many sprites overlapping), now then take a look at only sprite #3 and #10 and see if they are really overlapping.

With some games there may even be the case where sprites seems to pass through each other, but are not overlapping in any individual frames. This can happen even with sprites only moving at 1 pixel per frame. Well, that's another story.

I had overlooked the diagonal possibility during my original thought process but ended up correcting it in the code (post #9). So in that example a coinc is detected in all positions that it should

I have the situation of not being able to use ALL to drill down at almost any point., I have a design where sprites hide behind other sprites to give the effect of "popping up". I guess there is always a workaround, but I am trying very much to avoid it....

January 15, 2019

Quick little test & seems to work OK! Is detecting a dot/dot coincidence between two specific sprites, without using CALL COINC.

Use arrow keys;

100 CALL CLEAR :: CALL SCREEN(2):: FOR I=1 TO 12 :: CALL COLOR(I,15,2):: NEXT I :: CALL MAGNIFY(3):: DISPLAY AT(24,1):"COINC:"
110 S$="!-30!-31!-21!-12!-13!03!13!12!21!31!30!3-1!2-1!1-2!1-3!0-3!-1-3!-1-2!-2-1!-3-1!20!02!0-2!-20!10!00!-10!01!0-1"::Y=100 :: X=100
120 CALL CHAR(124,"0000000000010107070101000000000000000000008080E0E0808",128,"0000000000000001010000000000000000000000000000808")
130 CALL SPRITE(#2,124,7,80,X,#1,128,5,Y,X,#3,124,14,50,50,0,10,#4,124,14,50,50,0,-5,#5,124,14,50,50,0,5)
140 CALL KEY(0,A,B):: IF A<8 OR A>11 THEN 140
150 ON A-7 GOTO 160,170,180,190
160 X=X-1 :: GOTO 200
170 X=X+1 :: GOTO 200
180 Y=Y+1 :: GOTO 200
190 Y=Y-1
200 CALL LOCATE(#1,Y,X):: CALL POSITION(#2,A,B):: A=A-Y :: B=B-X :: A$="!"&STR$(A)&STR$(B):: C=POS(S$,A$,1):: IF C=0 THEN A$="NO" ELSE A$="YES"
210 DISPLAY AT(24,7):A$ :: GOTO 140

January 15, 2019

Thanks for the feedback and links guys - all very helpful stuff. I hadn't anticipated it would be this hard. For XB to not support dot-coincing between specified sprites I probably should have realised there was more to it.... I tried a few ideas on paper most of which were complicated, impractical, and took an absurd amount of steps and processing - but one idea seemed to have some potential, especially if it was XB compiled;

It would be effortless using CALL POSITION to determine if the 64 dots of any MAGNIFY 3 sprite were in a situation where they might overlap with a second sprite. This could be determined from the the Upper Left Hand Corner position of each sprite. A minim overlap of one dot creates a potential 46 x 46 grid with the reference sprite being centered at position 16,16 (46 is determined by 16+15+15).

If the two sprites fall within the 46 x 46 grid, the relative position of one sprite to the other sprite could be stored as a string. If the known positions for a coincidence were determined in advance, a "master string" could then act as a reference point for all such Y/X coordinates. Determining a dot-to-dot coincidence would then just be a case of searching one string within the other.

So I think the steps would be;

-Initial check to see if a coincidence is possible (if two sprites fall within the 46 x 46 grid), and if so;

-Store relative coordinates of second sprite as a string

-Search "master" string for the second sprite coordinate string using the POS command

-If the returned variable in the POS statement is not equal to zero, a coincidence between two sprites has taken place.

This idea seems like it might work although some effort in advance would be required to create the character "Coincidence Strings". Not sure if the concept is clear so I have Illustrated the idea in my attachment.

*For the illustrated example I have not "stringified" the center of the cross, this would probably be necessary - especially to dot-check sprites that were in motion.

January 11, 2019

I have so many it is depressing. My problem is that when life gets in the way and I eventually return (even after just a few weeks), I have lost the thought process completely and can't even follow my own code. I need to learn how to document things so I can pick-up where I left off. I invested literally a few hundred hours in a single game (an adventure), and it is all gone.

January 11, 2019

From the XB Handbook in regards to the CALL COINC command;

Format

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

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

CALL COINC( ALL, numeric-variable )

If the keyword ALL is given, sprites are coincident only if one or more of the dots which make them up occupy the same position on the screen. If two sprites or a sprite and a location are given, then tolerance must be specified, and two sprites are coincident if their upper left hand corners are within the value specified by tolerance. A sprite and a location are coincident if the upper left hand corner of the sprite and the position specified by dot-row and dot-column are within the value specified by tolerance. These coincidents are reported even if there is no apparent overlap of the sprites or the sprite and the position.

I created the following little program to get a better visual. Use the arrow keys to move the blue sprite onto/around the red sprite. Note when the two sprites are properly aligned that there is no coincidence under the ALL keyword (due to there being no actual dot overlap). BTW- The white background is not a sprite - only two sprites are used.

100 CALL CLEAR :: CALL SCREEN(2)::FOR I=1 TO 12::CALL COLOR(I,15,2)::NEXT I::CALL MAGNIFY(3)::CALL HCHAR(18,15,125,2)::CALL HCHAR(19,15,125,2)
110 CALL CHAR(124,"E0E0E0E0FFFFFFFFFFFFFFFFFFFFFFFF07070707878787878787CFCFCFFFFFFF",128,"1F1F1F1F000000000000000000000000F8F8F8F8787878787878303030000000")
120 Y=118 :: X=113 :: CALL SPRITE(#2,124,7,137,113,#1,128,5,Y,X)::A$="CALL COINC(#1,#2,"::B$(0)="YES"::B$(1)="NO"
130 CALL KEY(0,A,B)::IF A<8 OR A>11 THEN 130
140 ON A-7 GOTO 150,160,170,180
150 X=X-1::GOTO 190
160 X=X+1::GOTO 190
170 Y=Y+1::GOTO 190
180 Y=Y-1
190 CALL LOCATE(#1,Y,X)
200 FOR I=0 TO 12::CALL COINC(#1,#2,I,A)::DISPLAY AT(I+1,1):A$&STR$(I)&","&B$(A+1)&")"::NEXT I
210 CALL COINC(ALL,A)::DISPLAY AT(I+1,1):A$&"ALL,"&B$(A+1)&")"
220 GOTO 130

It would be a wonderful thing to be able to specify particular sprites (say #1 & #5) and have the function behave as it currently does when the keyword ALL is specified. ie- Be able to check a true coincidence between sprites *only* when two dots occupy the same screen position, rather than the scatter-gun approach of using the upper left hand corner plus a specified tolerance.

Does anyone have any ideas on how this might be achieved in XB? I imagine the processing might be too much for a regular XB program, but I doubt it would overwhelm an XB compiled program. I am basically trying to work out a method to detect a dot-to-dot coincidence without being forced to use the ALL Keyword (the use of multicoloured sprites make the ALL command mostly impractical).

Any ideas?

Full XB Reference;

COINC subprogram

Format

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

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

CALL COINC( ALL, numeric-variable )

Description

The COINC subprogram detects a coincidence between a sprite and another sprite or a position on the screen. The value returned in numeric-variable is -1 if there is a coincidence and 0 if there is no coincidence.

If the keyword ALL is given, the coincidence of any two sprites is reported. If two sprites are identified by #sprite-number, their coincidence is reported. If #sprite-number and a location are identified, their coincidence is reported.

If the keyword ALL is given, sprites are coincident only if one or more of the dots which make them up occupy the same position on the screen. If two sprites or a sprite and a location are given, then tolerance must be specified, and two sprites are coincident if their upper left hand corners are within the value specified by tolerance. A sprite and a location are coincident if the upper left hand corner of the sprite and the position specified by dot-row and dot-column are within the value specified by tolerance. These coincidents are reported even if there is no apparent overlap of the sprites or the sprite and the position.

Dot-row and dot-column are numbered consecutively starting with 1 in the upper left hand corner of the screen. Thus the dot-row can be from 1 to 192 and the dot-column can be from 1 to 256, (Actually the dot-row can go up to 256, but the positions from 193 through 256 are off the bottom of the screen.) If any part of the sprite occupies the position given, then there is a coincidence.

Whether or not a coincidence is detected depends on several variables. If the sprites are moving very quickly, COINC may not be able to detect their coincidence. Also, COINC checks for a coincidence only when it is called, so a program may miss a coincidence that occurs when the program is executing some other statement.

September 20, 2018

Have been fooling around with a game concept over the last week or so. Something perhaps similar to a Pitfall or HERO style game (single screen platform scroller I guess), set on some strange world where the player can jump and also use a Jetpack in certain areas. I don't envisage any shooting, just a "jump and avoid" style game.

Not sure at this stage if it should be something like Pitfall where it is one large continuous world, or more along the lines of HERO where each individual level is made up of several screens. I think I like the hero style as it seems to offer more flexibility.

Have a few ideas on how to draw each screen efficiently without using too much memory but do expect to rely on loading from disc from time to time. Would be XB compiled and need sprite flickering turned off, or have F18 due to the multicoloured sprites.

I have put together some screen ideas and experimenting with basic themes. I do like the overall feel of it so far.

September 18, 2018

Jetpack guy!

 
100 CALL CLEAR :: CALL SCREEN(6):: CALL MAGNIFY(3)
110 FOR I=1 TO 5 :: READ A$,A :: CALL CHAR(92+I*4,A$):: CALL SPRITE(#I,92+I*4,A,100,100):: NEXT I
120 FOR I=3 TO 16 :: CALL COLOR(#5,I):: CALL SOUND(-500,400,25,-5,25):: NEXT I :: GOTO 120
1000 DATA 000E1B111312141414130E0D01010101F0C0F0F804028A8AFA8AFC50505028F8,2
1010 DATA 0000000000010303030000000000000000000000F8742454040000A0A0000000,8
1020 DATA 0000000000000000000000000000000000300000008850200070000000000000,16
1030 DATA 0000040E0C0C0808080C01000000000000000000000000000004000000A0D000,7
1040 DATA 0000000000000000000000000C0C0C0400000000000000000000000000000000,2

September 16, 2018

That's a trick I've liked for a long time! I first saw it in Cavern Quest for XB (at least I think it was Cavern Quest). It was a typical XB "CALL COINC(ALL)" affair, and it created a timer by setting up two sprites at the top of the screen, one moving towards the other. When they collided, you'd die due to the COINC, making a very clever and free timer.

And here I was thinking this was my fantastic and original idea.....

Profiles

Forums

Blogs

Gallery

Events

Store

Posts posted by Bones-69