Porting the original classic Castlevania to the 2600

[+Random Terrain]

If this really turns into a full game, many shirts will be soaked in drool and many pants will be pooped.

[+grafixbmp]

If this really turns into a full game, many shirts will be soaked in drool and many pants will be pooped.

 

I greatly appreciate your comments as I do all positive comments. I am going to break down and try to use Batari basic to get the plane off the ground sorta speak. This is just to get code down which I can then work with and change.

 

There are a few things I could use some help with if it isn't a big stretch.

 

First thing is, I would like to know some examples of dynamic sprite rendering code which will multiplex only when they cross paths. This is the one thing I never quite could figure out as to how to distinguish which parts of the kernel is used at the right times. I know of a few games which have done this and that the NES had this feature natively I belive. This would also apply to the missles as well as they need to multiplex during certain times.

 

The other thing is music. I would love to be able to have a subroutine to play music data that is fluid enough so that changes can be made easily. Some music for the atari sounds so strict where each note is just a predefined pulse length and that would make the classic music sound horrible. The variables are: sound type, note duration, pause duration, subtrack repeat, and an override for sound effects on the second channel. This subroutine will only need to be called once per frame at most. The track repeat will help greatly on storage given that most of the soundtracks for castlevania have subtracks that repeat twice as it plays.

 

Thanks in advance for all you guy's help. and your criticism weather positive or negative. I belive in this project and will see THIS ONE through even if it takes 2 years.

 

I just don't want to wind up feeling like I am the only one on a sinking ship. But hopefully it won't come to that.

[+grafixbmp]

As far as the look of the levels go, how about this. The levels playfields are drawn on screen by having the entire level design be nothing more than just pictures that are made by lots of mini kernels broken into 8 pixel height mini kernels which vary from just terain to enemey prites to other sprites and their locations. This way the engine for the game being displayed are located in one bank with the raw game engine located in another bank. And the level and sprite graphics are in another bank with the level call data for 6 levels. The raw engine bank wouldhave the music data too. Granted many areas will be broken up depending on where program structures and subroutines need to be for faster calls without having to do bank jumps at inconvenient places.

[TROGDOR]

The mockups look very nice, but I honestly don't think this is feasible on a 2600. I count 6 playfield updates + p0 graphics update + p0 color update + p1 graphics update + p1 color update + missle in one scanline. Optimally, that's 42 + 17 + 8 + 17 + 8 + 13 = 105 cycles, not including loop overhead. That's not possible, even in RAM. Even with a 2LK, which this appears to be, you'll still have 42 + 17 + 8 + 13 = 80 cycles.

 

Edit: I reread the posts, and see that you're trying to minimize the playfield refresh. That's a good start to making this feasible. But keep in mind is that even with a double-height display, you still have to update the playfield each scanline if it's asynchronous. That's why asych playfields are so tough to implement on a 2600, and usually require venetian blind implementations for complex backgrounds.

 

The graphics translation for Simon is impressive. Well done.

Edited October 8, 2008 by TROGDOR

[+grafixbmp]

The mockups look very nice, but I honestly don't think this is feasible on a 2600. I count 6 playfield updates + p0 graphics update + p0 color update + p1 graphics update + p1 color update + missle in one scanline. Optimally, that's 42 + 17 + 8 + 17 + 8 + 13 = 105 cycles, not including loop overhead. That's not possible, even in RAM. Even with a 2LK, which this appears to be, you'll still have 42 + 17 + 8 + 13 = 80 cycles.

 

Edit: I reread the posts, and see that you're trying to minimize the playfield refresh. That's a good start to making this feasible. But keep in mind is that even with a double-height display, you still have to update the playfield each scanline if it's asynchronous. That's why asych playfields are so tough to implement on a 2600, and usually require venetian blind implementations for complex backgrounds.

 

The graphics translation for Simon is impressive. Well done.

 

I intended to have each screen work so that nomore than 5 updates for the PF registers happen. Optimaly 4. all graphics for P1 are double height even items and candelabra.

 

All color updates are no less than 2 scanlines for any entity of the TIA. The only item that visualy updates the data for each scanline is p0 and this might happen twice per scanline. It would be nice to use the p0 sprite delay feature so that the secon copy uses it instead of the main p0 write or vica vera which ever way it works. I may also have to use the delay for p1 graphic writes.

I see 4 to 5 playfield updates that could read in order from ram twice for each of the 2 scanlines. player 0 data update and no less than 2 scanlines for color updates. The scanlines that color updates do not occur for player0 than data updates for p1 can happen in place. Only 6 scanlines of the whole p0 graphic need duplicates and data updates for the duplicate along with the missle turned on. I guess there is one way to avoid too many writes per scanline and that is some kind of sacrifice of player 1 atributes.

 

So maximum for any scanline would be player 0 data + doubles activated + 4 to 5 playfield writes + player 0 rewrote data + player 0 color + player 1 color + player 1 data.

 

On a side note, when there are few things that needs to be done on screen usualy at the top. (or for the first 3 screens at the far right side.) a single midscanline color change for the PF.

 

single scanline writes:

player 1 needs data every scanline and for 6 of the 30 scanlines, needs it twice along with doubles turned on. May need to do this before anyting and blank the second out untill needed if the H position is offset when doubles are on or off.

 

double scanline writes:

 

p0 has color writes no less than 2 scanlines worth

 

missle 0 for 2 scanlines

 

data for p1 for 2 scanlines

Color for p1 could go as high as no less than 3 or 4 scanlines

 

pf data would be the same for 2 scanlines but would need rewrote each scanline except that if it is wrote the first scanline once, then the second it will not need to be rewrote so that eliminates thoes writes all together which brings the second of the 2 scanline writes to only the changes from left to right.

 

I may be able to make some headway yet. Just have to sacrifice little by little to get it accomplished.

 

I may wind up having to fore go the double p0 graphic and multiplex them when the whip/mace is used but this is a last resort.

 

I'm still trying to figure this out.

 

brief example of playfield writes.

 

worst case

 

First scanline: 3 PF writes for left side, 2 PF writes for the write right side

Second scanline: 2 PF writes for the left side, 2 PF writes for the right side

 

This is maximum for the PF

 

optimal is.

 

First scanline: 3 PF writes for left side, 1 PF writes for the write right side

Second scanline: 1 PF writes for the left side, 1 PF writes for the right side

 

Some parts again still may have a color change mid scanline which means that the color will have to be set back before any screen writes.

 

What do ya think?

Edited October 8, 2008 by grafixbmp

[STGuy1040]

Great work so far! I'm a big Castlevania fan, so if you finish this project and decide to sell it, please put me down for a copy!

[+grafixbmp]

I've been rather busy with work and such and haven't got to do much coding other than some game logic but I just woke up a bit ago and did several items for the game. with that, I now have enough to get some graphic kernels together. I know that with what I have sofar, it will look better on a computer than sheets of paper with notes, erasures, and scribbles. lol! Anyway here are a handful of things/items used in game. most if not all of these will have to share player 1 as multiplexed sprites as player 1 also does enemies and candelabra.

 

 

 

 

I added simon as a refrence and the small smudge in the corner is actualy a joke as it would be missle 0 and represents a thrown holy water but it can never look this color, just whatever player 0 is at the time.

 

Simon, whip upgrade, heart, big heart, pot roast, invincibility jar, II tile

holy water, holy cross, $700, $400, $100

 

Also given that these items are multiplexed, then $1000, when displayed would be as:

$700, blank, $400, blank, $100, blank

 

Edited October 12, 2008 by grafixbmp

[Godzilla]

this is damn impressive. tho i hope someone does lick the 2600 fullscreen. (and achieve sidescrolling in the process.)

[supercat]

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.

[+grafixbmp]

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.

 

The plan is that most all screens at every scanline has nomore than 4 load and stores perscanline And by scanline I mean 2 of them since they contain double pixel height but the first initial one has more loading than just 4 possiblt 5 and blanking out playfield registers can be done by writing directly to the accumulator so no memory spot has to be addresed for a data pull and then it is wrote to the register. THe second of the 2 doesn't even need some rewrites many of the times. Sometimes a register can be written to with the same data from another which saves the fetch. and data can be layed out in order where needed. most enimies have a unique movement and locations with which they happen on the screen so the engine for displaying is created accordingly with minimal screenwrites. Most of the screen is created with several types of sub-kernels. This way data translates directly to each from memory because most all memory is dedicated to specific variables and can be used accordingly. most all graphics can be reused for other levels with color changes. YOu should see the latest level designs I have been doing. the idea is to create the levels in detail first in order to get the whole engine working on a modular level so that say one thing for one level can do the same thing in another level. Because the screen is not completely asymetrical at any given scanline, then more time is left for every other element. The bigest hurdle is to properly display simon with the whip at any horizontal postion. I want to try some sample engines first with doubles turned on and several version of the kernel section for the dependance fo where he is displayed on the screen so that a rewrite to player 0 graphic data register happens between first copy and second copy.

 

If this fails to be possible, then I will do flicker of player 0 for simon and the mace/whip. The missle is there because of the original design. I do however plan to do the exact thing you were mentioning with stretching the graphic for the whip on the skeleton snakes thingys. lol

 

 

 

Here is the original on the nes. Thanks to Badbatman3 for the rip and to Konami for this game wouldn't exist without them.

Edited October 14, 2008 by grafixbmp

[tokumaru]

It's is amazing how even with such blocky graphics the general feel of the game can be kept. You've been doing a great job, keep it up. I really hope you can fully implement this, the 2600 really needs this kind of game!

[+Random Terrain]

The Atari 2600 screens look especially good inside. I hope they'll really look like that. As tokumaru, said, it has the same general feel of the original.

[+grafixbmp]

The Atari 2600 screens look especially good inside. I hope they'll really look like that. As tokumaru, said, it has the same general feel of the original.

 

I greatly appreciate that. In your general opinion, with the 3 pf registers and the 2 scanline aproach along with the spacing of the objects in the background (i.e. grey the brown/orange) and the repeat of some of some of the register from left to right, should this give enough space for code that renders both missles at double height, player 1 sprites at double height and and single height player graphics besides the color changes?

Thanks in advance.

[+Random Terrain]

The Atari 2600 screens look especially good inside. I hope they'll really look like that. As tokumaru, said, it has the same general feel of the original.

 

I greatly appreciate that. In your general opinion, with the 3 pf registers and the 2 scanline aproach along with the spacing of the objects in the background (i.e. grey the brown/orange) and the repeat of some of some of the register from left to right, should this give enough space for code that renders both missles at double height, player 1 sprites at double height and and single height player graphics besides the color changes?

Thanks in advance.

That's a question for people like supercat, Nukey Shay, Thomas Jentzsch, and so on. I just play around with batari Basic, so I'm about as useful as a nipple on a knee.

[supercat]

I greatly appreciate that. In your general opinion, with the 3 pf registers and the 2 scanline aproach along with the spacing of the objects in the background (i.e. grey the brown/orange) and the repeat of some of some of the register from left to right, should this give enough space for code that renders both missles at double height, player 1 sprites at double height and and single height player graphics besides the color changes?

 

As a first approximation, count it up. There are 76 cycles per scan line; 152 cycles for two scan lines.

 

Loading a constant takes two cycles. Loading a single variable takes three. Loading a variable from a fixed table generally takes four. Loading from a movable table takes five. A store takes three.

 

Some looping and decision-making overhead will often be necessary, as may some register-shuffling code. Figure anywhere from five to thirty cycles for that.

 

If the necessary operations total over 152 cycles even before you've considered any looping/decision-making code, they're not going to fit. If they total less than 120, things can probably be made to fit. If in-between, then more detailed analysis will be necessary.

 

Incidentally, the Stella's Stocking menu was very tight on CPU cycles. I actually had to include special logic in the bank-switch chip to allow for zero-cycle bank switching, since the kernel bank-switches twice per scan line.

[+grafixbmp]

I greatly appreciate that. In your general opinion, with the 3 pf registers and the 2 scanline aproach along with the spacing of the objects in the background (i.e. grey the brown/orange) and the repeat of some of some of the register from left to right, should this give enough space for code that renders both missles at double height, player 1 sprites at double height and and single height player graphics besides the color changes?

 

As a first approximation, count it up. There are 76 cycles per scan line; 152 cycles for two scan lines.

 

Loading a constant takes two cycles. Loading a single variable takes three. Loading a variable from a fixed table generally takes four. Loading from a movable table takes five. A store takes three.

 

Some looping and decision-making overhead will often be necessary, as may some register-shuffling code. Figure anywhere from five to thirty cycles for that.

 

If the necessary operations total over 152 cycles even before you've considered any looping/decision-making code, they're not going to fit. If they total less than 120, things can probably be made to fit. If in-between, then more detailed analysis will be necessary.

 

Incidentally, the Stella's Stocking menu was very tight on CPU cycles. I actually had to include special logic in the bank-switch chip to allow for zero-cycle bank switching, since the kernel bank-switches twice per scan line.

 

I like thoes odds supercat. Thankyou.

The way I hope to do all of this is have a table in rom that is called up section by section for each room as it were in order so that the mini kernels can be organized as jumps one after the other to display the rooms and the data is organized accordingly for each jump with indexed addressing. This way with several sub kernels layed out and indexing for the data that is needed for that part of the room, then many things can and will be reused over and over again, just rearanged for each room and the data they pull can be diffrent depending on the indexing. Along with the indexed sprite data and flickering of sprites in the mix. Just have to organize page breaks at the right locations during the displaying process and have them more during v blank and overscan. and as few during h blank

Edited October 15, 2008 by grafixbmp

[roland p]

The graphics look really nice. It looks like it has more than 2 colors per line, while it hasn't, neat. The best way to find out if this works on an atari 2600 is to write some code, right?

[tokumaru]

The way I hope to do all of this is have a table in rom that is called up section by section for each room as it were in order so that the mini kernels can be organized as jumps one after the other to display the rooms and the data is organized accordingly for each jump with indexed addressing.

I think that the fastest way to jump from a mini-kernel to the next is using an RTS instruction, which takes only 6 cycles. Before rendering starts, you have to push the addresses (actually I think it's the address - 1) of the kernels for each section to the stack in reverse order.

 

I was planning something like this for a project, because it is even possible to push to the stack parameters for the kernels, such as the index of the background patterns and colors to use, the index of the object to reposition, and so on, that they can pull as soon as they have been called. You just have to be careful with the height of the kernels, so that all the addresses and parameters don't take too much RAM.

Edited October 15, 2008 by tokumaru

[Ben_Larson]

I greatly appreciate that. In your general opinion, with the 3 pf registers and the 2 scanline aproach along with the spacing of the objects in the background (i.e. grey the brown/orange) and the repeat of some of some of the register from left to right, should this give enough space for code that renders both missles at double height, player 1 sprites at double height and and single height player graphics besides the color changes?

Thanks in advance.

Using all 3 PF registers for the asymmetrical playfield, even if you're only displaying stuff on half the screen, isn't much faster than just displaying stuff on the whole screen because you still have to write zeroes to all 3 registers every scanline - it's 35-36 cycles (half screen) vs. 42 (full screen). So really you should try to use only 2 of the PF registers for the asymmetrical PF parts. Then you don't have to worry about writing a zero to the unused register. This method would cost 28 cycles per line...

 

Ben

[+grafixbmp]

The way I hope to do all of this is have a table in rom that is called up section by section for each room as it were in order so that the mini kernels can be organized as jumps one after the other to display the rooms and the data is organized accordingly for each jump with indexed addressing.

I think that the fastest way to jump from a mini-kernel to the next is using an RTS instruction, which takes only 6 cycles. Before rendering starts, you have to push the addresses (actually I think it's the address - 1) of the kernels for each section to the stack in reverse order.

 

I was planning something like this for a project, because it is even possible to push to the stack parameters for the kernels, such as the index of the background patterns and colors to use, the index of the object to reposition, and so on, that they can pull as soon as they have been called. You just have to be careful with the height of the kernels, so that all the addresses and parameters don't take too much RAM.

 

I like this thought and may use a limited form of it. Thank you so much tokumaru for your input here. I know who to credit for this bit of help now.

 

I thought about when using data for the colors to just use regular variables so that the stack doesn't get too big to cause an overflow. This way only one location in memory is always referenced for color data and such. Given that I was actualy thinking about placing about 6 bytes in memory to use for all playfield and background colors and call the ones I need for each screen. Then depending on which screens are displayed, change up the palette.

 

I decided to work on backgrounds first just because there is so much data to arange and display then work in the sprite graphics afterwards. And due to the fact I had so much trouble getting visual batari basic to compile. Crimson already is setup properly.

 

On a side note, as far as optimization goes, size is no object as far as ROM goes but for optimazation, in order to maintain a workable clock cycle count per scanline, this is paramount. I was however be shooting for a 16K size ROM. I may go as far as one of the specialty sizes like 24 K if possible or neccesary.

Edited October 17, 2008 by grafixbmp

[+grafixbmp]

I now have an organized model in the works but need to ask a few questions first. In reference to crossing page boundaries, does this include all page crossings weather it is in-line code or data pulls from memory to the registers when adding one cycle used?

I would assume both or all. Like, it is said that the fastest load and store is 5 cycles but with absolute indexing it is 4 for loads if within a page and more if a page boundary is crossed. With a 4k rom i counted 64 pages total so if I index my data on the page level only and I could do 4 cycles for calls or rather loads and storing would be 3 to TIA registers?

 

The idea is to have mini kernels and the data for thoes kernels incased in each page and not crossing pages then have the stack be organized to call the kernels I need when I need them. I also thought about just shoving the lines for sprites in the stack calls thereby eleminating the need for keeping track of scanlines with the x or y registers but then again I may redo this part. The levels are then created by building the sections up from organized data that is then just stored to the stack for each screen.

 

If I do 4 cycle absolute indexed loads of data and 3 cycle stores that is 7 cycles each. In order to save cycles I will put cycle intensive data in zero page. Plus with the way I hope to get this stuff aranged per kernel, some loads maybe immediate and stored to more than one spot. some may be done with LAX too. that way I can use the accumulator with another PF register or other TIA register, use y to index and later in the scanline reuse the data from before without having to load by storing x. each sub kernel will work with data diffrent but will have all needed things there.

 

How fast are load and stores from RAM? If quick enough, I can use this for the color palette. I look at having about 90 bytes of ram for game logic data cause the rest is used for the stack.

 

With the PF data indexed for the kernels, the index can be redirected to other locations and thereby reusing the kernel for that type of layout. The stack being used also allows the kernels and even the data to be reused for any and all the screens. This way the color palette can change from level to level and use the same kernels and sometimes the same data from previous ones.

Edited October 20, 2008 by grafixbmp

[roland p]

How fast are load and stores from RAM? If quick enough, I can use this for the color palette.

Loads and stores from RAM are 3 cycles, 4 when indexed.

 

I always look here: http://www.6502.org/tutorials/6502opcodes.html

Edited October 20, 2008 by roland p

[+grafixbmp]

How fast are load and stores from RAM? If quick enough, I can use this for the color palette.

Loads and stores from RAM are 3 cycles, 4 when indexed.

 

I always look here: http://www.6502.org/tutorials/6502opcodes.html

 

I already have this list printed off for reference. I would like to find a list I once had bookmarked but lost that looked alot like this but was for the TIA. can't seem to locate it.

I decided to place as much sprite data on 0 page as possible. mainly single pixel data and decided to use flicker of P0 for the whip/mace and simon. The missle will still be used as to keep some detail and know better where enemies are in relation to simon. I figure some software collision detection will come in good here. Could use some help on that part.

 

I will try to keep the items at 0 page as well just to save cycle space and if possible, candelabra all permittig that 0 page can hold it all

Edited October 20, 2008 by grafixbmp

[+grafixbmp]

I just about have the dynamics down of the display. The mini kernel system looks to work well. the actual jump from one kernel to the next takes just 8 cycles. To fall back into the current kernel for another run takes about 5. The kernels can repeat several times thereby keeping the stack lower where needed. The kernels can even change data they point to as to change the PF data. The rooms are consturcted from data from several of the 16 pages from each bank. Smilar data and kernels are grouped together in each page. I think I can have atleast 1 and a half to 2 full levels in each bank. And since overhead things like cut scenes, title and intro sequence are simple enough, they can be on the same bank. The one thing that I may have touble squeezing in is the sound. I have a crude system rigged for collision and process. I also thought about using sampling of the collision registers several places on the screen to know where simon is and thereby how to act in relation to his current condition.

 

One problem I am having though is using my registers and counters properly so as to keep correct track of things. I wanted to use the x for indexing the PF data and was thinking about using y for cycling through the kernels multiple times but then I realized I really need Y for sprite data scanline counting and such. I just need to be able to use a branch for breaking from a repeat of a kernel so control can go to another kernel. Possibly the timer would be perfect for this and the Y can count scanlines for P0. I was going to, to a point, hard code the enemies into the standard kernel routines and have simons kernel section be dynamic enough to slide between kernels. Of course alternations between sprites happens during several times across the screen, this can't be helped within 2 scanline space an HMOVE is done. However, Nomore than 2 flashing out of one player sprite will happen at a time or every 2 frames.

 

Candelabra are hard coded into the kernels where they are needed. Cause in several places, the space invaders tricks for collision are used but modified to fit the situation. The hardest part is counting for everything that is used per screen and for everyother screen.

 

I also decided that regardless of what any sprite or playfield looks like, all vertical scrolling will be at 2 scanline increments as is how all kernels are precieved except for simons section which has fetches every single scanline but repositions every 2.

 

As far as controls go, I had a question for everyone. Can you do without crouching and using the mace or whip? I can use this for secondary weapons instead.

 

<--- ---> Left and right for movement

 

_ _

|\ /| Up/left up/right for jump at angles OR if next to a ladder you will climb

 

(*) Button in any direction except down uses whip/mace

 

|

\/ down crouch

 

|

\/ (*) down and button use second weapon

 

Are these controls to everyones liking?

If not, what other methods would be better?

 

I could keep the original as crouch and then use whip

 

and

 

push button first then crouch before whip is gone for secondary weapons

 

Need some input here. Thanks in advance.

 

Summary:

 

So far these are my statistics of the ROM.

 

All PF graphics are 2 scanlines deep.

 

Not all of the PF registers are reloaded for the right hand side for ANY scanline but can be diffrent from one scanline to the next (every 2) hence the mini kernels

 

all sprites drawn with player 1 are 2 scanlines deep.

 

all sprites drawn with player 0 are 1 scanline deep.

 

all places where missles are used are 2 scanlines deep.

 

All sprites move by 2 scanline increments verticaly.

 

Movements of all sprites happens no less than 2 framees at a time which allows more code on even frames that is diffrent from odd frames.

 

Music or audio info can change every frame

 

color changes happen every 2 scanlines for allitems

 

With these bylaws in place other things are allowed

 

Simon always has either a whip, short mace or long mace he can use anywhere.

 

Either none or a single secondary weapon can be used. If applicable, a double of the secondary weapon can be used.

 

Up to 2 enemy types will be on a screen at once not including PF obsticales.

 

All candelabra are fixed positions for each screen (do not move).

 

Player 0 has one position for the entire frame

 

Player 1 can reposition several places per frame

 

The missles can be repositioned several places per frame but only one entity per frame.

 

When a candelabra is struck (as in 1) It drops an item and is displayed for a given time or until another is struch and the first disspears. Meaning only one item to collect on screen at any given time.

 

Maybe this will give a general overview of what gameplay will be like.

 

UPDATE: While working on some code I needed some sprites for the enemies. These represent the standard vertical resolution for 8 or 16 and 15 or 30 depending if you go by singles or doubles. Atleast the data to store them are the lower numbers TG!

 

The bats (red and blue alike) are made up of 3 frames and the gouls or zombies are 2. The bats also have the hanging frame (up-side-down)

 

Here ya go.

 

 

Updated some of the graphics and how they work. This arrangement allows for far less changes per scanline, more detail and a fully connected mace and whip along with unique color of the weapons. However this comes at the price of flicker during excecution. I also have added the black cat thing and am working on containing all these things in a concise set of code (super hard part).

 

The cat is double width and may be a bit bigger than you would think but it still looks rather good for low res.

 

 

Edited November 5, 2008 by grafixbmp

[+grafixbmp]

There seems to be too much overhead for staying in kernels by looping back into them. I may need to take a wider approach. If I use variable size kernels then I can potentialy save but in other sizes I may not. 8 is the magic number however this may hinder thingswhen displaying sprites. I could possibly do kernels for 2, 4, 8, and 16 scanline areas some other sizes for sprite areas like candelabra and enemies.

 

I now have all regular enemies done for the first level and am trying to rig the data so that only changes are stored hoping This can save lots of space. I also am tinkering with display and interactions of sprites now. sortof doing sprites and playfields stuff side by side and tweaking both to fit together as best a possible.

 

The only enemy I have not done is the vampire bat. Actualy the only sprites I don't have are the vampire bat, crystal,stopwatch, and some more of simon.

 

I also have been toying with the HUD and have a basic layout down solid. With some heavy 6 score stuff.

 

Here are most all the sprites I have so far.

 

I can even display the scores as they appear when you collect things only.