grafixbmp

The startings of a battle screen.

added a few new images and updated what was there just a bit. Funny that this original post was #100.

Just wondering if this is still being worked on or if you plan to come back to it soon. It was looking really good. Well, I only designed the game screens but Propane13 did the coding. Last I heard, he had been looking into adapting it to another similar style game. However, at the time, I think he had a few other things going that took priority.

been thinkin about adding in another level of compression to data storage. This may or maynot work but it's worth exploring. I already have 5 bytes to indicate which scanlines are used for collisions. I thought about breaking the screen into 8 sections am use a single byte to tell the screen kernel to switch over to one that loads the screen data diffrently. It would only store the first and second bytes/sections of the screen, and then, with the timming right, re-store that same data backwards. data: A B C D F Color PF1 PF2 PF2 PF1 standard kernel B A C D F repeat kernel B A C A C And then collision etection will take this into effect based on the byte that shifts the kernel(s) .

Hello all. I've been redesigning the screen layout to come closer into sync with the look of the NES version and in doing so added more color to the scene. this may closer refect the final look than anything thus far. Once I have the screen loader code in place and simon can move, then new screens will be added. enjoy the latest demo. Castlevania 2600 kernel v2.6.3.bin Thanks go out to pac man red. Your rendition of dracula's castle helped me to upate the first level. And to the others who have contribute as well. Much thanks.

I searched through my archives and found the engine created by Richi_S. All he asks is credit for it. IGSE.txt

As a matter of fact, there is a sort of compression going on. Each screen worth of data (40 bytes) pulls its graphic info from one of 2 master data tables. 5 bytes for collision data references the 40 bytes themselves which in turn re-references the 40 bytes again. 1 = used for collisions 0 = ignore for collisions. 4 bytes for nearly all items is split into 2 groups 2 indicate positioning and depending on what the positioning is, may indicate what type of items there are to be placed The other 2 indicate 4 items per screen. with the last full byte for enemy data. Alot o his comes from table lookups which is where the compresion comes from. Not much diffrent from techniques use for music compaction.

Ok. Thought I would share some quick info about data storage of the game. In particular enemies, all candles (where and what). all hidden items, brick items All collision detection, and level screens. All info for each screen takes 50 bytes. for each screen: 1 byte for enemy 4 bytes for candle/brick/hidden items 5 bytes for collision data and 40 for playfield image data Since I intend to use f4sc for the bankswitching format, this is the basic grouping of the ROM starting with the above mentioned: About a page an a half for screen data Two pages for all graphics image data as well as screen kernel one page for music and sound. one page for all object attributes and tables one page for main game engine And what ever is left for opening/ map sequence/ closing/ an anything else left. Gonna suck now cause I need to build some extensive tables of data.

Well, I was gonna suggest a sound engine created by Richi_S but apparently he completely dropped of the forums with no posts and only some basic info. He created a nice compact engine with envelope modulation. I liked it so much, was gonna use it in castlevania.

Ok ladies and gents, after a time where I couldn't concentrate on coding. i'm slowly coming back with some long time comming help from my roommate. Your a lifesaver Matt. It's a small update (very tiny) but it means all the world to me since it works properly now and I'm no longer frustrated by it. He can now crouch with the best of them. God knows what will be comming next. Castlevania 2600 kernel v2.6.3.bin Well, kinda spoke too soon. It works, don't get me wrong. But a bug crept back up when going from down to an imediate left or right. Just a split second graphics garble that i'll fix later. Otherwise, I'm perfectly happy with the results.

When I was little, my dad got a vic 20 in the styrofoam with power supply, but I didn't have any software to run on it. At that time the C=64 was my thing and I had crap loads of disks for it. He eventualy sold it shortly after geting it. I also had a C= +4 which wound up in the same boat. However, my dad had the newest system from Commodore a 128D. This thing was cool because of the diffrent modes it ran in. Once, I even had to code it by hand from a gaming mag for a game I wanted to play. Which emulator would you recomend for a vic 20? I'll look up some info on the game in the mean time.

exactly right. it was a very simple example but it had crossed my mind about a year and a half ago.

Well, Later this year I'll have a major update for castlevania. But in the mean time, I had an idea from a while back and decided to do a mock up of it just for show (proof of concept). I would love to see it as a real game someday. If anyone would like to run with it, be my guest. Make it your own. If not, I may attempt it someday but not anytime soon. I'm sure many of you will know what game inspired this one. I call it Quantumetric Wars. hope ya'll like it.

excellent. when I get f4sc setup, I'll start loading in screens to test the screen loading code. this part should be the easiest of all.

Everything is quite recognizable. But you also get to choose the background color behind the visible scanline. the left and right borders are always black though.

DASM could simply just need an overhaul/update.

eh yes and no. of the 2 real channels the system has, they will both be doing harmony music with a lead and a base line almost all the time.The sound channel settings can be adjusted really anytime while the game runs but often this is designed to adjust the settings 60 times a second. The channel doing the base line also handles pricussion. pricussion sounds are fast, short, and full of noise. When this happens, pricussion simply over writes the current musical data for a single frame. Just enough to get a "tat" sound without destroying the sound of the base once the it has been reloaded the next frame. I havne't tested the last part yet, but It may accomplish what I want to hear. sound FX are short sound patterns that last less than a few seconds. since they are so diffrent from the actual game music, I want to alternate between lead and soundFX by alternating them 30 times a second. its gonna be choppy but may hold continuity with the music. If I wanted to really get extra channels out of the 2 the system has, I'd probably need to adjust them every 2-4 scanlines. say roughly (262/ 3)*60 = big #. bigger than I want to mess with lol

Now thats nice. wish I knew about this program earlier on. inspiration is high.

Wow. Very nice. I think that helps more with data compaction. Just a matter of building a data matrix table based on these levels. static screens. I like how it helps with candelabra. This will do well for accuracy.

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. Rock on!

Would be nice if it had a hardware based pause button. Sorta like the mod kit for 2600. And (jokingly) it could be called "Uhtaree"

that last one was the highlight of my day. I ran it and played with it for about 10 min. I was fiddlin with how atari skewing works today before I even saw your post. I bet there are several people wouldn't be able to beileve this was running on an atari. It just looks that good.

Game is too difficult starting out. needs a gradual increase in the challenge. noone will want to play it if they can't make it past the first screen within a few tries.

Every test here shows that it can be faked so well that racing games (and such) could not only be 2 player with this perspective but could play smoother than most racing games thus far. Excellent work. I take it the PF pixels aren't even being used?

With the scrolling circles, what if they were expanded to 2x sprites and then there would be more implied resolution when it is skewed by down to single color clocks for more detailed circles. And I know you would have your own way of coding the system, but this is sorta what I thought about before Perhaps a lookup table listing out the smooth skewing say to the 4th-8th scanline. then this way there could be multiple stacked skewed linear vectors that can flex as if they were strait lines when you race through the track. Like only the patterns that give an evenly distributed skewed strait line. Then as a section drops down the screen, the skew vector could be changed and therefore animate/flex across the screen, implying 2D flat terain viewed from a 3D perspective.