Ribbon cable extender for the Firehose

[Ribbon cable extender for the Firehose]

I have one of these too, I got it from these guys, definitely saves desk space

 

http://www.connectworld.net/cgi-bin/hello-cables/L1172

[Night Stalker - (XB256 compiled) FINAL VERSION]

Update uploaded to first post.

 

 

Memory is getting tight, so I'm optimizing as much as I can. But I may lift my skirt in the next week or so and get other eyeballs on my code to see what can be done to improve speed and space

 

 

 

COMPLETED:

Bats and Spiders stun player

Add hit points to Level 3+ robots

BUGS:

Characters are being defined after the title screen comes up

STILL NEED TO COMPLETE:

Bats and Spiders die from bullet hits from either player or robots

Level 2+ Robots pursue player through maze

Level 4 Robot destroys bunker
Level 4 Robot shots kill player bullets

Add an attract screen mode, to give the player time to start the game and explain scoring
Bats start hanging from ceiling
Add delay before player and robot respawn

[Night Stalker - (XB256 compiled) FINAL VERSION]

I think I have a solution, All point values are hundreds or thousands, if I just add two zeros to the converted string, "200" Points would actually be 2 points internally. This means one could theoretically score up to 3,276,700 before you flip the score. I now return you to your regularly scheduled programming.

[Night Stalker - (XB256 compiled) FINAL VERSION]

OK, I missed this one.... how does one have a score that goes higher than 32767?

[Night Stalker - (XB256 compiled) FINAL VERSION]

BUGS:
Bullet still registers hits after dying if player doesn't shoot
Bats will start shooting at player after 5000 points, when the bats are supposed to become robots after death

Robot not switching to higher level robots after 15000 points

Fixed the issue with the score not drawing correctly (thanks Bones-69)

Also changed the spider color to light green, it looks better on a CRT

[Night Stalker - (XB256 compiled) FINAL VERSION]

 

 

Ahh so I can use STR$ to apply the numeric value into a string that can be displayed, that's what I was looking for.

 

Thanks!

That fixed the issue with the score showing up with blank spaces

[Night Stalker - (XB256 compiled) FINAL VERSION]

 

A few things come to mind... I am out and about so only going from memory at the moment, but think I am on the right track. If you use something like the following this is likely causing the spaces;

DISPLAY AT(1,1):"SCORE";A

Whereas the following should give you a better display;

A$="SCORE "&STR$(A)::DISPLAY AT(1,1)SIZE(LEN(A$)):A$

I think using the same A$="SCORE "&STR$(A) should allow you to use the XB256 feature. Again, only going from memory.

 

Game looks great by the way!

 

 

Ahh so I can use STR$ to apply the numeric value into a string that can be displayed, that's what I was looking for.

 

Thanks!

[Night Stalker - (XB256 compiled) FINAL VERSION]

As an aside, does anyone know how to keep the DISPLAY AT from adding a blank character to the left and the right of the value? IS DISPLAY AT USING the only way? Because that function doesn't compile. And unfortunately XB256's CALL LINK("DISPLAY") only uses character strings not values.

[Night Stalker - (XB256 compiled) FINAL VERSION]

FINAL VERSION. I've included source code and graphics, if anyone wants to improve the playability.

 

Thanks to TI99IUC For the cartridge label design

 

 

 

 

Uses Joystick 1, check your ALPHA LOCK before playing.

 

Updated 12/14/2018

 

 

NIGHTSTK8.bin Cartridge version (No Title Splash Screen)

NIGHTSTALK.dsk XB Disk Version (Includes Splash Screen)

Nightstalker - Manual.pdf Game Manual

Nightstalker-Source Files.zip All the source files to make the game.

[XB Game Developers Package]

I'm not having this issue, have you tried it on http://js99er.net/?

[XB Game Developers Package]

Here is the XB Game Developers Package "Chardonnay" version. This fixes the IF/THEN/ELSE bug that was in "Bordeaux". As far as my testing shows, the only limitation is that you cannot have nested IF/THEN/ELSE statements.

Somehow an older version of COMPRESS found its way into the package; that has been replaced with the latest version.

Additions to XB256 and the compiler are CALL LINK("SYNC") which lets you tell a loop how long to take. I will post a video showing a digital clock that uses this

Another addition is CALL LINK("RUNL1") which lets you load and run an XB program from another, but without doing a prescan. This means that variables are carried through into the new program and you don't have to store them and then retrieve them.

I have removed the DV80 version that was compatible with a real TI. It is a lot of trouble to maintain two versions and I can't see any benefit in spending time on that. I'm getting 72 errors when compiling Aperture on a real TI - I think there is something wrong with the runtime routines but don't know what. The programs created with Classic99 are compatible with real iron and that's really all that matters. If people complain enough I could revisit this.

Already compiled my game with it, no issues so far

[Moving a sprite through a Maze, Extended Basic]

Yeah, I'm trying to get it all working first, then make performance adjustments, It's already changed quite a bit since I posted that, I'm no longer checking all four sides, I check the direction that the joystick is pulled, this sped things up quite a bit, as it's only doing 2 GCHARs per loop if the Joystick is moved, it's created fewer IF/THEN statements.

 

Thanks for sanity checking stuff like this. It will help when I'm looking to speed things up before compiling. The faster it runs in XB the smoother it will be once compiled.

 

I have the directional firing from the player working, once I get the robot firing I'll start working on sprite collisions. Then working on the higher level robots ability to chase the player.

 

I'm really happy to see the progress I've made so far.

[Book : TI games for kids!]

You should use the code tags for all the basic listings, this will help avoid emojis showing up in the code

 

[XB Game Developers Package]

That's why slow moving adventure games would be a good candidate for this. Time to find an old "Choose Your Own Adventure" book and turn it into a game.

[Moving a sprite through a Maze, Extended Basic]

Time to take the wraps off what I've been farting around with. Here's my test, I have the player moving through the maze, Robot, Bats and Spider randomly moving through the maze, and I can pick up the gun and add bullets. I've only been working on this since last week. It is running CPU Overdrive because it's not compiled yet. But this is all very encouraging.

 

 

I felt like Night Stalker was good choice, Bomb Squad was a little too ambitious at this time. It only has 1 map, always 4 enemies, so basically once I get the base game working, getting to the finish seems more achievable. With tools like XB256, Magellan and TIdBit, it sure removes the barrier to entry.

 

 

The next challenge will be shooting and hit detection. But I'll probably clean up the player sticking to walls as much as I can. Thanks again everyone for the help!

[Moving a sprite through a Maze, Extended Basic]

So after adding 4 more points of character detection, he moves the maze pretty good, the only areas where he's having trouble is the ends of the walls, but I put IF/THEN statements in the movement subroutines to handle those positions and it's working fairly well. If the character gets really close to the wall he's moving slower but not stopping, and I'm not opposed to this behavior as it simulates wall scraping a bit, so I may just leave it. Most importantly adding the extra detection passes hasn't made that much of a speed hit compared to just 4. I took Mathew180's suggestion of removing the interim variable.

 

I use TIdBit so this is my detection pass

_MOVERETURN:


	_COLMAP:	CALL GCHAR(INT(MY/8)+1,INT(MX/8)+1,MZ1)
					IF MZ1=32 THEN GOSUB _LEFT
					IF MZ1=16 THEN GOSUB _LEFT
					IF MZ1=17 THEN GOSUB _LEFT
					IF MZ1=18 THEN GOSUB _LEFT
					IF MZ1=19 THEN GOSUB _LEFT
					IF MX>33 AND MY>33 THEN _COLMAP1
						FOR A=36 TO 45
							IF MZ1=A THEN GOSUB _WEBLEFT
						NEXT A
			
	_COLMAP1:	CALL GCHAR(INT(MY/8)+2,INT(MX/8)+1,MZ2)	
					IF MZ2=32 THEN GOSUB _LEFT
					IF MZ2=16 THEN GOSUB _LEFT
					IF MZ2=17 THEN GOSUB _LEFT
					IF MZ2=18 THEN GOSUB _LEFT
					IF MZ2=19 THEN GOSUB _LEFT
					IF MX>33 AND MY>33 THEN _COLMAP2
						FOR A=36 TO 45
							IF MZ2=A THEN GOSUB _WEBLEFT
						NEXT A	
			
	
	_COLMAP2:	CALL GCHAR(INT(MY/8)+1,INT(MX/8)+3,MZ3)
					IF MZ3=32 THEN GOSUB _RIGHT
					IF MZ3=16 THEN GOSUB _RIGHT
					IF MZ3=17 THEN GOSUB _RIGHT
					IF MZ3=18 THEN GOSUB _RIGHT
					IF MZ3=19 THEN GOSUB _RIGHT
					IF MX>33 AND MY>33 THEN _COLMAP3
						FOR A=36 TO 45
							IF MZ3=A THEN GOSUB _WEBRIGHT
						NEXT A
						
	_COLMAP3:	CALL GCHAR(INT(MY/8)+2,INT(MX/8)+3,MZ4)
					IF MZ4=32 THEN GOSUB _RIGHT
					IF MZ4=16 THEN GOSUB _RIGHT
					IF MZ4=17 THEN GOSUB _RIGHT
					IF MZ4=18 THEN GOSUB _RIGHT
					IF MZ4=19 THEN GOSUB _RIGHT
					IF MX>33 AND MY>33 THEN _COLMAP4
						FOR A=36 TO 45
							IF MZ4=A THEN GOSUB _WEBRIGHT
						NEXT A
		
	_COLMAP4:	CALL GCHAR(INT(MY/8)+1,INT(MX/8)+1,MZ5)
					IF MZ5=32 THEN GOSUB _UP		
					IF MZ5=16 THEN GOSUB _UP
					IF MZ5=17 THEN GOSUB _UP
					IF MZ5=18 THEN GOSUB _UP
					IF MZ5=19 THEN GOSUB _UP
					IF MX>33 AND MY>33 THEN _COLMAP5
						FOR A=36 TO 45
							IF MZ5=A THEN GOSUB _WEBUP
						NEXT A
						
	_COLMAP5:	CALL GCHAR(INT(MY/8)+1,INT(MX/8)+2,MZ6)
					IF MZ6=32 THEN GOSUB _UP		
					IF MZ6=16 THEN GOSUB _UP
					IF MZ6=17 THEN GOSUB _UP
					IF MZ6=18 THEN GOSUB _UP
					IF MZ6=19 THEN GOSUB _UP
					IF MX>33 AND MY>33 THEN _COLMAP6
						FOR A=36 TO 45
							IF MZ6=A THEN GOSUB _WEBUP
						NEXT A					
										
	_COLMAP6: 	CALL GCHAR(INT(MY/8)+3,INT(MX/8)+1,MZ7)
					IF MZ7=32 THEN GOSUB _DOWN
					IF MZ7=16 THEN GOSUB _DOWN
					IF MZ7=17 THEN GOSUB _DOWN
					IF MZ7=18 THEN GOSUB _DOWN
					IF MZ7=19 THEN GOSUB _DOWN
					IF MX>33 AND MY>33 THEN _COLMAP7
						FOR A=36 TO 45
							IF MZ7=A THEN GOSUB _WEBDOWN
						NEXT A
	
	_COLMAP7: 	CALL GCHAR(INT(MY/8)+3,INT(MX/8)+2,MZ8)
					IF MZ8=32 THEN GOSUB _DOWN
					IF MZ8=16 THEN GOSUB _DOWN
					IF MZ8=17 THEN GOSUB _DOWN
					IF MZ8=18 THEN GOSUB _DOWN
					IF MZ8=19 THEN GOSUB _DOWN
					IF MX>33 AND MY>33 THEN _LIMITS
						FOR A=36 TO 45
							IF MZ8=A THEN GOSUB _WEBDOWN
						NEXT A

[Moving a sprite through a Maze, Extended Basic]

I'm actually using a FOR/NEXT loop for my delay and putting the player input loop in that to increase controller sensitivity. I adjust the loop value to adjust the needed delay.

[Moving a sprite through a Maze, Extended Basic]

 

1100 ! CHECK FOR LEFT

1102 CALL POSITION(#1,PX,PY)::CX=INT(PX/8)+1::CY=INT(PY/8)+1::CALL GCHAR(CX,CY-1,CH)

1104 IF CH=112 THEN 2000 ELSE IF CH=104 THEN MY=MY+8::GOTO 90

1106 GOTO 90

1200 ! CHECK FOR RIGHT

1202 CALL POSITION(#1,PX,PY)::CX=INT(PX/8)+1::CY=INT(PY/8)+1::CALL GCHAR(CX,CY+1,CH)

1204 IF CH=112 THEN 2000 ELSE IF CH=104 THEN MY=MY-8::GOTO 90

1206 GOTO 90

1300 ! CHECK FOR UP

1302 CALL POSITION(#1,PX,PY)::CX=INT(PX/8)+1::CY=INT(PY/8)+1::CALL GCHAR(CX-1,CY,CH)

1304 IF CH=112 THEN 2000 ELSE IF CH=104 THEN MX=MX-8::GOTO 90

1306 GOTO 90

1400 ! CHECK FOR DOWN

1402 CALL POSITION(#1,PX,PY)::CX=INT(PX/8)+1::CY=INT(PY/8)+1::CALL GCHAR(CX+1,CY,CH)

1404 IF CH=112 THEN 2000 ELSE IF CH=104 THEN MX=MX+8::GOTO 90

1406 GOTO 90

 

 

 

That is basically what I'm doing as well, it's not as clean for a 16x16 sprite since I'm doing only 4 checks, I'm going to try adding 4 more and see if that slows it down too much

 

 

*- GCHAR position point

 

#- Sprite

 

What I'm currently doing

 * 
 ## 
*##*
  *

With these 4 checks it works perfectly when colliding with obstacles to the right and down, but left and up causes the character to get stuck, so I've had to include checks to see if the character has gone too far to the left, or too high up and reset their position to the next closest pathway

 

So I'm going to try doing 2 checks on each side.

 **
*##*
*##*
 **

Which I suspect will yield better collision,without having to check the character's position, but not sure at what cost performance wise doing 8 GCHARs per input loop.

 

 

 

Thanks for all the input guys, I appreciate it!

[XB Game Developers Package]

Point to remember is sprite data is the screen 1 character set, so if you have sprites in your game, screen 1 would be affected. You'll need to restore the character definitions before going back to screen 1. The good news is if you use compressed VDP data it doesn't take that long to do that.

[Moving a sprite through a Maze, Extended Basic]

I should mention that I'm using MAGNIFY (3), so the pathways are 2 chars wide. I am having some success, with using GCHAR, I have one for each corner of the sprite. I figured out the need to have it be (X/8)+1 earlier this evening so some brain cells are still kicking. If the character next to sprite is 32 in any direction, I only allow input in those directions. It's getting there. I will move the monsters away from auto motion and use LOCATE as well. But I'm not worrying about those guys yet.

 

I'm a 3D Artist for my day job, so interpolating X and Y is hard wired in my brain.

[XB Game Developers Package]

 

From the XB manual:

100 IF X>5 THEN GOSUB 300 ELSE X=X+5

100 IF Z THEN C=C+1::GOTO 500::ELSE L=L/C::GOTO 300

All should compile and run properly

Also,

100 IF X=3 THEN IF Y=1 THEN IF Z=4 THEN PRINT "PI"

This too works fine, but you might as well just use AND: 10 IF X=3 AND Y=1 AND Z=4 THEN PRINT "PI" ELSE PRINT "NOT PI"

 

I missed the last half of this the first time,

 

10 IF X=3 AND Y=1 AND Z=4 THEN PRINT "PI" ELSE PRINT "NOT PI"

 

are you saying would compile fine with the new version? So we can use AND in our IF/THEN statements?

[Moving a sprite through a Maze, Extended Basic]

So if X and Y are the dot values given by CALL POSITION, I would use A=INT(X/8) :: B=INT(Y/8) :: CALL GCHAR (A,B,Z)

 

Am I correct that Z would give me the character value under the SPRITE?

 

Sorry if these question sound newbie, programming isn't my strong suit.

[Moving a sprite through a Maze, Extended Basic]

I'm having trouble wrapping my brain around how to constrain player controlled and CPU controlled sprites through a maze. for the CPU controlled, I originally tried trigger spots, where the monster determines where it is and whether it's coincident with an intersection, then randomly select which direction to go by adjusting sprite velocity. The problem with this is the time it takes to scan through all possible intersections, and act upon it, the coincident detection has usually past. And my monsters just keep moving in that one direction. The player controlled, I can easily keep the player sprite within the confines of the screen, I'm using CALL LOCATE to position the player, and I can set minimum and maximum constraints for the screen, I have then determined where the vertical pathways are and only limit up and down motion through those avenues. But I don't know how to determine when a wall blocks that vertical path. I want to keep all this position polling to a minimum as it affects the animation of the characters because it has to be done during the game loop.

 

I don't see anyway to detect collision with a specific character which would be the easiest way, since the path is all CHR$(32)

 

I was just wondering how others may have tackled the task of moving player and CPU controlled sprites through a maze without clipping through walls using extended basic?

 

My intent is to compress this as I'm using XB256, so RXB is not really an option.

 

 

[XB Game Developers Package]

maybe a redistributable loader version of XB256 you could put on a disk image to launch your program.

 

What I imagine it would do is allow you to define which XB file you want to launch and it would create a LOAD file you put on your disk to auto execute when you select Extended Basic, start XB256, show a splash screen to get your due, then launch the defined XB256 program. Then you'd definitely know what programs make use of XB256

 

I really dig what you've done so far, I was planning on writing up a tutorial on how I use the compressed data during development.

 

And one day I hope to actually finish a program.

 

[XB Game Developers Package]

The other nice aspect of compiling is that it is self contained, you don't have to first run XB256, then run your program. I think that's why there isn't the motivation to release it as a straight XB.

 

it just makes it a cleaner presentation to run an E/A file or ROM bin.