Jump to content
IGNORED

Porting the original classic Castlevania to the 2600


grafixbmp

Recommended Posts

But that's someone else's project...

 

If you've followed this thread, you'd know that Castlevania probably has a year or more to go.

It's best to ask an original author to finish their own work. And yes, that can take significant time.

 

One thing to learn about the Atari community, is that it requires a LOT of patience. But, in the end, it's worth it. :)

 

-John

  • Like 1
Link to comment
Share on other sites

Been doing some basic tests with the kernel and thought I would share the current progress.

 

things added:

 

joystick sampling (data readout between where HUD area and game screen meet)

 

temporary hard coded animation to guage best animation speed(s)

 

raw vertical movement (no actual jump or crouch yet)

 

 

 

The animation looks a little off but thats because horizontal movement has not been added yet.

 

Doing baby steps here. Every step is a step twards pogress.

  • Like 2
Link to comment
Share on other sites

Been doing some basic tests with the kernel and thought I would share the current progress.

 

things added:

 

joystick sampling (data readout between where HUD area and game screen meet)

 

temporary hard coded animation to guage best animation speed(s)

 

raw vertical movement (no actual jump or crouch yet)

 

 

 

The animation looks a little off but thats because horizontal movement has not been added yet.

 

Doing baby steps here. Every step is a step twards progress.

 

 

update:

I removed the constant animation and added left facing to the mix. Just tryin to get a feel for the controls. Guess im getting in the 'zone' or something :D

 

 

 

Next on the list is horizontal movement and jump and crouch graphics

 

And BTW, some documentation out there for the TIA is incorrect with respect to REFP0 (REFP1).

 

For D7|D6|D5|D4|D3|D2|D1|D0 (the register associated with REFP)

It is "D3" that needs to be set. Some documents I have read as D2 which does nothing.

This needs to be 0 for non reflective and 1 for reflective.

 

 

This is the most current file.

 

Castlevania 2600 kernel v2.6.1 new input.bin

Edited by grafixbmp
  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...

Wow! That looks amazing. How gaming history might have changed if games like this had been in the works in the early 80's. I just want to play hooky and run that cart all day.. of course as a parent and teacher that isn't the best example, but whatever... kudos to you that is outstanding!

Link to comment
Share on other sites

  • 3 weeks later...

Been a while since an update. Here is the current state of the project.

 

Added crouch graphic for both crouching and jumping. Still need to offset the vertical position when only crouching.

Next task is to add both a gravity routine and ground collision.

 

Castlevania 2600 kernel v2.6.1 new input.bin

Link to comment
Share on other sites

@grafixbmp: When you first started this project I honestly pegged you as an idea man that would probably abandon this project after you realized its complexity. Put simply, I was DEAD WRONG! This latest binary is amazing. No flicker. On a system designed for PONG this is clearly, recognizably Castlevania.

 

You give me hope for my own projects. Carry on!!

 

P.S. Belmonts pants change colors after crouching and standing again (but you knew that)

Link to comment
Share on other sites

@grafixbmp: When you first started this project I honestly pegged you as an idea man that would probably abandon this project after you realized its complexity. Put simply, I was DEAD WRONG! This latest binary is amazing. No flicker. On a system designed for PONG this is clearly, recognizably Castlevania.

 

You give me hope for my own projects. Carry on!!

 

P.S. Belmonts pants change colors after crouching and standing again (but you knew that)

 

Thanks man. That means alot to me. And yes I knew about the bug. It only happens when the stick goes directly from crouch to left or right but since it is only a visual bug and not anything that hinders future gameplay, it won't have top priority at this time.

 

I know I mentioned that gavity and collision come next but I had an idea last night about something else that may need to come before those. A single RAM vaiable used as an idirect jump. I call it the "primary overide vector". It temprarily takes control over simon for many things. Jumping, gravity, whip, mace, enemy hit, secondary weapon, etc. I actually surprised myself cause I don't see how I got this far with out a "POV" in place.

 

And trust me wne I say I am very aware of the complexity cause most of the code is stuck in my head with the majority of the complexity and I need to get it in digital format instead of braincell format. :D

 

I've never been the fastest at coding. I'm too slow at it. I'm not as experienced at it either but the slow pace is all there is now being it's a one person project.

 

If I get stuck anywhere along the way, would you care to lend a few braincells to the cause? And that goes for anyone else as well.

 

We all know the mechanics of the original versions of the game so replicating thoes mechanics leaves little room for original game design which should make it easier... :roll:

Edited by grafixbmp
Link to comment
Share on other sites

If I get stuck anywhere along the way, would you care to lend a few braincells to the cause?

 

I'd be honored to. Of course, the standard disclaimer that I'm a BASIC newb-4-lyfe applies. Right now I'm making a side-scrolling platform engine for the Genesis. If any of that knowledge would help I'll make sure to chip in my 2 cents (which, ironically, usually makes no sense :P)

Link to comment
Share on other sites

Well I had the drive to go ahead and fix the slight control issues with crouching and I think its more spot on to the original(still need to make it where he stays on the ground though). I also slightly spead up the animation. I think the next few updates are going to be nice.

Castlevania 2600 kernel v2.6.2.bin

  • Like 1
Link to comment
Share on other sites

Just out of curiosity has the writer put this on youtube yet? Thanks.

Thats a good question. Up till now I hadn't given it much thought. But I would want to wait a bit before posting up a video just yet. I want to have enough worth posting first.

 

I want to get all 8 banks set first, with gravity and hoizontal movement added, new screens loading routine. terrain collision and stair recognition. Around the time music and the HUD are being added would be good for a video.

Link to comment
Share on other sites

Vampire Killer 2600! Are you gonna go the Gyruss route and exclude sound fx to take advantage of both sound channels?

 

 

Ever since the early stages in design and the briliant work of thegoldenband with enough music to start out with, I thought about which way to go about incorporating as much sound as possible.

 

I plan on using a music engine based directly on the one created by Richi_S. It was always what I wanted in a sound system and far better than I could ever do. I especialy like the envelopes available. Channel 0 will be lead and channel 1 the bass line. I am however hoping to add an aditional part that doesn't run during vsync. This runs as a multiplexer of the 2 channels. The portion for channel 1 adds percussion multiplexed in with the base and the additions to channel 0 are unique. with chalnnel 0, I'm going to try doing a strait multiplex between the lead music and sound FX only because one is actiual notes and the other is just noise. It will allow for musical continuity even though it may not sound great at least it will be less broken and still allow for SFX. nd because they are so diffrent from each other, the SFX will have their own volume controls and will never share the same waveform as the lead in order to keep distiction between them.

Link to comment
Share on other sites

  • 3 months later...

Well, hello everyone. Been a while. First off i'd like to say thank you for your continued support and encouragement. It is always most welcome. It's been a stressful year to say the least. I'm sure everyone out there has had their share of it. I had to take a bit of a break from this project for a while. It was begining to consume me so much, I couldn't think strait about anything else so I let it go for a few months. The only real thing keeping me from progressing further is myself. I lack good organizational skills and focus (not that I haven't tried till i'm blue in the face lol) but I'll never discard this project just cause its too hard (but not impossible) to do. There will be no official release date until a lot more of the framework code is in place. But since I have trouble keeping focus/concentration on code, That is where the community comes in. Anyone from the community with a familiarity with programming (assembly in general) no matter how little, a strong understanding of castlevania (not just in playing it but in the physics of the program, ex: where enemies and items appear, attributes, scoring, quirks, and glitches) and the desire to help squeeze a 128k (nes) game into 32k (atari 2600) ROM, please come forth.

 

The current work has the HUD ready to be assembled and the screen loader is in the works. But I need to drop all the stand alone code I have into the f4SC template I have. still trying to fully figure that out. I have "0" hands-on experience with using a bankswitched design. The other thing I wanted to open up to the floor is level designing. No coding experience is needed for this but there are some strict rules for implementation. If anyone i intrested then here they are.

 

A castlevania 2600 screen is made up of 78 scanlines worth of data.

These scanlines are spaced apart by one blank scanline. This brings the effective visual total to 155 scanlines.

Each screen is represented by 40 bytes of data.

Each of these bytes indexes 5 bytes worth of data. one byte being PF color while the other 4 are the image data

 

These 40 bytes are displayed in a cross repeated order like so:

 

level image

scanline 1: byte 40

scanline 2: none

scanline 3: byte 39

scanline 4: none

scanline 5: byte 40

scanline 6: none

scanline 7: byte 39

scanline 8: none

 

This pattern repeats until reaching byte 0

 

This method allows for upto a page of options worth of image data to be reused numerous times

 

Along with the 40 bytes is 5 more bytes. Each screen worth of 40 bytes will have these additional 5 bytes. They are used for the collision detection routine. There are 40 bits in 5 bytes, and so represent the image data. If any bit is 0, the scanline of data it represents is ignored for collisions. If it is 1, then that scanline is monitored for possible collisions.

 

Every scanline drawn, which also is used for collisions, may have a special pattern which will trigger a climb up or down stairs.

 

This pattern is simply a bit skip '00111010' this bit skip is a stair going down and right. '00101111' and this goes down and left.

 

From the floor going up, will have similar patterns.

 

so 45 bytes sofar..

 

6 additional bytes are added for candelabra (active,amount/spacing, location)

 

There are 6 possible rows where they may appear. a single bit tells if any are to appear. 3 bits indicate 1, 2, or 3 and how far apart they sit. the last 4 bits indicate horizontal location of screen. these will allways appear fixed (don't move).

 

This brings each screen to 51 bytes of data. Add one more byte for BG color which gets us to 52.

 

For all this data (52 bytes for each screen) to fit into a single bank it gives a total of 78.77 screens that can be displayed. I planned to have another bank to fill for additional screens (specialty screens) about 35 more than this.

 

I also will have 2 main game play kernels. Each of these has some identical data (simon, some enemies, etc) but the screen image data is almost totaly diffrent. This gives 2 diffrent "sudo tile sets/scanline data" that will help to keep diversity in the color and look of each level.

 

So to recap If anyone wants to help design gamescreens, Its 1 byte = BG color, 40 bytes = game screen, 5 bytes = collision detection, and 6 bytes = candles

 

I had started out with the first level and plan to finish it out.

 

Good colors for each screen is important And remember that any scanline of data could be reused elsewhere even if the BG color is diffrent.

 

The greatest solution is also its biggest weakness. Croud sourcing the level design gets alot done in a short time but the problem is in the squeezing of the data.

 

Use as little space for screen data as possible because it will need to be shared across multiple levels and BG colors.

 

When anyone finishes a level, post it for community refinement. This will help others out in using your data to help make other levels and eleminating redundant scanline data. In the demo I used maybe 12 to 18 chunks of 5 bytes to make the screen. and alot of that data will be reused in the next screens, there by keeping me from having to use up all the space. Once the majority agree on any set of screen data, it will be a generic piece others can use in their levels. I will try to get the ball rolling into January but for now, I want to get this game done cause I can't do it alone and I don't want to loose my sanity in such an attempt.

 

anyone willing to participate, please submit a visual image and data list of the level you choose to work on.

 

The following image shows the fundamental workings of the engine and how things are drawn to the screen. Candelabra are represented by the triangles, scanline loading is color coded on the left and simon is represented in 2 parts (split sprite). there are 2 enemy/items on screen. Please take time to examine this image. Any questions, post in this forum.

 

post-10601-0-78476300-1324414503_thumb.png

 

Rock on!

Link to comment
Share on other sites

Here's a utility that may also help:

 

"Stake is a Windows-based level editor for the NES ROM, Castlevania. It was developed

using Delphi 6, on the Windows XP operating system. It supports the many versions of

Castlevania, such as the european ROM, the american ROM, and even Akumajou Dracula -

the special rerelease of the Japanese CV. It doesn't however, support the Famicom Disk

System original of CV. (Yet :))"

 

http://www.zophar.net/utilities/neslevel/stake.html

 

ROM not included. :P

 

Illya

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   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...