The routines now report a collision only when sprite pixels overlap.
I've modified the joystick routines to use the right joystick to move Evil Otto. When he's moved the score will turn green to denote that his collisions are the ones being displayed.
Not touching (technically this should be touching - but the revolving eye is not stored as part of the sprite image).
Touching
Evil Otto collides with humanoid
Evi
I'm not able to use the TIA's hardware collision to detect sprite collisions as it's possible, due to flicker, that 2 colliding objects are never drawn on the same frame. As such, I've started working on a software collision detection routine.
Collisions are only tested for a sprite that is moved (saves a lot of time as most sprites are stationary on each frame).
The quickest thing to determine is if the rectangles containing the spites overlap - that's called Bounding Bo
The reposition routines have now been rewritten to support updating the missiles. The 2 missiles are flickered at 30 Hz to provide a maximum of 4 shots in flight.
I've also added test routines to move the 4 shots around the screen. 1 shot will be used for the humanoid, up to 3 for the robots. The shots can be displayed in 1 of 3 shapes: horizontal, vertical and small square. The small square will be used for a new robot-smart-missile feature I'm planning to add to compensate for fewe
The "new" Linux ARM compiler produces the same results as the OS X compiler that batari built. So either the OS X compiler was built with the current source, or the changes made are not relevant to Frantic's source.
In the source are 2 directories for the custom C routines:
In custom, the function ShiftRoom() directly precedes DataStream0().
In custom crash, the function ShiftRoom() directly follows DataStream0().
The functions themselves have not changed, only th
Just finished getting the main kernel loop revamped to support updating the missiles. To make it work I unrolled the datastreams for both left and right PF0. PF0 only uses the upper half of the byte, while the missile enable only uses one of the bits in the lower half, so I combined the data(left PF0 with Missile 0 and right PF0 with Missile 1). Due to timing issues, I load those datastreams into the X and Y registers as that gives me more flexible for timing the writes (the PF0 writes have diff
My folks are coming in from Trinidad this weekend. Their household is all packed up and ready to be shipped to Africa. They'll be leaving from Houston for dad's new job in Africa sometime next week.
My next step for Frantic is to update the kernel to turn on/off the missiles for the shots. My plan is to flicker the two missiles to provide 1 humanoid shot and up to 3 robot shots. If I can also get the ball to update then I'll do 2 human shots and up to 4 robot shots.
An al
Initial integration of the digitized sample playback routines. It sounds a bit rough at the moment as not all of the AUDV0 updates are in place.
Note: the speech can only be heard using a Harmony cartridge. I'll release a beta build of Stella later this week with support for the new DPC+DA driver.
ROM
f20110626_NTSC.bin
Source
Frantic20110626.zip
Think I figured out the cause of the glitch.
I use 4 datastreams to draw all the players(sprites in 2600 terminology) on the screen. Each player gets 2 datastreams, one for the image and one for the color. A 0 value in the color datastream is used to trigger a reposition of a player. The color datastreams are pre filled with 15 (white) so that missiles will be visible on scanlines without the corresponding player present.
When a reposition is triggered, 2 bytes in the ima
Preliminary flicker routines. They do mess up every once in a while, so no need to report that - just wanted to get an "offsite backup" posted in case I make things worse trying to figure out the source of the occasional glitch
Use left joystick to change rooms, robots will rearrange for each room. Use difficulty switches to control room display.
ROM
f20110617_NTSC.bin
Source
Frantic20110617.zip
For those with a Harmony, can you test this build and let me know if it works OK?
digitalaudio_harmony_20110614.bin
I've been experiencing crashes on my light sixer and 7800. On both it sometimes crashes right away, and other times it can complete a few words or even a few phrases before crashing. Eventually, "once it warms up", it stops crashing.
Batari's not able to find anything wrong with the new DPC+DA code, plus it runs OK on his system, so we're thinking it mi
Test of X values from 0-159. Use the RIGHT Joystick to move 2 of the robots. If you push upward the left/right movement is slowed down to facilitate testing. (2nd joystick keys for Stella are: Y = UP, G = LEFT and J = RIGHT).
The Room # is now the first 4 positions of the score. The robot's X value is the last 2 positions of the score. In the topmost strip of the room I've turned on all 8 pixels for the sprites. These are positioned using the traditional position object routine so th
hardcoded sprites for testing the repositioning routines for Player 1. Also did some color tests for the robots
ROM
f20110611_NTSC.bin
Source
Frantic20110611.zip
Not sure how clearly this comes across via YouTube as I'm so used to hearing & understanding the phrases (even down to 2000 Hz) from all the testing I've done. The demo is at 4000 Hz and the phrases are:
"The Humanoid Must Not Escape"
"Intruder Alert, Intruder Alert"
"Chicken, Fight like a Robot"
"The Chicken Must Not Escape"
Followed by the Intruder Alert message played back at a variety of rates.
http://www.youtube.com/watch?v=NEDP0Ch0j8M
With the packed data, I'm pretty sure I'll be able to make the simple phrases fit into the game. It also increases the odds of fitting in some additional words.
Instead of overlapping 2 samples together, I just packed each sample's data by itself. This means I only need 1 function to expand the data instead of 2. The utility raw_to_dpc was modified to pack the data when it converts the 8 bit samples to 4 bit.
Anyway, back to kernel development.
alex_packed_sim
Did the robotic 7-8 treatment on the voices that work at 4000. They all have the distortion that I don't care for.
Based on the experiments done so far, I'm hoping I'll be able to use Alex4000_simple4 from the prior blog entry, but until the game code has been written I won't know how much space I'll have to use for audio samples. I will decrease the quality (or even eliminate the samples) if needed, though there's also the change that there will be extra space allowing me to add an
An empty buffer is filled with an 8 for the waveform data as using 0 causes a noticeable click between words. The Display Data after the sample buffer is filled with 0, so if the program went past the end of the buffer the waveform on the screen wouldn't show anything. On the chance that just the ARM code stopped working and the 6507 was using data from after the sample buffer, I added a bit to the 6507 code to toggle the background color based on the right difficulty switch. However, the proble
Just for grins, did some builds using the Alex voice at 3 different rates: 2000, 3000 and 4000 Hz.
Sample space used for the 12 words:
2000 Hz = 7575 bytes
3000 Hz = 11365 bytes
4000 Hz = 15153 bytes
Edit: added Berzerk samples at 2000 and 3000 Hz
2000 Hz = 8743 bytes
3000 Hz = 13117 bytes
Edit 2: added Victoria samples at 2000, 3000 and 4000 Hz.
2000 Hz = 7537 bytes
3000 Hz = 11304 bytes
4000 Hz = 15072 bytes
In the prior example the entire phrase was put into the Display Buffer. For this test, I've revised the routines to use a 1K sample buffer. The buffer is filled in with $F8, then the word to be played back is copied into the buffer. The 6507 routines monitor for volume >= $80 which tells it to request the ARM routines to fill in the next word.
Not all of the voice tests were compatible with the 1K buffer. Some of them, such as the Berzerk samples, ended up having a word (humanoid
I found SoX and used it for the frequency conversion w/low pass filtering.
I created a bunch of test ROMs that utilize the original MAME Berzerk samples as well as the various built in voices on the Mac. To create the samples for the Mac voices I used the Speech System Preference panel, selected each voice and ran the script create.sh (in the samples folder of the attached source code), which creates audio files for each word.
I then ran convert.sh, which runs sox to conv
I did some testing for sample playback. I used 2 different samples for the word "humanoid", one from the Berzerk samples used in older versions of MAME, the other uses the Mac's built in speech synthesis with the Zarvox voice (with speaking rate set half way between Normal and Fast). I chose the humanoid sample as it was the longest in duration of the Bezerk samples.
The Berzerk sample seems a bit noisy which is why I decided to try the Mac's built in Zarvox voice. Also I would like
hardcoded sprites for testing the repositioning routines for Player 0. There's 2 DataStreams, 1 for the color and another for shape. The color stream is always read first. It will contain a 0 whenever Player 0 needs to be repositioned (1 is used for black). The reposition prep is contained in the next 2 Graphic Datastream bytes and the next Color Datasteam byte, so a reposition takes 2 scan lines.
At the moment I'm using Early HMOVE so there's no black bars on the left edge of the sc
My sister's taking a little longer than to expected to get here, so I put in the new title graphics while I've been waiting. The graphics didn't work as is though, I had to shift the letters FRANT to the left by 1 pixel due to PF alignment of the 2nd color.
The colors I'm using are:
FranticLogoColor:
.byte 0, HAIR ; 0
.byte 0, FACE ; 1
.byte WHITE-4, FACE ; 2
.byte RED+6, RED+4 ; 3
.byte WHITE-6, WHITE ; 4
.byte WHITE-2, WHITE ; 5
.byte WHITE-2, WHITE-6 ; 6
.byte WHITE-4, WHITE
RL events mean the next update won't be until next week.
I'd been planning to use similiar robots & humanoid images as those found in Berzerk and Frenzy, but espire8 sent me some multi-color sprite samples that have me reconsidering:
One thing I was planning to do was to HMOVE the Missiles and Ball on every line so I could draw them diagonally for diagonal shots. I haven't looked at timing yet, but multicolored sprites and digital sample playback probably
I changed all the wall and door routines to use the new DrawLine function. I also updated the Frenzy routines to do the full maze instead of just 1 1/2 columns. At that point the ARM code had shrunk from 3180 to 2508 bytes. Nice savings and cleaner code.
I then added difficulty switch settings that will eventually be replaced by menu options:
Left Difficulty
Flicker Reflective walls
Animate Reflective walls
Right Difficulty
Frenzy maze la
Partial test of the new wall routines for the Frenzy gameplay variation. The Frenzy maze starts with 15 posts in the middle of the room instead of 8, and the walls can either be shot-out brick-by-brick, or they can reflect the shots flying around the screen. I'll eventually have a menu option where you select which variation to play, at the moment it's hard coded for Frenzy.
While working on the 2nd column, I decided I needed to revamp how I am drawing the walls - so this is what was
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord