globe

Yeah, joystick isn't ideal for this kind of game, with gamepad the controls are easier to handle and there's plenty of buttons for everything. Together with SNACK ability to work like Joy2B+ in Classic mode and run all 'normal' games and all hacked Joy2B+ games, it's a pretty good bang for the buck.

Here's Final Assault version 1.1 Zip is in the Download section: https://atari8.dev/final_assault/ Bug fix version with some cosmetic and game play adjustments. Changes: - fixed 'ballance' misspelling in intro text - fixed hard-coded subroutine call in intro pointing at 3 BRK instructions which made the game stop in emulators with 'Stop on BRK' setting enabled - ceiling and floor in game are darker and without dithering for easier orientation - music in intro now plays at correct speed on NTSC systems - gameplay adjustments: - time interval between player being noticed by enemy and enemy attacking lengthened from 2.5 sec. to 6.5 sec. - weapon cadence of flying sentry bot and boss bot slowed down by 25% - weapon cadence of armored sentry bot slowed down by 50% So all in all nothing big but it should make the game somewhat easier and a bit less visually confusing. Thank you all for your support, for pointing out the bugs and for improvement suggestions. Only some of them made it in Final Assault ver.1.1 because of space constrains but they're not forgotten and will be used in future projects. There's also one more xex file in the Final Assault 1.1.zip package: Final Assault 1.1 SNACK.xex This is a build specifically made for those lucky Atarians who got their hands on Irgendwer's - SNACK - SNES Atari Controller Kit and for those who plan to. I didn't manage to cram in all the previous controls + SNACK together, so this xex is specifically for SNACK controllers and won't work with normal joysticks (there's Final Assault 1.1.xex for that). Here's the controller layout: The whole game can be finished without touching the keyboard. Don't forget to switch to Enhanced mode and have fun. Happy New Year! Globe/GMG

Since I had a bit of free time during this hectic end of the year, ver.1.1 will be ready in a day or two (hopefully) and there will be difficulty adjustments besides the cosmetics (floor/celing) and couple of bug fixes.

1. davidcalgary29 - 1 cart 2. xrbrevin - 1 cart 3. skriegel - 2 carts 4. mchorvat - 1 cart 5. brenski - 1 cart 6. AtariSociety - 1 cart 7. Mathy - 2 carts 8. Haightc - 1 cart 9. Markk - 1 cart 10. Sleepy - 2 carts 11. Nezgar - 1 cart 12. Gunstar - 1 cart 13. Chaosfaktor - 1 cart 14. Wadeford - 1 cart 15. sanny - 1 cart 16. DNA128k - 1 cart 17. Senor Rossie - 3 carts 18. KlasO - 2 carts 19. NML32 - 1 cart 20. CharlieChaplin - 1 cart. 21. slx - 1 cart 22. David_P - 1 cart 23. Rainier - 1 cart 24. AtariPortal - 2 carts 25. patjomki - 1 cart 26. Allan - 1 cart 27. Toddtmw 1 cart 28. TheNameOfTheGame 1 cart 29. adam242 1 cart 30. Dan Winslow - 2 carts 31. Jinroh - 1 Cart 32. Philsan - 1 Cart 33. Lastic - 1 Cart 34. invisible kid - 1 cart 35. gozar- 1 Cart 36. pixelmischief - 1 cart 37. BigBen - 1 cart 38. Soulbuster 1 Cart 39. Ransom - 1 cart 40. TemplarXB - 1 cart 41. tuf - 1 cart 42. mariusz - 1 cart 43. leech - 1 cart 44. Firedawg - 1 cart 45. mani - 2 carts 46. code_blazer - 2 carts 46. Defender II - 2 carts 47. Curt Vendel - 2 carts 48. massiverobot - 1 pbi device 49. fandenivoldsk - 1 cart 50. sdewalt - 3 carts 51. panamajoe - 1 cart 52. Sugarland 1 cart 53. pedgarcia - 1 cart 54. JoSch - 1 cart 55. Mono - 2 carts 56. chouimat- 2 carts 57. TheMontezuma - 1 cart 58. OmaOhneBH - 3 carts 59. Freetz - 1 cart 60. Bowman1 - 1 cart 61. Umberto - 1 cart 62. gambler172 - 1 cart 63. Mr Robot - 2 carts 64. solaris104 - 1 cart 65. tschak909 - 1 cart 66. globe - 2 carts

Thanks, now I can double check my results. For 5 buttons if you want a safe combination, you can press 3 in one column and 2 in other 2 columns - in a row that isn't used by first 3 Example: 4,7,10 and 2,3 Combinations like this are safe. For simultaneous button presses absolutely safe are only 1 or 2 buttons at a time. From 3 buttons up strange behavior can happen because of the wiring but as far as addition to joystick goes it should work just fine. No, it's great. I only have one piece of CX21, which I'm fairly certain works correctly but I wanted to be sure. Also this is a confirmation that I'm reading the controller correctly. So thanks for your time.

While working on new control schemes for upcoming projects this kind of sort of happened so here's ATARI Video Touch Pad tester v1.0. Should work with Atari 2600 CX21 Video Touch Pad, Atari 2600 CX50 Keyboard Controller and Atari 2600 Kid's controller. First one was tested, last two weren't because I don't have the hardware, so part of this is also my request for whoever has access and a bit of time to try it out and report how it worked (or didn't:) There's a manual included but the operation is very simple. Run the program, attach AVTP or compatible controller, which should be automatically detected and press buttons. Left half is for joystick port 1, right half for joystick port 2. Top table shows pressed buttons, bottom table shows pots and trigger values for each row (once the controller is connected and recognized). For debug purposes, even if you don't attach anything or if controllers won't get detected for some reason, pressing Start, Select or Option will display pots and triggers values anyway. There some more info about limits for simultaneous button presses and some odd (but expected) behavior description in the manual so check it first please if something strange happens (especially if you push a lot of buttons together and get strange readings). Globe/GMG AVTP tester v1.0.zip

Thank you.

Thank you for the great review, I'm glad you liked it. That's the plan, though it's only in early stages so it will take a while. This time I'm not going for complete 'radio silence' throughout the whole development so once I have something more specific to show, I'll share.

Nice one. Kind of unexpected it was discovered this way, not from Goldy's hint.

After watching the video... this is almost exactly what I'm doing, except for the incremental length calculation (I do that at the end after both start and end points are known) Don't expect too much. 1.1 will be bug fix and 'cosmetic enhancements' (darker floor) release without changes to controls and unlikely changes to things like line of sight checking (maybe if I find a way to 'fix' it that won't bloat the routine) All the other enhancements talked about in this thread will be probably implemented in some future version for machines with larger RAM.

One grid tile is divided to 32x32 subtiles. You can't always go the full range though, there's some limit how close to a wall you can get, and there's limit for enemies too because when they were licking the walls, clipping algorithm kicked in making them look weird - partially sticking out of the wall . 32 I think I messed up in earlier post and said that full turn is 256 steps, that's wrong. Full turn is 128 steps (was 64 at the beginning) The 256 steps for 360 degrees is from the raycaster.

Thank you, I'll definitely check it. Easier math sounds faster, therefore GOOD:) Though if you look at Permadi's tutorial chapter 7 https://permadi.com/1996/05/ray-casting-tutorial-7/ ''To find walls, we need to check any grid intersection points that are encountered by the ray; and see if there is a wall on the grid or not. The best way is to check for horizontal and vertical intersections separately. When there is a wall on either a vertical or a horizontal intersection, the checking stops. The distance to both intersection points is then compared, and the closer distance is chosen.'' I found a way to do this with only one check for intersections instead of two, one multiplication (for the distance calculation) and no distance comparison (there's nothing to compare) which speeds things up significantly. Not going to spill my beans (yet) but as far as performance goes drawing takes roughly 49% of CPU time but raycasting only 27% (all of this assuming I didn't mess up while using ALTIRRA's Profiler which is possible)

The first, completely failed grid tile sized check had 14x14 resolution (16x16 tiles map segment with wall along the outer edge where no player or enemy can enter) Second, much slower, partially failed check had 448x448 resolution (one grid tile is subdivided in 32x32 smaller grid for player / enemy movement) Second check 'version B' had 224x224 resolution, you can probably guess why. Currently used shoot-me-from-behind-the-wall-baby check uses 56x56 resolution. For the first and the last, yes. For the second, that I think could get near perfect results it's pretty comparable if you look at the resolution. Sure I don't have to deal with bit operations, colors and other 'real drawing' stuff but I have some extra checking to do instead. As for 'all over the screen' part. It's not really that different, both player and enemies can run all over the map. One thing is significantly different though, my 'canvas' has walls, so the more walls there are the shorter the LoS lines could be before they hit a wall.

In the version for larger RAM machines absolutely. Just wondering, I get various fast turning and 90 degrees turning requests but 180 degrees seems only useful when you decide to 'go back', for traversal, since usually there shouldn't be any enemies in direction where you came from. I mean, there are no complicated map segments where enemies would be able to sneak behind your back. Thanks, I'll check it out. Not sure what the question means. Some of them aren't shooting at all (floating mines) so they're excluded from LoS check. For the rest the checks are relatively frequent because of how the whole enemy aggression works. Don't want to write another page-long post so let's just say there's couple of phases and player gets a bit of leeway and audio warning in the beginning instead of being blasted by bots as soon as he gets spotted. (for detailed enemy attack behavior there's [ENEMY INFO] section in the manual) See post #237 image 1 for grid tile check trouble. Red square = enemy, green squares = possible player positions, in both cases there's no obstacle between enemy and player at grid tile resolution while it's pretty obvious they can't see each other. What does 'do some match check' means anyway? Unless you do some proper line from enemy towards the player how else do you detect corners protruding and blocking the shot? I really wish it would. Sure it's somewhat more expensive but it it was 100% correct it would be a good solution Here's a rough sketch that shows what could go wrong at 'incorrect' angles and enemy/player positions. (nothing's really up to scale, just an illustration) Enemy CAN hit the player if it aimed a bit to the right from players center (talking from enemy POW) If you want to complicate this a lot more the flying sentry (blue floating ball) has gun in the middle but the armored sentry (grey bot) has guns at both sides The more I think about this the more I come to the conclusion that making it simple, flawed but IN FAVOR OF THE PLAYER would solve this. People would probably feel it's less flawed when they aren't getting shot from behind the wall by enemy they can't see. Roughly 2,5 years of coding and testing* with a couple of weeks for research before that. *that's 'hobby time' so sometimes I spent week worth of evenings coding drawing etc.. sometimes real life had priority and only small progress was made (or none), you know how that works.

This is how I felt most of the time

This could probably work. I like the 'out of sight out of mind' part. That's when player shoots the enemy and it works exactly as you described, if there's enemy slice in the middle of screen, under the cross hair and you pull the trigger, enemy gets hit (with first 3 weapons at least). My post was about enemy shooting toward the player. See post #237 image 2 for why this isn't always ideal solution. It's not really comparable. Raycasting doesn't 'draw' a full line, that would be too slow and wasteful. Only grid intersections are checked. For line of sight check I do 'standard' bresenham line and if you check a few 'fast line drawing' threads on AA you'll see how much that costs and how many per frame can be done (somewhere around 9 or 10 per frame IIRC and that's while CPU is completely dedicated to drawing) So '+couple casted rays' would definitely slow things down and there's 4 enemies in one map segment so multiply accordingly. To manage the last part I already do some simple scheduling so all LoS checks don't fire at once. Yeah, that' the thing. If you go from enemy center to player center things like post #237 image 2 will happen while it would be perfectly possible in that scenario for the enemy to hit the player if it aimed a bit more to the right. What I'm trying to say with all this: Perfect check is possible but unbearably costly, every other method is just a shortcut with different set of circumstances where it doesn't perform as required.

Line of sight checking was another tough nut to crack. First I tried to do simplest, cheapest thing and only check using the resolution of a grid tile (grid tile = square tile which is either wall or floor) hoping something at least partially useful will come out of it. Well, it didn't. Next attempt was a single precise line (which is more expensive to do cycle-wise) but that didn't go so well either. A lot of cases where player could clearly see the enemy but the enemy didn't 'see' the player and didn't start to attack at all (would be skewed too much in favor of player and we can't have that:). Foolproof solution would be to cast a lot more precise lines but that's a lot of cycles spent because line of sight checking can't be easily simplified like the ray casting part. In the end I went back the grid based LoS check, but instead of whole grid tile I divided the tile and did some adjustments according to player's and enemy's position inside the tile. Precision isn't 100% and the check errs in favor of enemy so shooting through corners of wall can happen. I don't see an easy solution to this besides making the check go in favor of the player but then cases like picture 2 in this post, especially with static enemies would happen. Couldn't find anything in immediate vicinity to throw so what else could I do? I like this excuse a lot, must memorize:)

Once you check it out, let us know. I'm sure it would be an interesting read for many to find out more about such a gem.

If you decide to use PMGs for enemies, I promise you're going to love the clipping part:) Anyway, you probably know the basics: calculate how far away the enemy is from the player (translate into 'wall depth' if necessary). Depending on zoom level (width) of the enemy and position on the screen, find out what wall slices he occupies and check enemy depth against wall depth, slice by slice. Possible results: 1. all wall slices are behind the enemy = easy part, draw the enemy with desired zoom level because there's no wall covering it, only clipping you may need is on the sides of the screen (for 40 bytes width screen, if you went with wide screen you'd avoid even this hassle). 2. all wall slices are in front of the enemy = you won, don't need to draw the enemy at all, just clear PMG memory or set horizontal registers to 0 3. enemy is partially covered by slice/s of the wall from one side, other side, both sides or clipped by left screen border or right screen border (while also being covered by the wall from the other side:) Things to consider: PMG zoom level: 4x zoom = one enemy pixel = 2 gr.9 pixels - you clip single bits 2x zoom = one enemy pixel = 1 gr.9 pixel - you clip bit pairs 1x zoom = two enemy pixels = 1 gr.9pixel - you clip 4 bits at once Alignment - does the enemy 'stands' at the border of the wall slice or in the middle (my enemies / objects are always aligned to gr.9 pixels, at maximum zoom level to whole bytes because I can't clip half the pixels from PMG player) PMG width: If you're going for something similar to this you'll notice that at 4x HW zoom enemy may occupy 5 - 8 wall slices depending on zoom level That should be more or less all. It's not a long routine but it's one I spent a lot of time with before it worked properly. If you go with softsprites it should be considerably easier to do this (though you'll pay the price in RAM and cycles for other things) Anyway, good luck making it work.

Gr.10? Yes, but there's only 9 color registers and considerations never went beyond switching PRIOR $D01B for a bit without making proper textures for it. Actually when player gets hit, GR.10 flashes for a frame (or two?) to show interference. I wanted to use some static noise for that but changing PRIOR $D01B was cheaper. Some downsides, some upsides but in the end the memory cost was too great. Upsides: -closer, big objects could be more detailed -more zoom levels than 12 -no 2 per view limit on objects and enemies (this has some extra cost because of overlapping of more objects wouldn't be as easy as with PMGs) -much easier clipping since you draw into wall columns (clipping was a nightmare with PMGs) Downsides: -farther, smaller objects and enemies would be blocky and less recognizable compared to PMGs, -because of the mode used they'd blend into the environment more -RAM cost: PMGs have 2x and 4x HW zoom (although you still need to handle the vertical stretching manually) so for 12 zoom levels used I only need to store data for 4 and get rest almost for free. You could try to work around this by storing only some zoom levels and doing scaling in software but then you'll be spending much more cycles than for PMGs. Then you need a mask and pre-shifted graphics if you want enemies to move at pixel resolution + associated cycle costs of doing bit operations.

Yes. Though sorting is kind of a strong word considering the limit of 2 objects/enemies in player's FoV. Basically I just check how many objects there are in front of the player (result should be 0,1 or 2) and if it's 2 then the closer one gets assigned PMG Player 0+1 and the farther Player 2+3 so they are shown correctly if they overlap.

Totally worth it:) Great. For some reason I thought it will affect both.

I gave it a quick test run and instead of 26353 Bytes total packed with 7zip, zopfli with 350 iterations squeezed the game data into 25966 Bytes. One page and a half extra for free, just because better compression program was used. Awesome! Did you experiment with higher # of iterations and did it slow down decompression significantly?

GOOD! If the game only lasted for a few minutes people would start to call it tech demo again:) That said Goldy wasn't joking about the 20 minutes clear time once players become familiar with surroundings. Hopefully fisheye correction and a bit more precision in larger version will remedy that. Well see. If you don't have trouble hitting once, shotgun also stuns the flying sentry or another good strat is the one I prefer, pick weapon 2, spray and pray:) Thought about it but then I realized I can use the backstory of a war + supersoldier as an excuse for all the gear being available from the start. (The real reason as you probably guessed, I couldn't fit few more pre-scaled PMG weapon graphics inside) Yes and no. While I wouldn't try to kill armored sentry with it and killing flying sentry is a bother because you have to hide between shots it's great for popping flying mines since they don't shoot back and there's plenty of static ones, serving as traps. Saves other ammo for more powerful enemies. Takes a bit of practice. bfg is twice as fast as rocket, it's easier to start with that one for training:) Yeah, something will be done about that. Didn't manage to come up with some easy to 'read' indicator, definitely something worth to consider. Yeah, probably could be fixed by having larger inventory and leaving it to the player when to pop up the medkit. Thank you. Congratulations! Save state or not, it's actually great to see someone went beyond looking around for a bit and then quitting.

You have to be a little more specific, this is way too vague:) There is a hint in the game webpage for players that want to take it easy and explore instead of desperately fighting for their lives.