286 replies to this topic

[grafixbmp]

supercat, on Mon Oct 13, 2008 6:50 PM, said:

It is not realistically possible to show a horizontally-mobile multiplexed-shape sprite on the same scan line as an asymmetric playfield. The only realistic options I can see would be to either use venetian blinds for the whip attack and playfield or use 30Hz flicker between the whip and the player (possibly using a 2x- or 4x-sized whip). The former option might work nicely if the whip attack was only done while facing right (one would switch off NUSIZ0 on the lines with the drawn playfield), but I can't see any way to make it work while facing left, other than Venetian-striping the player (which would probably look bad).

If you do away with the nice looking 'crack' at the end of the whip, you could display the whip as an 8-pixel-wide missile or Ball shifted left or right 7 pixels each scan line. Note that you wouldn't have to write HMxx during the kernel, nor use any logic to decide when to hit HMOVE. Simply hit HMOVE every scan line, and figure the correct initial position for the missile so that it will be in the right place on the lines where it's displayed.

I am thanking you for your input here. I decided to take your advice and do a 30Hz flicker and still keep the 'crack' at the end of the whip. The missle at full 8 times wide fills the void perfectly. THis also allows the whip to be blue like in the original game (or close) And with the player and mace flickering, fully extending is easy enough by also switching out locations for the missle by 8 pixels so that it appears twice its width for the longest primary weapon possible. This will be far easier spreading it out over 2 frames with less TIA register writes for any given scanline.

Big thanks again. This is the first thing to expect in demo form.

Incendently, this will also make going left easier too. I may have the far left (first visible 4 color clocks) not show any sprites as well as the fat right (last 4 color clocks) THis will help to save room and add all the detailsfor read and writes.

Edited by grafixbmp, Fri Nov 7, 2008 6:14 PM.

[nonner242]

one of my top 5 games on a 2600

[grafixbmp]

Probably the hardest part I will have is organizing my data. I have once said before that the appearance of the game will look like double scanline screens (or 2 scanline kernels) also I have said that the idea is to load the screen so that it looks asymetrical but not every register of the PF is always updated. I now have an illustration that may shed some light on the subject and show a crude form of the whole sub-kernel method I hope to design. One of the biggest hopes for this is that the engine itself is HIGHLY reusable for other games.

This image does not show any of the possible reloading of data per scanline (ie: a byte is loaded and stored to PF0 and PF2 then another byte is loaded and stored to PF1)

It also does not show color stores to the BG or PF.

It only shows how scanlines are hopefully going to be made and how the load and stores are arranged.


Given that immediates are 2

Indexed data loads are 4+ for absolutes

and stores to the TIA are 3

The following image shows 2 of the screens I have previously mocked up and the PF register load and store diagram.

The screens are numbered as the order they come in as the game would be played.

The legend at the bottom shows what each color indicates.

And finaly just so any of you know, the images show single scanline read and writes not doubbles. The LOOK of the finished image seems to have double scanlines.


The reason I did this is to try to discern a pattern that I can exploit as to help create the diffrent kernels and how many scanline each spans to save space in the long run.

[grafixbmp]

As a pass time to the work. I have been recreating the title screen. I figured since this area really has no game play, it didn't mater what I did with the sprites as long as I was able to fit in the sprites to help with the image. this would work fine. So I designed a mockup of What I would hope I can recreate in code.



To give credit where credit is due. I did a little more work on the logo and added the creators to it. Wanted to see what it might look like.

Edited by grafixbmp, Tue Nov 18, 2008 4:44 PM.

[supercat]

grafixbmp, on Mon Nov 17, 2008 12:54 AM, said:

As a pass time to the work. I have been recreating the title screen. I figured since this area really has no game play, it didn't mater what I did with the sprites as long as I was able to fit in the sprites to help with the image.

Not quite sure what sprites you're planning to have where. I doubt you can do everything you show there using the 2600's resources. Still sometimes it's surprising what is possible.

Attached Files

•  logo.bin   4K   163 downloads

[grafixbmp]

supercat, on Wed Nov 19, 2008 8:45 AM, said:

grafixbmp, on Mon Nov 17, 2008 12:54 AM, said:

As a pass time to the work. I have been recreating the title screen. I figured since this area really has no game play, it didn't mater what I did with the sprites as long as I was able to fit in the sprites to help with the image.

Not quite sure what sprites you're planning to have where. I doubt you can do everything you show there using the 2600's resources. Still sometimes it's surprising what is possible.

here is a hint: Most if not all things during the title are displayed at 30 Hz flicker using both sprites and missles somewhere on screen. This also includes the playfield. The ball is not currently used.

[Propane13]

I believe that the title screen without the word Konami is possible without flicker.

If you wanted, I could try to make a version of it (not sure how much external involvement you're looking for).

What I would do is in the 3-0 color lines (red, black, green) set red as COLUBK, and then zero as the PF color.
Once PF0 is drawn, change the color to green. There *should* be enough time to update PF registers, and then change COLUPF back at the appropriate time.

-John

Edited by Propane13, Thu Dec 4, 2008 2:59 PM.

[grafixbmp]

Propane13, on Thu Dec 4, 2008 2:54 PM, said:

I believe that the title screen without the word Konami is possible without flicker.

If you wanted, I could try to make a version of it (not sure how much external involvement you're looking for).

What I would do is in the 3-0 color lines (red, black, green) set red as COLUBK, and then zero as the PF color.
Once PF0 is drawn, change the color to green. There *should* be enough time to update PF registers, and then change COLUPF back at the appropriate time.

-John

I don't mind if you want. However, I figured with a black background that flicker wouldn't even be noticed and would allow me to have more detail in the process.


On a side note, I have a new image.

Update: have a new castle layout that looks more like the original NES version's layout.


And, already from some friends and people here as well seem to have a good idea about the way it looks on an atari, so as a nickname and for fun it can be a.k.a. "Lego Castlevania"

Edited by grafixbmp, Wed Feb 18, 2009 6:29 PM.

[grafixbmp]

grafixbmp, on Tue Nov 11, 2008 11:42 PM, said:

Probably the hardest part I will have is organizing my data. I have once said before that the appearance of the game will look like double scanline screens (or 2 scanline kernels) also I have said that the idea is to load the screen so that it looks asymetrical but not every register of the PF is always updated. I now have an illustration that may shed some light on the subject and show a crude form of the whole sub-kernel method I hope to design. One of the biggest hopes for this is that the engine itself is HIGHLY reusable for other games.

This image does not show any of the possible reloading of data per scanline (ie: a byte is loaded and stored to PF0 and PF2 then another byte is loaded and stored to PF1)

It also does not show color stores to the BG or PF.

It only shows how scanlines are hopefully going to be made and how the load and stores are arranged.


Given that immediates are 2

Indexed data loads are 4+ for absolutes

and stores to the TIA are 3

The following image shows 2 of the screens I have previously mocked up and the PF register load and store diagram.

The screens are numbered as the order they come in as the game would be played.

The legend at the bottom shows what each color indicates.

And finaly just so any of you know, the images show single scanline read and writes not doubbles. The LOOK of the finished image seems to have double scanlines.
castleva..._compare.PNG

The reason I did this is to try to discern a pattern that I can exploit as to help create the diffrent kernels and how many scanline each spans to save space in the long run.

To clarify some of this, The first image is not going to be that detailed in how screens are loaded but an extreme ideal way to do it. Unfortunately no Atari programer has the luxury of having so complexed kernels.

The best idea to date is to have variable kernels. Not variable as in "any thing goes" kind of way but kernel groups like 2 4 8 and 16 scan lines at a time and a proper arangement of these would theoreticaly limit the number of memeory locations used for the stack. I also thought about another thing. A simple yet detailed design for the music, or the the music and sound effects to fit within the V sync area. Less than 3 scanlines worth of space for music to fit and be streamlined to do so. This is the current thing I am looking into. I could use the upper memory for things I won't need during screen writes with the music and the score graphics pointers.

But really, has anyone had any experience with using the V sync area for music?

[grafixbmp]

Unfortunately I have some sad news today. A good friend of mine, James Nathan Ghent past away a few days ago. I worked with him in Electronics at Wal-Mart and in honor of him and his love for videogames, I have decided to dedicate this project in his memory. He played castlevania like crazy and even though he prefered Simons Quest over the first one, I still think it will be a great to do so in his honor.

He died at the age of 28 while driving to work on Wednsday the 10th at 12:45 pm. All of his friends and myself will miss him greatly.

I hope to have his listing in the credits at the end of the game.

Before Wednsday, I had been trying to design a music system, the bulk of which would reside in the V sync area. I hope to have the first tune of the game wrote soon given this has nothing to do with the graphics I expect it to be a bit easier to acomplish. Hoping to have this part by Feb.

RIP Nate.

[grafixbmp]

Well just kinda guestimating the math, it looks like ne level (the first) will need atleast 8k. I have a crude design which should be demoed here around the last part of Feb for a music engine and the only thing I hope to do with it first is the intro theme to the first level. I also have every single piece of sprite data (I think) except the large vampire bat at the end of the first level and HUD icons and numbers. This page of sprites takes 628 bytes alone just for the first level. This doesn't include color info, sprite spacing, or any other data needed for their rendering. But it looks nice and finishes up all graphics for simon. YAY!

I eliminated some unneeded data and lowered the bytes needed from 628 to 613


With the first level boss finished, the total bytes are around 641. Now with every weapon in the first level present, the final total of bytes are 665. They were 666 but I removed one byte for beter luck. I am hoping to have all sprite data including HUD images to around 768 or so.

And as an added bonus, to visualy see how that impacts a 4k space here is this.

Edited by grafixbmp, Wed Jan 7, 2009 12:17 PM.

[Random Terrain]

Can't wait to see a working demo.

[Corby]

I am very impressed. Just went through the whole tread, and I hope your still at it. I just amazes me what the 2600 can do.

keep up the good work

[grafixbmp]

There is one thing that I could use some advice on. With this sprite table I have showing the full color sprites used in the first level, I have simon (for the most part) organized so that abut half of his images are a mixture of about 2 diffrent sections. These include torso and legs which can combine in diffrent arangements to acheive all the looks of his figure. The thing I would like input on is having a sprite rendering routine that can not only display a sprite from top to bottom but can jump half way though one piece and land at another lower piece that way I can keep the data storage for the graphics down and be able to store more but this gives more overhead. I think there should be no problem but have any of you out there have any experience with this form of complexed sub sprite data jumping before? And if so what would you recomend?

[lapetino]

This looks great. I'm excited to see a working .bin. Keep up the good work!

[grafixbmp]

I am thinking of a few things to organize the kernel as best as I can. I am embedding the candelabra into the kernel design as 6 bands that repeat thoes 6 times as the background is drawn. I have almost finished the layout of the first level and have decided to simplify the playfield ever so slightly further than what it already is. I also toyed with the thought of during the gamplay area (excluding the hud and possibly the lowest 22 scanlines) updating the background PF area as such: draw scanlines 1 2 then 5 6 then 9 10 etc.
and on the second frame pass do as such 3 4 then 7 8 etc.
This may cause some sort of flicker effect but I am thinking that this will still look quite well and will free up several scanlines for sprite updates and allow the gameplay to progress easier than before but I still would like to keep from this.

I would also like to ask for a rally of others who would be willing to assist in any way they think would help. I only would like to use the graphics that have been created so far and would like to keep the look as close as possible to the classic castlevania. As of right now I am only intrested in completing the first level then the other can fall into place. The music should be along near the end of the month. At least that will be working. lol

It is not that I have lost intrest in the project. On the contrary, I enjoy every part of it but have gotten to the point of being burned out on the design and can't get the coding in my head. My mind just can't retain all the info well enough to get it into code. I hope many of you understand where I am coming from. Maybe I am just geting lazy or something but I just... I don't know. Man when I was younger I could program like crazy but now... I can't concentrate on the task anymore.

NEW ANIMATIONS:
I added some animations to see if the frames of the sprites line up properly


Level 1 Boss bigbat


Level 2 Boss Big Medusa


Lit Candelabra


Level 2 ghostly flaming skull


Level 2 knight


Level 2 small medusa head


Level finish crystal orb

Some of these animations are not to scale to each other. A few were enlarged for detail to be seen easier.

Edited by grafixbmp, Sun Feb 8, 2009 11:31 PM.

[grafixbmp]

Progress is going rather slowly. I now have a working design which has only 2 bytes per note/instrument/sustain and rest. However, this only allows 8 possible instrumentsand upto almost a fourth of a second for sustain and upto almost a forth of a sec for a rest. This should for the majority help keep music data storage to a min. the first obviously uses the first 3 bits for instrument and the other 5 bits for note. The second byte is split evenly for the sustains and rests. The design for the tracking of the musical segments works fine but the music data of the original format just seemed to take up too much data. The other part being the sound effects is ran as a secondary part. This is checked for a sound effect or not. If not, the second voice plays the notes/instruments for the current track location. If there is a soundeffect the data is changed accordingly and then played. When the sound effect is finished, the background music continues on as if no intreuptions took place. Each sound effect only last upto one second or 60 frames. And just like the music, the current state of either voice has the potential to be changed 60 times for the one second of the sound effect. Granted this engine is simple compared to others but it covers all the basis I need. The sound effects are the only part with the ability for manual volume control. The music does not. I should have something in the next 2 weeks for everyone to hear but the sound effects part will have to wait for now.

[Random Terrain]

grafixbmp, on Mon Feb 2, 2009 7:24 PM, said:

Maybe I am just geting lazy or something but I just... I don't know. Man when I was younger I could program like crazy but now... I can't concentrate on the task anymore.

All I do is work with batari Basic and you'd think I could finish a game with that since it's so easy, but I'm a victim of the good life. There are all kinds of cool things begging for my attention and I can't get anything done.

[Rastignac]

grafixbmp, on Mon Mar 2, 2009 11:05 AM, said:

Progress is going rather slowly.

Slow speed is not a problem: we'll wait ! Your CastleVania looks really great. It's impressive. Please, don't stop. We're waiting for the first BIN. CastleVania 2600 can beat MegaMan 2600 ;)

[grafixbmp]

Rastignac, on Wed Mar 4, 2009 6:03 AM, said:

grafixbmp, on Mon Mar 2, 2009 11:05 AM, said:

Progress is going rather slowly.

Slow speed is not a problem: we'll wait ! Your CastleVania looks really great. It's impressive. Please, don't stop. We're waiting for the first BIN. CastleVania 2600 can beat MegaMan 2600

I appreciate your vote of confidence. With a project of this magnitude I figure for a complete game would take close to 2 years. But with such a complexed design, I will need to take several diffrent points of view tward the task so that the best balance occurs. I have already gone through about 3 diffrent designs and combinations of each. I hope to have 3 diffrent demo bins with one doing a sample of music, one having basic control of simon and an automatic sequence that incorporates a full background and animation for the intro and the title screen. Look for the majority of these in the summer (my guess). A music sample is in the works for in a few weeks.

[yuppicide]

First off, sorry to hear about your friend's death.

Second, this game looks freakin sweet!

Legovania?

[the.golden.ax]

All I can say is Wow. Keep up the good work. Even if it take 5 years this will be a hit, and go down in the books as a 2600 triumph.

AX

[grafixbmp]

I thank you all from the bottom of my heart. It has been tough lately and thank God I backed up all my info to my new netbook coding computer. My desktop sorta crashed and I am hoping I can recover the data from my 500 GB drive cause there is alot of things I want to save there. It wasn't my fault though. A friend of mine rewrote my MBR and FUBARed it and now the partitions arent recognized.

I have a friend that is a professional musician and offered to help me out with the music come May. The rest has fried my brain in the mean time. I will never say die though. I do have an updated screen if you would like to see.

It does hurt me that I can't get any working demo's out right away but I am not as experienced as most but am confident I can get it to work. On that you can rest easy.

Edited by grafixbmp, Wed Mar 25, 2009 5:59 PM.

[Devin]

Wow, this might be the most ambitious homebrew ever!

Let me know if you need help with the music. I wrote a program can somewhat reliably convert MIDI to TIA.

[grafixbmp]

Devin, on Fri Mar 27, 2009 3:04 PM, said:

Wow, this might be the most ambitious homebrew ever!

Let me know if you need help with the music. I wrote a program can somewhat reliably convert MIDI to TIA.

THat sounds nice. Would love to know more about it. All help is welcome.