Medieval Mayhem - 2600

+SpiceWare · October 23, 2006

That's an idea - though I'm not sure how well that would work using a paddle. If I used "paddle's towards top/bottom then scroll" then there's a really good chance that the attract mode would never engage because the menu was spinning.

cd-w · October 23, 2006

That's an idea - though I'm not sure how well that would work using a paddle. If I used "paddle's towards top/bottom then scroll" then there's a really good chance that the attract mode would never engage because the menu was spinning.

Good point - probably best just to leave it as it is, since it works fine anyway.

Chris

r_type2600 · October 23, 2006

Maybe - but it's a pain to reorg the menu.

Hmm...dare I suggest strimming it down - visually?

The gothic font looks great and fits the game mood perfectly, but IMO it's too much of the good too also use it for the options text.

I hope I don't commit a sacrilege here, realizing how much hard work and love you must have put in creating this elaborate font.

But I believe using some simpler (though yet nice, something along the lines of the ones used for Four-play or Lady Bug, for instance) option text would have a couple of desirable effects:

- the smaller font would allow to fit all options on one screen

- the title logo, now being alone in using the gothic font, would get the visual presence it deserves. No need to flash it anymore to distinguish it from the rest of the text

...

Superb work on the game - exciting to see how this has evolved into another arcade-quality homebrew masterpiece :thumbsup:

Eric

Shawn · October 24, 2006

Any chance of using all crowns instead of those sheilds? They look pretty out of place. Aside form that the game looks perfect.

+SpiceWare · October 24, 2006

Hmm...dare I suggest strimming it down - visually?

The gothic font looks great and fits the game mood perfectly, but IMO it's too much of the good too also use it for the options text.

I hope I don't commit a sacrilege here, realizing how much hard work and love you must have put in creating this elaborate font.

But I believe using some simpler (though yet nice, something along the lines of the ones used for Four-play or Lady Bug, for instance) option text would have a couple of desirable effects:

- the smaller font would allow to fit all options on one screen

- the title logo, now being alone in using the gothic font, would get the visual presence it deserves. No need to flash it anymore to distinguish it from the rest of the text

...

Superb work on the game - exciting to see how this has evolved into another arcade-quality homebrew masterpiece

Eric

No problem with the suggestion; but, I'm running out of time in order to have it available for Xmas. The final dragon animation and other planned enhancements take priority over revamping the main menu.

Thanks

+SpiceWare · October 24, 2006

Any chance of using all crowns instead of those sheilds? They look pretty out of place. Aside form that the game looks perfect.

It originally was all crowns (Post #107) until supercat brought up the fact that it made the game unfair for the lower players in Post #109. The lower "shields" are actually batttle helmets, selected from espire8's designs in Post #113.

Thanks!

Jacob Rose · October 24, 2006

Any chance of using all crowns instead of those sheilds? They look pretty out of place. Aside form that the game looks perfect.

Those aren't shields - they're helmets! There's also a good reason to have a different shape at the bottom. Unless I'm mistaken (and I might very well be...), Spice is using hardware collision detection, so the shape of the bottom kings should generally *mirror* that of the top kings, to keep things fair. If they were wider on the side facing the enemies than the enemies were on the side facing them, it would be an advantage to their enemies. Maybe not much of one, but still...

Jacob Rose · October 24, 2006

No problem with the suggestion; but, I'm running out of time in order to have it available for Xmas. The final dragon animation and other planned enhancements take priority over revamping the main menu.

That's not the final dragon animation!?! Wow.

+SpiceWare · October 24, 2006

That's not the final dragon animation!?! Wow.

Missed post 123?

espire8 · October 24, 2006

No problem with the suggestion; but, I'm running out of time in order to have it available for Xmas. The final dragon animation and other planned enhancements take priority over revamping the main menu.

That's not the final dragon animation!?! Wow.

Actually, the current dragon animation of 3 frames was my alternate version of Nathan Strum's original 'test dragon' from earlier but because of an overloaded "to do" list, I was offered to finish the assignment which will be at 27 frames! and I'm happy to report, is almost complete!

Edited October 24, 2006 by espire8

Jacob Rose · October 24, 2006

Actually, the current dragon animation of 3 frames was my alternate version of Nathan Strum's original 'test dragon' from earlier but because of an overloaded "to do" list, I was offered to finish the assignment which will be at 27 frames! and I'm happy to report, is almost complete!

Wow! Got any test animations?

Missed post 123?

Yes, yes I did.

Edited October 24, 2006 by Jacob Rose

espire8 · October 24, 2006

Actually, the current dragon animation of 3 frames was my alternate version of Nathan Strum's original 'test dragon' from earlier but because of an overloaded "to do" list, I was offered to finish the assignment which will be at 27 frames! and I'm happy to report, is almost complete!

Wow! Got any test animations?

Yes. I'm doing the test on a flash based program. I will post it in this trend when it's completed for reveiws and comments soon.

espire8 · October 29, 2006

Okay everybody, Here's the link to the 27 frame 'Dragon anime', This is my inital test so I can't say this is the final version yet, enjoy. :cool:

supercat · October 29, 2006

Okay everybody, Here's the link to the 27 frame 'Dragon anime', This is my inital test so I can't say this is the final version yet, enjoy.

How'd you get all those colors on the 2600?

espire8 · October 29, 2006

Okay everybody, Here's the link to the 27 frame 'Dragon anime', This is my inital test so I can't say this is the final version yet, enjoy.

How'd you get all those colors on the 2600?

It was really Spiceware's handywork. Personally, I know nothing next to what he can do! designing the graphic's sprites artwise is about all I can manage but here's a comment I posted on the same topic.

SeaGtGruff · October 29, 2006

Okay everybody, Here's the link to the 27 frame 'Dragon anime', This is my inital test so I can't say this is the final version yet, enjoy.

That is extremely cool! :thumbsup:

How'd you get all those colors on the 2600?

It looked like some of the subtle color shade differences may have been due to whatever method was used to capture the image?

If the dragon is always in the middle of the screen, with no other objects on those scan lines, there can be 4 colors-- background, playfield/ball, player0/missile0, and player1/missile1. I'm guessing the two players (and maybe the missiles, too) are definitely being used, and possibly the ball?

Using flicker, the four solid colors can be combined to get additional colors, which could yield subtle color shadings, such as:

COLUBK = black

COLUPF = brown

COLUP0 = red

COLUP1 = yellow

COLUBK flickered with COLUPF = dark brown

COLUBK flickered with COLUP0 = dark red

COLUBK flickered with COLUP1 = dark yellow

COLUPF flickered with COLUP0 = reddish-brown

COLUPF flickered with COLUP1 = yellowish-brown

COLUP0 flickered with COLUP1 = orange

Shoot, you could even get 4 colors on a single player scan line using just 1 player, if you flicker the COLUBK and COLUP0 colors, such as:

odd frame = a

even frame = b

COLUBK(a) = dark yellow

COLUBK(b) = dark red

COLUP0(a) = light red

COLUP0(b) = light yellow

COLUBK(a) flickered with COLUBK(b) = dark yellow + dark red = dark orange

COLUBK(a) flickered with COLUP0(b) = dark yellow + light yellow = medium yellow

COLUP0(a) flickered with COLUBK(b) = light red + dark red = medium red

COLUP0(a) flickered with COLUP0(b) = light red + light yellow = light orange

MR

  rem * multicolor player test
  player0x = 78
  player0y = 60
loop
  NUSIZ0 = %00000111
  COLUBK = $10 : rem * dark yellow
  COLUP0 = $4E : rem * light red
  player0:
  %00001111
  %00001111
  %00001111
  %00001111
  %00001111
  %00001111
  %00001111
  %00001111
  %00111100
  %00111100
  %00111100
  %00111100
  %00111100
  %00111100
  %00111100
  %00111100
  %11110000
  %11110000
  %11110000
  %11110000
  %11110000
  %11110000
  %11110000
  %11110000
  %11000011
  %11000011
  %11000011
  %11000011
  %11000011
  %11000011
  %11000011
  %11000011
end
  drawscreen
  NUSIZ0 = %00000111
  COLUBK = $40 : rem * dark red
  COLUP0 = $1E : rem * light yellow
  player0:
  %00110011
  %00110011
  %00110011
  %00110011
  %00110011
  %00110011
  %00110011
  %00110011
  %11001100
  %11001100
  %11001100
  %11001100
  %11001100
  %11001100
  %11001100
  %11001100
  %00110011
  %00110011
  %00110011
  %00110011
  %00110011
  %00110011
  %00110011
  %00110011
  %11001100
  %11001100
  %11001100
  %11001100
  %11001100
  %11001100
  %11001100
  %11001100
end
  drawscreen
  goto loop

multicolor_player_test.bas.bin

espire8 · October 29, 2006

Okay everybody, Here's the link to the 27 frame 'Dragon anime', This is my inital test so I can't say this is the final version yet, enjoy.

That is extremely cool!

It looked like some of the subtle color shade differences may have been due to whatever method was used to capture the image?

Thanks. The flash program's file compression did cause those subtle shades you see. The dragon image, two sprites of one color each overlapping the other, are suppose to be just red and yellow.

If the dragon is always in the middle of the screen, with no other objects on those scan lines, there can be 4 colors-- background, playfield/ball, player0/missile0, and player1/missile1. I'm guessing the two players (and maybe the missiles, too) are definitely being used, and possibly the ball?

Wow! ...I don't know if that's possible for this game (that's up to Darrell) but that's very intreresting! ...and useful to know for future homebrew projects!

Jacob Rose · October 29, 2006

Okay everybody, Here's the link to the 27 frame 'Dragon anime', This is my inital test so I can't say this is the final version yet, enjoy.

Looks really good! I guess I'd have to see it in motion (travelling across the screen) to understand how the various swoops from the front view would work.

+SpiceWare · October 29, 2006

The color effect is minimized if the dragon is viewed smaller than full-screen:

http://www.spiceware.org/dragontest.html

That's a clever idea SeaGtGruff. Not going to happen this late in the game(not enough ROM left for doubling up the graphics for each color set) ; but, could be useful for somebody else's project.

Edited October 29, 2006 by SpiceWare

SeaGtGruff · October 29, 2006

If the dragon is always in the middle of the screen, with no other objects on those scan lines, there can be 4 colors-- background, playfield/ball, player0/missile0, and player1/missile1. I'm guessing the two players (and maybe the missiles, too) are definitely being used, and possibly the ball?

Wow! ...I don't know if that's possible for this game (that's up to Darrell) but that's very intreresting! ...and useful to know for future homebrew projects!

Adding the ball could give you a third color (red for one player, yellow for the other player, and some other color-- brown?-- for the ball). And adding the missiles could let you use the yellow and red colors beyond the 8-pixel boundaries of the two players.

Adding 30 Hz flicker (with or without the ball) would give you even more colors, as I described, but it would also require keeping track of the frames (although in this case I prefer to call them "fields," since it takes 2 of them blended together to form 1 "complete frame," although technically they're frames not fields). That would require 1 byte of RAM, which might not be available, since I know there's already a ton of cool programming stuff squeezed into this game! And you have to update the field counter every field, so that requires a little bit of extra processing time during the vertical blank routines (see below). And then you need to use more ROM, both for the sprite(s) and for loading the data (see below), since you need to have one pixel pattern for one field, and another pixel pattern for the other field. And loading the graphics data takes a little bit longer, too.

The way I do it is as follows:

 ; somewhere in the vertical blank
  LDX field
  DEX
  BEQ update_field
  LDX #1
update_field
  STX field

Assuming the field variable is initialized as 0, this causes it to alternate between 0 and 1 from one field to the next. Then, to load the display data for a given field, I do something like the following:

 ; technique 1
 ; somewhere in the active region
  LDX field
  LDA data,X
  STA GRP0
 ; etc.
data
  BYTE %11001100; field 0 data
  BYTE %11110000; field 1 data

That means the graphics data must be arranged in an inconvenient manner, since the field 0 data and field 1 data must be interleaved, so I don't actually store and load the graphics data that way. Instead, what I'm doing in my current project is more like (but not exactly like) the following:

 ; technique 2
p0_pointer = $80
p0_pointer_lo = $80
p0_pointer_hi = $81
 ; etc.
 ; somewhere in the vertical blank, after the field counter has been updated
  LDX field
  LDA p0_pointer_lo_data,X
  STA p0_pointer_lo
  LDA p0_pointer_hi_data,X
  STA p0_pointer_hi
 ; etc.
 ; somewhere in the active region
  LDY p0_height
draw_player0
  LDA (p0_pointer),Y
  STA GRP0
  STA WSYNC
  DEY
  BNE draw_player0
 ; etc.
p0_data_field0
  BYTE %00000000
  BYTE %11001100
  BYTE %11001100
  BYTE %11001100
  BYTE %11001100
p0_data_field1
  BYTE %00000000
  BYTE %11110000
  BYTE %11110000
  BYTE %11110000
  BYTE %11110000
p0_pointer_lo_data
  BYTE #<p0_data_field0
  BYTE #<p0_data_field1
p0_pointer_hi_data
  BYTE #>p0_data_field0
  BYTE #>p0_data_field1

My current project displays many (many, many) pages of text, and it uses 30 Hz (or 25 Hz PAL) flicker to get 12 players on a line-- 6 on one field, and 6 on the other field, as in my Sudoku WIP-- plus the characters are only 4 pixels wide, so there's room for 24 characters in each row of text. The field counter is used to get the horizontal movement values of the players and missiles for the two fields, as in the technique 1 example, then some of the graphics data is loaded as in the technique 2 example. However, I'm using ASCII text, with the character shapes defined in two ROM tables-- one for the left half of a player, and another for the right half of the player-- so I'm not actually loading the character data that way. Instead, the text for each screen is split into two parts-- one for the characters that will be on field 0, and the other for the characters that will be on field 1-- and I use the field counter to get/set the text pointer to the appropriate text data address, as in the technique 2 example. And since I have to load the left and right character data separately, and then combine them, for each player shape, there simply isn't enough time on a scan line for that, so I preload the data for the last 6 characters and store them in RAM between each row of text, and then to display the text row I load and combine the data for the first 6 characters (or first 3 players), and read the preloaded data for the last 6 characters (or last 3 players). This gives me characters that are 8 scan lines tall, with 8 blank scan lines between each row of text. And even if the result might not look very exciting to some people (since after all it's just a whole bunch of text screens), I'm very proud of the achievement, because I'm having to use some neat tricks to accomplish it. For example, the text data is stored in several different 4K banks (the final ROM will be 32K, using the F4 bankswitching method, with *no* extra RAM), so I load the text data for a given field and row using a modifiable subroutine that's stored in zero-page RAM, with the bank number and text pointer located within the subroutine. And I'm using four "special characters" to help compress the text data-- HT or horizontal tab (which is equivalent to 2 consecutive spaces), LF or line feed (to indicate that the remainder of a text line is all spaces), VT or vertical tab (which is equivalent to 2 consecutive line feeds, for double-spaced lines), and FF or form feed (to indicate that the remainder of a text page is all line feeds). Also, I had to write a short text-processing program in FreeBASIC to read in a text file (formatted 24 characters per line), chop it up into two strings (one for field 0, and the other for field 1), convert the resulting strings to use the HT, LF, VT, and FF characters where appropriate, then write the resulting strings to two files which are then added into the Atari 2600 program using INCBIN. It's been a real bear to program, which is one of the reasons I'm so proud of it (the more difficult something is to do, the more satisfying it is for us to accomplish, even if it might be a piece of cake for someone with more knowledge, experience, or ingenuity). And part of the reason why it's been so challenging is because it uses *no* extra RAM, and *no* extra hardware like the Chimera data queues (I *think* that will involve extra hardware?), just zero-page RAM and F4 bankswitching. I still have a ways to go with it, but I expect to meet a December 1st completion date.

MR

supercat · October 29, 2006

Adding 30 Hz flicker (with or without the ball) would give you even more colors, as I described, but it would also require keeping track of the frames

I don't think that would be a particular problem, since one could share a bit with the shape-selector byte. One thing which can help when using flicker for colors is to alternate scan lines between the two colors (indeed, one can alternate scan line colors even without flicker). This can greatly reduce apparent flicker, though at some expense in CPU cycles. Of course, if the dragon is launching fireballs there may not be any cycles to spare.

SeaGtGruff · October 29, 2006

Adding 30 Hz flicker (with or without the ball) would give you even more colors, as I described, but it would also require keeping track of the frames

I don't think that would be a particular problem, since one could share a bit with the shape-selector byte.

In my current project, I use a whole byte for the field counter, to avoid having to mask the byte before decrementing it or using it as an index:

field = $80
something_else = $80
; etc.
; somewhere in the vertical blank routines
; is there a more efficient way to do this?
  LDA field
  AND #%00000001
  TAX
  DEX
  BEQ update_field
  LDX #%00000001
update_field
  LDA field
  AND #%11111110
  STA field
  TXA
  ORA field
  STA field
; etc.
; somewhere in the active region
  LDA field
  AND #%00000001
  TAX
  LDA data,X
  STA wherever

But it depends on which is more precious-- RAM space or machine cycles. In my case, since I have zero-page RAM space available, and I want to minimize machine cycle time as much as possible, it's more useful to use a whole byte for the field counter than to share a byte with another variable.

One thing which can help when using flicker for colors is to alternate scan lines between the two colors (indeed, one can alternate scan line colors even without flicker). This can greatly reduce apparent flicker, though at some expense in CPU cycles.

That's a good point. Here's a demo I did a while back to display a 240-color palette, by flickering between different luminances on alternating scan lines:

http://www.atariage.com/forums/index.php?a...st&id=38693

Dithering helps, too. For expanding a 6-player score display into a 12-player display, that of course translates as flickering Venetian blinds, which may or may not be feasible depending on the timing constraints for each scan line. For normal players, dithering can be used for color areas wider and/or taller than a single pixel. For the missiles and ball, that would mean alternating between enabled and disabled bits from scan line to scan line. And for the playfield, dithering can be used, but of course the pixels are bigger! There was a demo posted a while back (by Thomas?) that used flickering to get a 4-color playfield, but I don't have a link for it, and it might have been on the Stella list. :ponder:

Of course, if the dragon is launching fireballs there may not be any cycles to spare.

I gather there are no ROM bytes or machine cycles to spare, but the dragon is fabulous work exactly as is-- as is the rest of the game. :thumbsup: This will be a great game to buy for Christmas! With all of the fantastic homebrews that are being released in recent years, it's like being a kid again, getting excited about buying new Atari games. :lust: We don't need no stinking Viagra, we got homebrews! :lol: This is truly the Age of the Atari Renaissance.

MR

+Nathan Strum · October 30, 2006

Okay everybody, Here's the link to the 27 frame 'Dragon anime', This is my inital test so I can't say this is the final version yet, enjoy.

That's fantastic! Much better than I would have been able to do. Nice work! :thumbsup:

+SpiceWare · October 30, 2006

Title Screen/Attract Mode Music, Druid Chip by moderntimes99.
Easter Egg(works, but is not finished)
Minor fix to prevent captured fireballs from wrapping around the screen

mm20061029NTSC.bin

mm20061029PAL.bin

Albert · October 30, 2006

Okay everybody, Here's the link to the 27 frame 'Dragon anime', This is my inital test so I can't say this is the final version yet, enjoy.

Wow, that looks fantastic!! Is this going to be used in the game?

..Al

Medieval Mayhem - 2600

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members