While getting ROMs together for Nathan for his RetroN 77 contribution to the Stella-thon 12 Hour Gaming Marathon Fundraiser! event I realized I've yet to publish the final ROM for Draconian.
NOTE: newer versions of the Harmony Cartridge use a different chip that does not work with the above ROM. batari posted this patched version of the final ROM in this topic where he explains why the patch was needed:
Station and station pod explosion sequences using placeholder images I whipped up as Nathan's been busy Station explosions are not deadly to the player's ship.
One issue with the station graphics is the gaps in the image which are used to create a shadow effect. They look great, but play havoc with collision testing. I built a test version, available below, that lets you move a horizontal shot around with the right joystick. It denotes a collision by changing the score to 888888:
If the shot ends up in a shadow there's nothing to collide with, so the score shows 0:
Collision tests are done row-by-row, so I got to thi
Added a new function, CollisionQuad(), that lets me test for collisions with the stations. So far only the shot routines have been updated to use this function. What this means is you can no longer take out all 6 station pods while remaining on a single side! You can still fly through a station without getting killed - though odds are that a station shot will take you out.
I made these changes while walking on my new TreadMill Desk. So far I have my MacBook Pro and a secondary monito
Your mission, blow up the enemy stations. To do so you'll need to destroy all 6 pods or, if visible, hit the energy field to trigger a self destruct. After destroying all stations you'll be taken to the next sector.
No station related explosions yet. Shots are also not yet absorbed by station infrastructure, which means you can currently shoot out all the pods while remaining on a single side of the station. Both will be addressed in a future update.
To get this to work I
ARM routine InitLevel() is now run mid-screen to eliminate problem where OverScan occasionally ran out of time
screen shifted down to give more time to Vertical Blank
player shots are faster
station shots are slower, and once again deadly
asteroid explosions are no longer deadly. They're also faster than mine explosions. Non-Deadly explosions are now drawn in white.
Have not seen any jitter since making these changes. Let me know if you encounter any as I may nee
I took a look at the energy field routines while eating lunch, so here's a new build in just 2 days rather that a few weeks
each station type (Horizontal and Vertical) has its own Energy Field design (2 flickered shapes for each design)
last Energy Field flickered shape kept track for each station, so Energy Field will always alternate between its 2 shapes regardless of Station flicker rate.
Added X-Y check to make sure energy field is onscreen before drawing it. This appears
Test of preliminary routines that open the center pod and show the "energy field" that can be hit to destroy the station in one shot.
The energy field is drawn using a missile. If the station is drawn with player0, the energy field is drawn with missile1. Likewise missile0 is used for stations drawn with player1. I did this as we can't control the color of the missiles, so this gives us a chance for the energy field to be a color other than green.
preliminary explosion sequence
asteroids, mines and enemy ships are deadly to touch
station shots are deadly
Player Lost a Life routine
added a buffer space around the ships spawn point so asteroids/mines aren't placed next, or even on, the ship.
Collision routines don't support quad sized sprites yet, so flying thru a station won't kill you (their shots on the other hand...)
The new buffer space around the spawn point increased the odds of there bein
* but only asteroids and mines.
Collision handling's going to be a bit different for Draconian as it's not feasible to check against all 150 sprites. One handy thing I can take advantage of is how the asteroids and mines are positioned. The screen's divided into horizontal bands that are 32 pixels tall. 4 stationary objects (combination of asteroids and mines) can appear in each band, and they're positioned so they never straddle multiple bands. Sprites 22-25 are in the first band, 2
I migrated the color conversion routines from Timmy! so you can now select your TV Type of NTSC, PAL or SECAM from the menu. Because of the limited menu space, due to that snazzy logo up there, I did not copy over the RED/GREEN/BLUE menu entry - so use the green station in the logo to confirm your selection.
You can use Stella to try out the different TV-Types. Hit <CONTROL>-F to step between the different formats. Make sure to use modes PAL60 and SECAM60 instead of PAL and SEC
The inspiration came from Chris' Star Castle logo. There's a couple minor differences due to the extra processing time that using DPC+ provides.
The logo is centered instead of being slightly offset to the left.
Instead of using VLBANK, I'm using SCORE mode to change the playfield pixels from green to black to hide the right and left edges of the screen
I'm changing PF1 (in conjunction with SCORE) to hide an extra 8 pixels on the right that couldn't be masked with a missile.
A while back, Nathan posted some well thought out mockups detailing how to do Bosconian on the Atari 2600. There was a bit of discussion, including a suggestion by supercat for drawing the stations using players instead of the playfield. But nothing came of it - until today.
Two weeks ago I approached Nathan about possibly using the routines from Space Rocks to implement his ideas. Those routines seemed ideal as they support objects with unique colors as well as the ability to set th
With my prior DPC+ kernels, I used an Event Datastream that would tell the kernel to jump out of its normal loop. After that, the 6507 would spent a lot of CPU time deciding if it was supposed to reposition player 0, reposition player 1, or if it was all done drawing the game display.
I got to thinking and came up with a way were the 6507 no longer has to make any kernel decisions - instead of having an Event Datastream, just have a Jump Datastream. Every entry in the Jump Datastream