globe

Sorry, we're full:) Since I picked 64KB as one of the hard limits for this game there's only a couple of free bytes here and there, nothing really useful for anything but very small changes. Definitely going to aim for 128KB in the future. Well that's exactly what happened. Before last round of bugfixes $8A58 was a start of PMG memory cleanup routine. After fixing some boss fight bugs Marco found I repacked everything from scratch but missed this hardcoded label that moved to $8A5B. Another one for 1.1 bug fix list, thanks.

Thanks, noted for 1.1 version if (when:) couple of more issues pop up. Going to barge in for a moment. The idea was to make something similar to LucasArt's iMuse system where several melodies could seamlessly transition between each other depending on what's going on. Like slower, softer 'exploration' tune changing into 'fight' tune after the player gets spotted by the enemy. In the end it didn't happen because of memory limits but I hope we'll get it working in some of the future projects.

I'm surprised someone still remembers, RA was supposed to be a different game though, platformer/shooter with 256 color graphics. Thanks. This was kind of maybe-it-will-work-maybe-it-won't project and even when I was halfway through I still wasn't 100% sure it will be finished. So I choose not to make any announcements, to avoid pressure and disappointment if things don't work out in the end. @emkay Thank you. As for the music, I like it so I don't really share your opinion but there's a bit of guilt on my side as far as both tunes (main menu music and You Won music) are concerned. The game engine basically 'ate' almost all the RAM so I pestered Goldy to make the tunes as small as possible.

After more than 2 decades of inactivity we're back and we proudly present our new game: Final Assault It's a FPS for 8bit Atari computers with 64KB Ram, works on PAL and NTSC systems Story: You are enhanced human super-soldier, serving under Central Command of United Humanity Armed Forces, fighting against the A.I. onslaught. Your job is to infiltrate an old research facility and search for the KEY, a chip serving as a safeguard against A.I. running amok that could help win the war. Features: -raycaster engine running at 25 - 30 FPS -animated textures -simple lighting system -some walls can be destroyed -automap Screens: Controls: Some more screenshots, (very)short vids and Download: https://atari8.dev/final_assault/ Have fun, Globe/GMG

For simple fix you could set color registers (708-712) to zero.

After mashing and holding F8 for a few moments (KILL was triggered 5 times per frame) I made it out of the cursed KILL room. To my surprise after finishing last demo level, I got into next one and still was able to move around a bit.

I'll try next time I get there.

One more bug report: Encountered a crash in level 9 in a room with small poison potion after a hallway with two slicers. Rest is all cosmetics or small details: During the last minute countdown the timer blinks, in some rooms it's more noticeable than in others (timeout1.avi, timeout2.avi) Level 5 - pillar base outlines started to blink as soon as I climbed down to get HP flask and didn't stop till I climbed back up (blinking pillar bases.avi) Barely noticeable but strange. Level 7 - after getting knocked down by a guard, he didn't follow and stayed glued to the edge of upper platform knocking me down (without damage) each time I climbed back. Tried to reset his position by running around, leaving room, even going farther away but it didn't help. Not game breaking but slightly annoying because only way to proceed was suicide. This happens rarely, during several hours of play I only encountered it twice in the same place. (guard knockdown.avi) Level 8 - when climbing platforms on far right side of the level, player's sprite parts are not masked like elsewhere. guard knockdown.avi blinking pillar bases.avi timeout1.avi timeout2.avi

First, big thanks to all involved for absolutely awesome port of a great game. Keeping my fingers crossed so finishing goes as smoothly as possible. Working my way through the game I found a cosmetic glitch in level 4. In the room with the mirror blocking player's way if you jump up while being reflected, couple of sprite glitches appears above torches. mirror.avi

You're welcome.

Cover it with PMGs. Since you just need a vertical bar, you can write directly to 53261 / $D00D GRAFP0, set the size to x4 and position the player.

If you want to build upon 'single step' maze something like this https://www.youtube.com/watch?v=8FMDIEGeWwk could be the result. It's still 'single step' and 90 degrees rotation only, but in-between animations make it look smooth. If you want to go for completely free movement though the maze, you're probably going to have to start from scratch. Here's a great tutorial about the math involved that gets posted here occasionally: https://permadi.com/1996/05/ray-casting-tutorial-table-of-contents/

Absolutely awesome looking game that actually gets quite challenging later on with larger levels. I wish there was some legit way to continue, like passwords each couple of levels and maybe a bit more variation. For example levels with winter color scheme and some sliding before stopping, depending on player's horizontal speed.

Is the skull usable for something?

Thanks for the demo, it was awesome! Will wait for the full game with bated breath. If possible, could you make player's arrow in map screen blink? It was easy to find in the beginning but once the mapped area got large, sometimes I got 'lost' while using ladders.

Looks like the problem happens with COLOR command and D value 125. If you skip 125 whole circle gets drawn so a simple workaround would be: 155 IF D=125 THEN D=126 This skips one beam though. Other solution would be to use different variable for color, increment it and reset it to zero when it reaches 4. 125 C=0 160 COLOR C 165 C=C+1 167 IF C=4 THEN C=0 No idea why this happens though.

Specifically it looks like one of the styles of this Atari TTF: https://www.fontspace.com/atari-classic-font-f30342 Scroll down a bit and look at Atari Classic Smooth Style.

In cases like this it really helps to trace what the program does step by step. Example binary value we want to convert to BCD: 32770 Initial values: VAL1 = $80 VAL0 = $02 RES+0 = $00 RES+1 = $00 RES+2 = $00 Since we ASL/ROL VAL0 and VAL1 each loop it's easier to understand if we look at their binary value: VAL1 VAL0 10000000 00000010 Important: all our additions happen in DECIMAL mode so when you add $06 + $06 you get $12 not $0C as a result. --------------------beginning of loop----------------------------------------------------------------------------- 1st loop ASL/ROL: SETS CARRY to 1 <- this is where most significant bit from VAL1 enters our decimal addition loop VAL1 VAL0 00000000 00000100 RES+0 = $01 1 --------------------------------------------- 2nd loop ASL/ROL: CARRY = 0 VAL1 VAL0 00000000 00001000 RES+0 = $02 2 --------------------------------------------- 3rd loop ASL/ROL: CARRY = 0 VAL1 VAL0 00000000 00010000 RES+0 = $04 4 --------------------------------------------- 4th loop ASL/ROL: CARRY = 0 VAL1 VAL0 00000000 00100000 RES+0 = $08 8 --------------------------------------------- 5th loop ASL/ROL: CARRY = 0 VAL1 VAL0 00000000 01000000 RES+0 = $16 16 <- notice the result of decimal mode addition, without decimal mode we'd get $10 in RES+0 --------------------------------------------- skipping ... --------------------------------------------- 7th loop ASL/ROL: CARRY = 0 VAL1 VAL0 00000001 00000000 RES+0 = $64 64 --------------------------------------------- 8th loop ASL/ROL: CARRY = 0 VAL1 VAL0 00000010 00000000 RES+1 = $01, RES+0 = $28 128 <- and another one, this time we carried over to RES+1, without decimal flag active we'd get $80 in RES+0 only --------------------------------------------- skipping some more ... --------------------------------------------- 14th loop ASL/ROL: CARRY = 0 VAL1 VAL0 10000000 00000000 RES+1 = $81, RES+0 = $92 8192 --------------------------------------------- 15th loop ASL/ROL: CARRY = 1 <- this is the 1 from VAL0 that was finally rolled all the way left and reached CARRY VAL1 VAL0 00000000 00000000 RES+2 = $01, RES+1 = $63, RES+0 = $85 16385 <- and one more, we already have value in RES+2 - BCD 10K+ territory --------------------------------------------- 16th loop (the last one) ASL/ROL: CARRY = 0 VAL1 VAL0 00000000 00000000 RES+2 = $03, RES+1 = $27, RES+0 = $70 32770 --------------------------------------------- BCD RESULT: 03 27 70 = 32770 --------------------end of loop----------------------------------------------------------------------------------- So how does this work? We add value of each bit to RES+0 - RES+2 but instead of using a table with BCD representation of bit values we start with most significant bit and double it with each iteration while using decimal mode addition. So most significant bit from VAL1 gets doubled 16 times, the one next to it 15 etc... till we reach least significant in VAL0 and that one only gets added. All those bits doubled and added together in decimal mode give as BCD coded RES+0 - RES+2 as a result.

fighter.pic 192 x 28 STEALTH jet fighter's more advanced cousin. There's 6 bytes header + graphic data only. There don't seem to be any other extra data. mount.pic Six blocks with various mountain graphics. 6 bytes header, each graphics block preceded by 2 byte resolution in pixels (1st. 80 x 32, 2nd. 80 x 27 ... 6th. 32x27). allcity.pic Many blocks with sci-fi looking buildings (attached allcity.png shows only first 2 buildings and last one but there's 14KB of them). 6 bytes header, each graphics block preceded by 2 byte resolution, x res. is in bytes instead of pixels this time. (1st. 16 x 71, 2nd. 9 x 73 ... last 12x62). There's a border of $FF values on the left and bottom part of each block, maybe boundary for drawing routine?

Some more info would help, like resolution + color depth, if you still remember. Or if you don't mind, post some of the files so it's possible to check contents. Otherwise you could try using Atari Graphics Studio to open those files, it supports a lot of various graphics formats. http://madteam.atari8.info/uzytki/ags.7z

Hello Wes, one problem is video memory allocation. In your Display List you use 4000 bytes starting at the 4K boundary, then there's 96 bytes gap, then another 4000 bytes followed by another 96 bytes gap and remaining lines. For such fragmented Vram you'd need a custom line routine. Basic gets around this by not starting exactly at 4K boundary but 96 bytes later so when the 4K barrier is crossed the VRAM is still continuous without gaps. You could apply this to your display list and start 16 bytes after the 4K boundary (112,112,79,16,112), followed by 15 [* 101]. Second LMS would stay unchanged but instead of 15 [* 99], use 15 [* 101] again. This way you'll get 204 lines and continuous VRAM. 208 lines is kind of hard with this screen width since 4096 isn't divisible by 40 without reminder but it would be doable with narrow screen if you'd be ok with only 256 points of horizontal resolution instead of 320.

TEMP.CHA files are fonts, rest of the files are display lists + pictures/screens made using these fonts. (Colors in attached previews are made up.)

You can use Atari Graphics Studio with settings in attached screenshot, then load first 1200 bytes of resulting .mic file into your project. (no idea how to save only 160x30 cropped part, looks like AGS always saves full screen) test.xex

Checked on real machine, seems to work. No idea where the problem might be.

Didn't check on real machine. Before it was just a small routine where I directly changed color registers, then told WUSDN to compile and run to get my palette. Will check now.