Jump to content
  • entries
    658
  • comments
    2,707
  • views
    906,727

Announcing Draconian


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 their size and do the left/right shifting for supercat's station suggestion. I expressed the desire to have something to post today, which is the eight year anniversary of that blog post.

 

After that I decided Nathan's original idea of using the playfield would look better (less flicker) so it would make sense to use Frantic's routines instead. One problem I had was Bosconian can have a lot of shots flying around and Frantic's routines were limited to just 6 shots. So I started to revise it to support missile repositioning. Ended up having to drop the ball object to make that work but I was able to figure out how to reuse the missile objects. Tricky part was keeping the size changes of the missiles and players in sync (as each player/missile pair uses a single register to control their sizes). The solution was to only worry about the player size when repositioning the player, and likewise for the missile size and its repositioning. After all the objects have been repositioned, then run a "clean up" routine that fixes all the size changes. If you care to look in the code, available below, check out function FixSizes().

 

I then had second thoughts about using the playfield due to the shear amount of data that would be moving around due to the desire to use single line resolution for the station detail:

blogentry-3056-0-86415900-1396013064_thumb.gif

 

So I decided to drop the playfield and add back the ball object. That's when I figured out that Slick Kernel that can reposition an object on every scanline. Since I could reuse the objects so frequently, I decided to update COLUPF when repositiong the ball instead of CTRPPF. This means the ball is a fixed size, but each instance of the ball can be a unique color.

 

One thing not really worked out was the radar display. Nathan's mockup included the ingenious idea of using an indicator on the edges of the display:

26_bosco_3.gif

 

But recently Ed Fries posted Rally X were he'd worked out a rather slick radar implementation that shows the flags, cars and player position all in different colors without any flicker.

blogentry-3056-0-78864500-1396011341_thumb.png

 

I thought that would work well for Bosconian. Since the radar uses both players, the normal 6-digit score routine can't be used in the same screen section as the radar. Since the radar would look odd all by itself, I decided to go old-school and use the playfield to display the score and lives information.

 

After a couple weeks of late night coding sessions, we have something to show. It's not yet a playable game, though you can fly around the sector (or quadrant, we haven't decided ;)).

 

Start of the menu

blogentry-3056-0-03877000-1396012474_thumb.png

 

Game screen. I'm rather pleased with how the starfield turned out. The arrangement and color is randomly generated at the start of each round. Each star maintains its color, even as they move in the background.

blogentry-3056-0-63219300-1396012459_thumb.png

 

Diagnostic display showing processing time remaining for Vertical Blank and Overscan:

blogentry-3056-0-39117100-1396012521_thumb.png

 

The divider line and corners of radar are used for the "Condition Color". Above you can see Green and Yellow - it can also be Red:

blogentry-3056-0-93011300-1396012577_thumb.png

 

An early build displayed the condition using a colored character:

blogentry-3056-0-16862600-1396014967_thumb.png

Controls:

  • Left Difficulty - A= Diagnostic (time remaining in Vertical Blank and OverScan)
  • Left Difficulty - B = score display (currently just counts up and shows in hex to test the digits)
  • Right Difficulty - A = freeze ship (useful for looking at station damage)
  • Right Difficulty - B = ship moves
  • SELECT = return to menu
  • START = start game
  • Joystick = move around in sector/quadrant
  • Fire = shoot (collision detection is not yet in place)

Please remember this is very early build. You'll see issues such as flight angles(I'm look at you 45° ;)) that are not compensating for the non-square pixels as well as occasional jitter. Using the diagnostic display I can tell that Vertical Blank is overrunning when there's a lot of objects onscreen (see level 6), and Over Scan is sometimes overrunning when you start a new level. I believe that's due to the level init routines that prevent the randomly placed asteroids and mines from overlapping each other or the stations.

 

If you're checking this out with Stella, be sure to turn on phosphor mode!

  • open Draconian in Stella
  • hit TAB for the in-game-menu
  • select Game Properties
  • Select the Display tab
  • change Use Phosphor to Yes
  • click OK
  • select Exit Menu
  • Reload the ROM (Control-R)

ROM

draconian_20140328.bin

 

Source

Draconian_20140328.zip

  • Like 10

26 Comments


Recommended Comments



It's been a real blast seeing Darrell working on this for the last couple of weeks. I really never expected anything to come out of that blog post (hence the category "Stupid Game Ideas"), so it's pretty amazing seeing this starting to come to life. Bosconian was always one of my favorite arcade games, so it's nice to see it getting some homebrew lovin'.

 

Guess I should post some more Stupid Game Ideas. You just never know… :ponder:

 

Incidentally, the reason we went with the name Draconian is because of Darrell's tradition of using new names for his ports of arcade games (Medieval Mayhem, Frantic). Draconian, incidentally, means "excessively harsh or severe". But I'm sure he'll add selectable difficulty levels. ;)

I bet Sinistar would work well with it.

 

I forgot to mention how many objects this is currently keeping track of:

  • 150 sprites
  • 20 missiles
  • 128 stars

The program flow works like this:

  • OverScan - process game logic
  • Vertical Blank - prep all the datastreams to show the current frame
  • Display Kernel - shows the current frame

Most of those 150 sprites, 128 of them, are the stationary asteroids and mines. Only the player's ship can collide with them, so there won't be much overhead in OverScan.

 

The large number of sprites and missiles do impact Vertical Blank as those routines have to figure out which objects are in the visible portion of the screen so it can attempt to display them.


Most of those 150 sprites, 128 of them, are the stationary asteroids and mines. Only the player's ship can collide with them, so there won't be much overhead in OverScan.
Actually, the enemy ships can collide with the stationary objects.
However, the stationary objects are positioned in such a way that the collision detection routines only need to look at 8 of the 128 stationary objects. The sector is divided up into 32 horizontal bands. 4 stationary objects are randomly positioned (X and Y offset) within each band. Since the player or enemy can only straddle 2 bands at once, then only the 8 stationary objects within those bands needs to be compared with for collision processing.

 

Draconian, incidentally, means "excessively harsh or severe".

If anyone here has ever read some of the Dragonlance novels then they will have heard of 'Draconian' before. In the novels Draconians were a race created by the kidnapping of the good dragons eggs and twisting them with black magic as they hatched. This resulted in a humanoid type creature. They served as assualt soldiers for the evil army.

The wiki entry for Bosconian lists

Throughout the game, a digitized voice alerts the player to various events:

  • "Blast off!" (start of a round)
  • "Alert! Alert!" (enemies approaching)
  • "Battle stations!" (formation attack)
  • "Spy ship sighted!" (self-explanatory)
  • "Condition red!" (enemy attacks become more aggressive; occurs when the player takes too long to clear a round, or misses the spy ship)

The game's from 1981. It was still uncommon for games to use Digitized Speech back then due to the expense, Synthesized Speech was more common.

Nathan's not yet done his magic with the digit graphics. It's possible what he comes up with will be smaller than my test graphics, which are purposely large so as to establish the size of the area we have to work with.

 

The original score/radar area, the last screenshot above with the green G, was even more overwhelming :)

 

 

My test graphics for 5:

PFdigit5:
        .byte zz_____XXX ; 0
        .byte zz_____XXX ; 1
        .byte zz_____XXX ; 2
        .byte zz_____X__ ; 4
        .byte zz_____X__ ; 5
        .byte zz_____X__ ; 6
        .byte zz_____XXX ; 7
        .byte zz_____XXX ; 8
        .byte zz_____XXX ; 9
        .byte zz_______X ; 10
        .byte zz_______X ; 12
        .byte zz_______X ; 13
        .byte zz_____XXX ; 14
        .byte zz_____XXX ; 15
        .byte zz_____XXX ; 16   
Alternating those scan lines would be this, which doesn't look quite right to me.

PFdigit5:
        .byte zz_____XXX ; 0
        .byte zz________ ; 1
        .byte zz_____XXX ; 2
        .byte zz________ ; 4
        .byte zz_____X__ ; 5
        .byte zz________ ; 6
        .byte zz_____XXX ; 7
        .byte zz________ ; 8
        .byte zz_____XXX ; 9
        .byte zz________ ; 10
        .byte zz_______X ; 12
        .byte zz________ ; 13
        .byte zz_____XXX ; 14
        .byte zz________ ; 15
        .byte zz_____XXX ; 16   
A shorter 5, which would be less bright:

PFdigit5:
        .byte zz_____XXX ; 0
        .byte zz_____XXX ; 2
        .byte zz_____X__ ; 4
        .byte zz_____X__ ; 6
        .byte zz_____XXX ; 7
        .byte zz_____XXX ; 9
        .byte zz_______X ; 10
        .byte zz_______X ; 13
        .byte zz_____XXX ; 14
        .byte zz_____XXX ; 16   

An alternating short 5 would be

PFdigit5:
        .byte zz_____XXX ; 0
        .byte zz________ ; 2
        .byte zz_____X__ ; 4
        .byte zz________ ; 6
        .byte zz_____XXX ; 7
        .byte zz________ ; 9
        .byte zz_______X ; 10
        .byte zz________ ; 13
        .byte zz_____XXX ; 14

Hi,i downloaded both the draconian rom and the linux container pack with multiple roms of draconian,i tried all versions of that rom on my wooden stylish atari handheld trough it’s SD card input,i replaced those batteries as well because i do know that if that handheld will running low on power,then it wouldn’t load any game after going trough the menu,but even after replacing those batteries with fresh new ones and tested it out to see if it could load all other games,then i decided to test it out with draconian,BUT all i get is a prompt sound and a nlack screen wich is very frustrating,because eventrough it’s only 32KB in size,i do know my wooden style atari handheld does support 64KB of rom,so i do wonder what’s the issue here,is it indeed because of a new type of bankswitching wich mine atari handheld doesn’t support???

also i haven’t tried it yet on my harmony card but all i do know my harmony cart only supports 32KB roms at maximum,but i don’t know if it does support yet that new type of bankswitching,in fact i don’t know if it does have the newest firmware to support such new type of bankswitching,mmmm,

thanks for helping me out anyway🤣

 

Draconian final ROM is in this blog post.

 

By this:

 

22 hours ago, johannesmutlu said:

wooden stylish atari handheld

 

I assume you mean the Flashback Portable? Draconian uses an ARM in the cartridge as a coprocessor, I don't think the Flashback supports that.

 

 

The Harmony Cart has an ARM processor in it and supports running Draconian on a real Atari.  To see what version of the firmware you have hit FIRE on the line at the top with [.] 

image.thumb.jpeg.f7f6f275c3b9bd7c51b287f500e51208.jpeg

 

that'll take you to a credits screen which displays the firmware version at the top.  Mine is running v1.06:

 

image.thumb.jpeg.64c0c88bbf5b7b0bfc66b17563793026.jpeg

 

You need to have at least v1.05 for Draconian to work.  If your Harmony is lower then go here for the latest firmware and instructions.

  • Like 1

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...