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