LASooner

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

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

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.

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

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

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

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!

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.

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.

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

Already compiled my game with it, no issues so far

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.

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

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.

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!

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

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.

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!

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.

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.

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?

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.

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.

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.

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.