Here's the build of Frantic that was shown at PRGE. Al needed the demo ROMs at the start of October so he'd have time to build all the carts.
frantic_20231002_PRGE.bin
Changes:
Fixed issue where room sometimes changed color during transition to next room.
Revised robot death sequence - when hit the robot's shape is now briefly color cycled (like the humanoid's death sequence) before the explosion sequence starts.
Revised Otto logic for Fren
Been about a month since the last update for Frantic so I thought I'd spend some time on it.
Tryed out Maze Type as the default selected option. Not a fan, already changed back to Start for next build.
Added Diagnostic support like in Draconian, no longer need to create special diagnostic builds.
Noticed that the ARM routines were not using the audio interrupt routine (which will be needed when voice samples are added back in). It's been turned on - and I'm now seeing screen
LumaBoost in place, flickering objects will increase in brightness to compensate for the flicker
Special Room Object appears in the same location for a give X-Y room so that it doesnt change location if the humanoid dies and room is reinitialized
wall types (destructive vs reflective) surrounding Special Room Objects are now drawn based on the object.
Priority increased for Hit Special Object sound effect
halved the speed of Homing Missiles
Forced X position of
Moved routines from Vertical Blank to Overscan to fix screen roll problem
Special object animation in place
Big Otto's face will update, launches extra Evil Ottos with very primitive movement logic
Hit the Power Plant and robots can't move, but can still shoot
Hit the Central Computer and robots can't shoot and will randomly move (even into walls)
Factory doesn't do anything yet, but if you hit it the animation stops
Big Otto
Power Plant
Changes
Robot and Tank animation sequences are in place
Robot and Tank "cool down" logic implemented, should prevent "rapid fire"
Controls
RESET = start game
SELECT = return to menu
Left Difficulty, Frenzy Special Room Test1: B = Off, A = On
Right Difficulty, Stress Test Mode2: B = Off, A = On
1Frenzy Special Room Test will always put a special object in the room. Currently only Big Otto does anything, and it's the same experimental code as befor
missile/wall logic now checks all corners of the missile when testing for brick removal, fixes issues with Tank's Homing Missiles
missiles now reflect off flickering walls in Frenzy variation
ROM
frantic20140218.bin
Source
Frantic20140218.zip
Tanks now launch Homing Missiles
changeable wall color
menu is back
lots of ROM savings
Menu's back in place. All options should be functional, so let me know if something doesn't work as expected.
A couple Tanks launched Homing Missiles. They're shaped differently than the normal shots. The menu option sets the number of redirects each Homing Missile can make. Values range from 0-3 (0=no redirect). The "remove brick" routine needs to be updated to cop
I'm now at the point where I've implemented everything that was in the final build of the prior reboot
the RAM usage has been changed so there's space for the 2K speech buffer
preliminary animation
sprite clipping
etc
On top of that, the Stealth feature is in place, which wasn't last go around.
The new routines have saved almost 2K! Before there was 7372 bytes free (see the comments), now there's 9218 bytes free. Like before, the 9218 doesn't consider
Animation routines aren't in place yet, but we now have a playable build.
I always liked the Stealth Mode, so I've added that back in. It's currently controlled by the Right Difficulty switch. When enabled, all robots will initially be visible for 1 second. After that any robot that shoots will be visible for 1/2 second. If a robot is destroyed, all remaining robots will be visible for 1/2 second.
In the Frenzy version you can shoot out the solid walls - this can be handy
The missile routines have been added back. I also changed Otto to be a 2X sprite for testing purposes. It'll be changed back to a 1X sprite for the next build, which should be playable
I removed the original flicker logic routine and renamed the new one DisplaySprites. It uses DataStream0 and DataStream1 to populate the graphic and color datastreams for player0 and player1. Since the datastream usage is the same, I was able to merge those two functions into DataStream. The new
Sprite driver has been rewritten to work with the new kernel. I've also written an alternative sprite driver that improves performance, though there is a minor tradeoff when using it. I've set OPTIMIZE to 1, which causes some extra 6507 code to come into play. The extra code extends the display by 10 scanlines in order to show what's left in TIM64T for Vertical Blank and Over Scan. Some TVs may not like displaying a 272 scanline image, so it's possible this ROM will roll for some people. My C=10
Optimized the player 0 reposition routines for 200+ byte savings. The room generation is back in place to make it easier to test the timing of playfield updates - when the room shifts left/right any playfield timing issues become readily apparent. To aid in reviewing it, the playfield has been given priority over the players:
The X position display was changed to show which of the reposition routines are in use - there are 22 of them, 11 for each player. The routine used will b
For comparison, the top two robots are positioned using the standard reposition routine. The next two robots are positioned to the same X values using the new routines. The rest of the robots are repositioned to preset X locations using the new routines.
Move the joystick left/right to adjust the X position of player 0 and up/down for player 1. Hold fire to move slower.
Next up will be to do some ROM usage optimizations to the P0EarlyHMxx routines.
The revised Reposition Player 0 routines take 4 scanlines. The routines in the prior version took 6 (5 to reposition, plus 1 to get back into sync with the main kernel loop).
This screenshot shows reposition routines P0EarlyHM25, P0EarlyHM30, P0EarlyHM35, ..., P0EarlyHM70 being triggered (the red robots). They also show NUSIZ0 being updated (the red missile).
Unlike player 1, the player 0 routines do not have any late updates. There's also quite a bit of SLEEP going
The revised Reposition Player 1 routines take 4 scanlines. The routines in the prior version took 5 (4 to reposition, plus 1 to get back into sync with the main kernel loop).
This screenshot shows reposition routines P1EarlyHM25, P1EarlyHM30, P1EarlyHM35, ..., P1EarlyHM70 being triggered (the green robots). They also show NUSIZ1 being updated (the green & white missile).
I do have a single late update - ENAM0 is updated at cycle 25 in P1EarlyHM22. That won't be
Output from the new Kernel looks OK to me:
Due to the shift in timing, the new KernelEvent is more efficient than before. Before it looked like this:
KernelEvent: ; 3 27
; have to update PF2 before figuring out which Kernel Event, otherwise
; PF2 is updated to late in the Reposition Player 1 routines
ldx DS_PF2L ; 4 31
stx PF2 ; 3 34 - PF2L, before 38
sty PF0 ; 3 37 - PF0R, 2
Once again, Frantic is being rebooted
While working on Stay Frosty 2, Thomas Jentzsch suggested redoing the kernel to use VDELBL. It puts the ball on vertical delay with updates synced to GRP1. It's a clever idea - but due to how SF2 is designed that would have required me to draw the snowman using player(sprite) 1 instead of player 0, which would cause problems in the horizon due to object priorities:
I thought it could be useful for Frantic and Timmy, as their spr
I've freed up enough RAM so I'll be able to add back in the speech routines. Part of it was freed up by changing the sprite variables from INT (4 bytes) to UNSIGNED CHAR (1 byte). The routines can handle 24 sprites, and there are 9 different values stored for each sprite (such as X, Y, Image ID, Animation Frame, etc), so the original RAM usage was 864 bytes. After the change that only took 216 bytes. The rest was freed up by moving variables from the Display Data area into the Frequency table ar
New look for diagonal shots.
Robot explosions back in place, utilizing the new 2x sprite feature.
Doors are back in place.
Special room objects for Frenzy (Left Difficulty = A) in place. Only Big Otto does anything at the moment.
Evil Otto can be killed in Frenzy variation. Still some work to be done on this feature.
Sleeping until something happens
Happy the humanoid was neutralized
mad that little otto was destroyed, so launc
While there's still a lot to be added back, such as animations, Otto, and explosions, Frantic is once again playable.
ROM
frantic20120318.bin
Source
Frantic20120318.zip
The shot driver has been rewritten to take advantage of the new kernel. It supports up to 6 shots by using 30 Hz flicker.
Vertical shots are now 5 pixels tall instead of 8. One of the things I discovered before the reboot was that you could shoot a robot on the other side of a horizontal wall because the shot was too tall (horizontal walls are 5 scanlines tall).
Shots are drawn round-robin so each shot will be drawn using the ball, missile 0 and missile 1 over subse
The sprite driver has been rewritten to work with the new kernel.
Left Difficulty A = Frenzy layout
Left Difficulty B = Berzerk Layout
Right Difficulty A = all possible robots
Right Difficulty B = normal randomized robot count
The display at the bottom is XXYYFF where X and Y is the room location and F is the flicker factor.
0 = no flicker
1 = 30 hz
2 = 20 hz
3 = 15 hz
ROM
frantic_2012031
The wall generation routines are back in place, as are the room shift routines. This is so the Playfield updates could be checked (it's really obvious when the room shifts left/right if one of the PFx updates is occuring at the wrong time).
Use the Left Difficulty switch to select Berzerk or Frenzy layout.
Use right joystick to change rooms.
Use left joystick to position robots.
To check the PFx updates for all 22 reposition kernels I tested with X
Added some code to test the new reposition routines. Move the joystick left/right to adjust the X position of player 0 and up/down for player 1. Hold fire to move slower.
The topmost copy of each player is positioned using the standard reposition routines so that I could confirm the results were correct. The 2nd copy of each player is repositioned using the new routines. The remaining copies are hard coded and won't move.
I've also added the Score/Lives/Bonus kernel and a
The Reposition Player 0 routines have been rewritten. It now takes 5 scanlines to reposition player 0, plus an additional scan line to get back into sync with the main kernel loop. The player 0 graphics can start on the additional scan line, but a reposition of player 1 cannot be triggered on it as the BMI KernelEvent is what was dropped to get back in sync.
I was surprised that the reposition player 0 routines now take longer than player 1 (it used to take 2 and 3 scanlines respecti
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord