Porting the original classic Castlevania to the 2600

[eshu]

Been watching this thread for a while, and am impressed with your progress so far...

 

I figure that it's all about choosing the right color combinations that blend well on screen for minimal distortion. I wish there was a chart that displays most of the best 30Hz color combinations possible. That way many would know what works best and what doesn't.

 

I think you'll find that it's the "closest" colour combinations which blend well, so for instance colour $00 and $0F mixed will produce approximately the same colour as $06 mixed with $08 but the second combination will do so with less noticable flicker. Because the colours in NTSC are based on a colour wheel I think you can also quite easily measure the "closeness" of hues - the colours with the smallest differences in both hue and luminance will blend the best. I think the hues sort of rap around from $F to $1, so $E0 is about as "close" to $F0 as $10 is.

 

This isn't the issue that it use to be with older televisions. Newer units (LCD)can get rid of most noticable flicker and many newer tricks rely on heavy flicker to get more on screen than before anyway (4 colors instead of 2).

 

It's interesting to see how different peoples attitude to writing stuff for the 2600 is. Some people are only interested in things that could have been released back in the day, and others not. I've seen it a lot of times when people where talking about the Chimera project which never came about in the end, but I think the work formed the foundation for the Harmony/Melody cart, but this is the first time I've seen it with regards to tv sets!

 

I'm still playing around with stuff so I don't know if I'll ever get a complete game written - but I always want to write something from a "what if" point of view, like what if this game had been released before the crash, or what if it had been released while the NES was putting the final few nails in the 2600's coffin. So I wouldn't want to use an effect that wouldn't have worked so well back then. But I don't think my point of view is in any way better than yours, I just find it interesting how different people look at it.

[+Random Terrain]

Didn't at least some Atari 2600 programmers, starting in 1981 or 1982, use color monitors that had better picture quality than the TVs most people used? A video game on a monitor looked a lot better than it did on a TV. Nice and clear without any of the weird stuff a TV can do to video game graphics. Computer monitors and HD TVs finally allowed the rest of us to see a clearer picture. We're not cheating, we're just catching up.

[eshu]

Didn't at least some Atari 2600 programmers, starting in 1981 or 1982, use color monitors that had better picture quality than the TVs most people used? A video game on a monitor looked a lot better than it did on a TV. Nice and clear without any of the weird stuff a TV can do to video game graphics. Computer monitors and HD TVs finally allowed the rest of us to see a clearer picture. We're not cheating, we're just catching up.

 

Now, now - I'm certainly not accusing anyone of cheating . I think it's unlikely that many people where doing a video mod back in '81, but I guess it's not impossible.

 

The way a picture display's on a television isn't necessarily a hinderance, some developers used it to their advantage, I used to think the wheels on the cars in enduro where rubbish until a recent version of stella came out....

 

 

The article here: http://www.bogost.com/games/a_television_simulator.shtml seems to indicate that flicker is worse on modern televisions?

 

The only TV we have in our house is a big LCD screen which does some strange things to the VCS signal, I think it interprets it as interlaced or something but I get a very jagged picture so I don't use the real thing for development as much as I would like, at some point I think I will have to try and get an old CRT to use it with...

[+grafixbmp]

WOW. Does that ever take nostalgia to the extreme. One thing they failed to consider is these effects will range within certain tolerances between diffrent brand TVs and sizes from that era. Everyone more than likely saw a slightly diffrent picture depending on the TV used and how well the RF signal had been tuned in. Weather it was a Sony, RCA, Emerson, Panasonic, etc at 13", 15" 27" etc. Atari did the best they could with the equipment from that time. Now the quality of presentation is sharper, standardized and display settings give the user more control over how the picture looks with a modern set.

 

I sell TV's where I work and we have to know all the major high points of how they work. Even now there are slight diffrences between brands, but not as much as back then.

 

The 70's- 80's were nice and I like many things from there but I don't live there anymore.

 

Don't get me wrong. I like some of the visual effects being used but some of them are over kill and others couldn't hurt to be toned down a bit. THey should also have a setting for the size of screen being used so the effects can be properly scaled to fit the screen.

 

On a similar note, how many people do you hear that miss the blury, jerky, distorted images of VHS over DVD Video? I think I heard a pin drop.

Edited November 3, 2009 by grafixbmp

[jrok]

On a similar note, how many people do you hear that miss the blury, jerky, distorted images of VHS over DVD Video? I think I heard a pin drop.

 

I think you're missing the point somewhat. Programmers were, to some degree, exploiting the CRT's phosphor display to the benefit of their games, not trying to figure out a "way around it." The example of Enduro's sunrise and tires is a perfect example, although there are many others. Some of the effects were intentional, while others were likely happy accidents.

 

The analogy of 35mm film versus digital video is probably a better one. I know many movie buffs who prefer film precisely because of it's "imprecision", with it's chemical bleed helping to meld disparate frames and present a more dreamlike illusion of movement. You could make a pretty good argument that the CRT was an important component of the VCS as a medium.

 

Jarod.

[+thegoldenband]

The big thing I notice when playing on real hardware is the effect of NTSC artifacting, and how it can add texture to things that would otherwise be solid blocks of color. I've especially observed this in Intellivision games, many of which look a lot cooler on a real TV.

[+grafixbmp]

On a similar note, how many people do you hear that miss the blury, jerky, distorted images of VHS over DVD Video? I think I heard a pin drop.

 

I think you're missing the point somewhat. Programmers were, to some degree, exploiting the CRT's phosphor display to the benefit of their games, not trying to figure out a "way around it." The example of Enduro's sunrise and tires is a perfect example, although there are many others. Some of the effects were intentional, while others were likely happy accidents.

 

The analogy of 35mm film versus digital video is probably a better one. I know many movie buffs who prefer film precisely because of it's "imprecision", with it's chemical bleed helping to meld disparate frames and present a more dreamlike illusion of movement. You could make a pretty good argument that the CRT was an important component of the VCS as a medium.

 

Jarod.

When you said film vs digital, I couldn't help but remember this link.

http://gizmodo.com/5391504/terminator-salvations-director-of-photography-asks-can-you-tell-the-difference-between-film-and-digital

 

And as a bonus on a side note, I found this link too.

 

http://gizmodo.com/5393626/ataris-lunar-lander-made-real

 

I guess what I would perfer is something that helps the exploits with less TV look.

 

Leave the blockyness strong while slightly blurring the edges.

 

Remove the phosphor mask but add the same noise to the image that many DVD Videos have added to them.

Up play the exploits, down play everything else.

[jrok]

When you said film vs digital, I couldn't help but remember this link.

http://gizmodo.com/5391504/terminator-salvations-director-of-photography-asks-can-you-tell-the-difference-between-film-and-digital

 

And as a bonus on a side note, I found this link too.

 

http://gizmodo.com/5393626/ataris-lunar-lander-made-real

 

The funny thing is, the phenomenon the article describes is a form of emulation, which to my mind is pretty much the point of Stella development . It's not "nostalgia" so much as it is getting the game to mimic the presentation and logistics of the hardware it was originally designed for... which included the CRT .

 

I guess what I would perfer is something that helps the exploits with less TV look.

 

Leave the blockyness strong while slightly blurring the edges.

 

Remove the phosphor mask but add the same noise to the image that many DVD Videos have added to them.

Up play the exploits, down play everything else.

 

But you could do much of this stuff by simply screwing with your LCD settings. It sort of like when you mentioned the variance in phosphor sizes and retention. People forget that the human eye is an important component in this system. "What about emulating bigger sets?" Well, move closer to the screen

 

As for DVDs, that is a matter of compression that occurs during media translation, compressing hi res source frames to fit onto portable media. Its a practical concern, not an aesthetic one. Perhaps the more apt analogy is comparing a Gauguin still life to a Rembrandt. Rembrandt's style had sharper definition of line and form than Gauguin's.. does that mean his still lifes were superior?

 

Jarod.

Edited November 3, 2009 by jrok

[+grafixbmp]

 

 

As for DVDs, that is a matter of compression that occurs during media translation, compressing hi res source frames to fit onto portable media. Its a practical concern, not an aesthetic one. Perhaps the more apt analogy is comparing a Gauguin still life to a Rembrandt. Rembrandt's style had sharper definition of line and form than Gauguin's.. does that mean his still lifes were superior?

 

Jarod.

 

This is true of many DVD's, however when the source media being placed on DVD is lower quality or older animation, digital noise is added to cause the compression alogrythums to make the video take more space than they would otherwise. This allows the video to take up most of the DVD rather than very little, keeping the data rates high. A DVD disc has a minimum speed to run and the data has to meet or excede that. This instance is the digital noise I am refering to.

[tokumaru]

I think Stella's filters are a poor approximation of what the video from a 2600 actually looks like on a TV. These filters that just screw up the image in random ways are quite obsolete now that we have Blargg's NTSC Libraries, which faithfully simulate the artifacts of NTSC signals.

 

I'm so addicted to these filters that I can't seem to play the pixel-perfect crispy versions anymore. Hopefully the next version of Stella will have actual NTSC emulation.

[eshu]

I think this is getting a bit off-topic now (as in I don't think grafixbmp should be discussing the intricate details of TV simulation when he could be working on the Castlevania port which I'm hoping to one day play on my VCS) so I've started another thread here: http://www.atariage.com/forums/topic/153033-tv-simulation/

 

To grafixbmp, I just want to say again that I think the work you have done so far is very impressive. I think your point of view is just as valid as anyone else's and let's be honest most be people wouldn't think writing a game for a 30+ year old system is a normal thing to do anyway - you have to work towards your own vision, you'll never have the motivation otherwise. As much as other people can be impressed with your work, no-one else will feel the satisfaction you can get from seeing your game on the VCS.

[+stephena]

I think Stella's filters are a poor approximation of what the video from a 2600 actually looks like on a TV. These filters that just screw up the image in random ways are quite obsolete now that we have Blargg's NTSC Libraries, which faithfully simulate the artifacts of NTSC signals.

 

I'm so addicted to these filters that I can't seem to play the pixel-perfect crispy versions anymore. Hopefully the next version of Stella will have actual NTSC emulation.

I have an implementation of Blargg's filters for Stella already. It came from one of the Georgia Tech teams, a similar group to those that implemented the original OpenGL filters. Problem is, it isn't completely finished. And it also re-implements some of the current GL filtering code. I need to find time to go through it all and rework the whole thing. It's perhaps 2000-3000 lines of code (which isn't too bad), but finding time to do it hasn't happened so far. I want to get it done for the next release, but at this point the release won't be until late December.

[GroovyBee]

I don't want to tread on toes but I don't think full screen flicker is going to work on the real machine. I took your sample gif file, converted it into 7800 13 colour bitmaps (some colours were lost ) and made a little screen flipper :-

 

castlevania.a78

castlevania.bin

 

CC2 owners will need the following line :-

 

7800_48K 78BIOS

 

Its for NTSC 7800's only. The PAL palette isn't defined. Its not a game and its using MARIA.

 

On PAL and the 7800 ProSystem emulator it doesn't look good. It might give better results on a real NTSC machine.

[+grafixbmp]

I don't want to tread on toes but I don't think full screen flicker is going to work on the real machine. I took your sample gif file, converted it into 7800 13 colour bitmaps (some colours were lost ) and made a little screen flipper :-

 

castlevania.a78

castlevania.bin

 

CC2 owners will need the following line :-

 

7800_48K 78BIOS

 

Its for NTSC 7800's only. The PAL palette isn't defined. Its not a game and its using MARIA.

 

On PAL and the 7800 ProSystem emulator it doesn't look good. It might give better results on a real NTSC machine.

Even though I wasn't able to use a phosphor effect I think it may just work yet. What I need to do is get the new engine finished and see it anyone would like to stream line the code. Then I can test color combinations and find the best that is easiest on the eyes.

[GroovyBee]

Even though I wasn't able to use a phosphor effect I think it may just work yet. What I need to do is get the new engine finished and see it anyone would like to stream line the code. Then I can test color combinations and find the best that is easiest on the eyes.

 

Having seen the flickering effect in action I think it is so bad that I couldn't play the game (it really is that irritating). How about canvassing some more opinions from the people who downloaded the 7800 binaries?

[+Random Terrain]

Having seen the flickering effect in action I think it is so bad that I couldn't play the game (it really is that irritating). How about canvassing some more opinions from the people who downloaded the 7800 binaries?

Using the ProSystem emulator, the image is clear, but every 3 seconds, a line moves from the bottom to the top.

[GroovyBee]

Using the ProSystem emulator, the image is clear, but every 3 seconds, a line moves from the bottom to the top.

 

Thanks for the feedback but I think it needs running on a real machine. I've seen all sorts of visual glitches in ProSystem (probably graphics card related) that don't happen on the real hardware.

[+grafixbmp]

I just wish the Prosystem emulator had a phosphor effect as well like Stella. On a side note since I got the Prosystem emulator recently, I recalled a homebrew port of Super Mario Bros 3 being created for the 7800 once. Is that true and what would be the current state?

[+grafixbmp]

Well, it is a new year. I have taken a week and a half to reflect on this last year on this project and with so many drawbacks of diffrent methods to get this stuff looking good without things that would discourage many gamers, I now have another alternative solution that works for a kernel that does:

 

no flicker

alternate colors

reduced PF using reflective on

gets the players and missles on screen with P0 full res

allows for every other PF scanline to shift color mid scanline

 

Granted this is only a mock as usual but the only drawback is Fuzzy vision. But everything seems to appear ok and would be quite playable IMHO.

 

This damn kernel...

 

 

Would like some feedback on this alternative please.

Edited January 13, 2010 by grafixbmp

[+Random Terrain]

Looks pretty good, but I'm not sure how you are going to handle stairs. Will they be on both sides of the screen?

[+grafixbmp]

Looks pretty good, but I'm not sure how you are going to handle stairs. Will they be on both sides of the screen?

They can be depending on what is loaded to the screen and what the mask shows. I figured I would do another redesign of the level anyway given it is 32 pixels across I could break up the mask 8 by 17 for each screen and do it off that depending on where simon is located. The real kicker is designing the object display routines in the kernel to display the most at once for any given situation. and for the objects to have several modes of display.

 

One enemy object on screen taking up 16 colour clocks by flickering 8 colour clock horizontal shift each frame. Just back and fourth. Examples being final level bosses.

 

1 to 3 horizontaly placed objects using multiples at 16 scanlines tall and 32 scanlines tall. Generaly used for gouls.

 

Having the ability to break the data into separately loaded sections for the 32 scanline tall objects where the upper 16 is loaded separately from the lower 16. Used for nights and possibly skeletons.

 

note that all of these object senarios are double pixel height so 16 scanline would look like 8 pixels and 32 would look 16. They can also be displayed at double pixel width at one per horizontal line.

 

The 8 pixel or the 16 pixel objects can be displyed up to 3 objects with diffrent vertical positions with no overlap and at least 2 scalines between them.

 

and or 2 identical but independantly movable objects on the same horizontal row by using flicker as long as they aren't across the path of a candelabra or other object of either 8 pixel or 16 pixel objects. An example would be the frog men/ swamp monster with 2 independant ones on screen.

 

Not to exceed 3 enemy objects on screen at once. All enemies can be fliped.

 

For areas that have 2 types of enemies like black cats and gouls, the cata are rendered as a first wave, and when they leave the screen or are killed, the gouls will then come on to the screen as the second wave.

 

Candelabra are predefined in the kernel as an animation that are rendered as 6 rows and are just displayed or not anywhere on a horizontal position at any possible combination of 1 to 3 copies.

 

If any enemies cross the path of any candelabra, they will flicker where they need to beetween candelabra and enemy/objects.

 

As far as stairs goes, The mask will know where you need to be to walk up a set and which direction you are facing when you decide to press the stick up and to the right or left.

 

Oh and when any item for you appears of the screen, it looks like I may need to flicker that with simon/P0 and just use coordinates for collision. As a side note, only one item can appear on screen at a time, each new item from enemies or candles takes priority and only stays on screen for about 5 seconds or so.

 

There are other rules that don't necessarily apply to how the graphics are rendered like each screen can have a form of trigger that activates something. Trigger examples include enemy movements like a knight leaving the screen which brings a chest up or standing at a location for 2 seconds that can cause any treasure to rise. Also destroyable PF sections to reveal hidden objects.

 

Simon can use the current whip or mace as usual. Any ssecondary weapons generaly use the missle and will flicker the missle if the "II" is obained. Will try to allow the primary weapon to work in conjuction with the secondary weapons but this will just lessen the image of the primary weapon (whip/mace) as the missle will then be either single or double (flicker) displayed for the seconday weapon taking away from the primary weapons display detail when both are used.

 

Generaly missle1 is used as enemy fire.

 

I figured if only a few of these many attributes applied to each screen, the game program would function on a screen by screen basis rather well.

 

The only thing that slightly worries me is using 66 bytes of RAM to index the PF data for each screen. But if I still intend to use 32 K with superchip this shouldn't be a problem. If I have trouble I may recap and get the most bang for the buck and go with a Melody release. We shall see. I would prefer a superchip design thought.

 

And to keep everything concise, every movable object has its screen position modified every 2 frames. This is also the minimum frames and color palettes can be updated. I also thought about having a standard palette and doing special secondary pallette for each thing so that when things get flickered, they are displayed with a darker palette than normal.

 

PS sorry about the info overload.

Edited January 13, 2010 by grafixbmp

[+Propane13]

Well, it is a new year. I have taken a week and a half to reflect on this last year on this project and with so many drawbacks of diffrent methods to get this stuff looking good without things that would discourage many gamers, I now have another alternative solution that works for a kernel that does:

 

no flicker

alternate colors

reduced PF using reflective on

gets the players and missles on screen with P0 full res

allows for every other PF scanline to shift color mid scanline

 

Granted this is only a mock as usual but the only drawback is Fuzzy vision. But everything seems to appear ok and would be quite playable IMHO.

 

This damn kernel...

 

 

Would like some feedback on this alternative please.

 

I like it.

 

Are you going to retool the top status bars? I think they may have too many objects (so, hence, would need to be flickered).

In programming Mean Santa, I got my top and bottom graphics data done first, and working in a kernel, since 1) it's not as hard as the regular kernel, and 2) it lets you know how much space is left for the "fun stuff". Would you consider such an approach?

 

-John

[KevinMos3]

Would like some feedback on this alternative please.

Wow... just, wow. -- And did I say Wow?

 

Though, my opinion may not mean much since I can almost never find things to complain about in your work.

[+grafixbmp]

Well, it is a new year. I have taken a week and a half to reflect on this last year on this project and with so many drawbacks of diffrent methods to get this stuff looking good without things that would discourage many gamers, I now have another alternative solution that works for a kernel that does:

 

no flicker

alternate colors

reduced PF using reflective on

gets the players and missles on screen with P0 full res

allows for every other PF scanline to shift color mid scanline

 

Granted this is only a mock as usual but the only drawback is Fuzzy vision. But everything seems to appear ok and would be quite playable IMHO.

 

This damn kernel...

 

 

Would like some feedback on this alternative please.

 

I like it.

 

Are you going to retool the top status bars? I think they may have too many objects (so, hence, would need to be flickered).

In programming Mean Santa, I got my top and bottom graphics data done first, and working in a kernel, since 1) it's not as hard as the regular kernel, and 2) it lets you know how much space is left for the "fun stuff". Would you consider such an approach?

 

-John

 

I haven't been able to play it yet. Are there any screen shots or dare I ask, a ROM out there? I'm curious as to what your status layout looks like. But I wasn't sure what you meant by "I got my top and bottom graphics data done first, and working in a kernel" ?

 

Were you refering to 2 rows of info in your HUD sort of speak? Top and bottom? Or were you talking about something else? I figured it was this when you said not as hard as the regular kernel.

 

I guess you are asking If I would program the HUD kernel first and get it working before the game field area? Cause I think I like that thought. That way any screen RAM used for that could then be destroyed by the main kernel.

 

Oh and I'm sorry about the whole no flicker thing. I was centered on the game area having no flicker. I am sure I can design the run of the HUD with minimal distortion but in order to keep the original layout, the flicker would need to be there. However to be fair this is the atari and some things can be changed since the final boss doesn't show up till the end but the rest may be difucult. I prefer numbers for timers and the score is part of the game so...

Edited January 16, 2010 by grafixbmp

[+grafixbmp]

Would like some feedback on this alternative please.

Wow... just, wow. -- And did I say Wow?

 

Though, my opinion may not mean much since I can almost never find things to complain about in your work.

 

Thank you for that. I try to stay as close to the specs but even sometimes it gets way to hard to code such things. That is why I have tried to simplify the layout while still keeping a detailed playfield as much as possible. I have wanted to go back and finish the practice level of Marble Maddness an try to modify the design to run on real hardware if anyone could or would want to actualy make a game out of it. If that were ever the case, I would gladly do any other levels they could squeeze in.