299 replies to this topic

[grafixbmp]

It has been a while since I have had any inspiration to create something new for atari 2600. I've either hit a road block or lost intrest in past projects but that doesn't mean I won't ever go back to them. But since my job upgrade and new home, I now have some desire to jump back in to game creation for 2600.

I have been toying with the idea of a classic game which started on NES but also bounced over to the old IBM pc, commodore 64 and amiga. In recent years it has even gone moble (phone that is). I don't intend to get pretty with it or too busy on the screen but if I can find a viable and efficient way to do some simple full screen side scrolling, I think it may be possible and rather playable. I had thought that all levels might be too much for ROM but after watching walkthrough videos of speed runs, THere doesn't seem to be too aweful much but rearangement of backgrounds and platforms. Like I said nothing too pretty just playable and hopefully fun.

Introducing Castlevania 2600. I have been working on laying out and delegating sprites for certain things. But not a whole lot further.

So far player 0 is simon. and variations of missle 0 and a duplicate of player 0 with diffrent sprite data are the whip and mace. The missle 0 is also used for most if not all of his alternate weapons. Player 1 falls under 2 things. Starting with candelabras. This allows 4 levels of fixed locations horizontaly for candelabras to be located. Their sprites never change so that makes part of it easier when duplicating sprites upto 3 of course. Enemies fall under the second. They usually stay on platforms and ground in between Candelabras horizontal locations. If however they go across the plane of candelabras, they automaticaly take priority. Missle 1 is used for projectiles from enemies. Some enemies actualy use parts of the playfield and inturn fire projectiles using the ball. The ball can also be used for small medusa heads. There are other possibilites but these are a few.


I thought about what data storage and retrival might be like and have a few ideas but which may be a wrong direction to go in, could use some input here. If candelabras are a fixed distance from each other and only 3 can be on any row then each row can be represented by groups of bytes in ROM which is loaded into ram when that area is being displayed. Each row has it's own group totaling 4 rows at any given time. For an example, say that each row is represented for a full level by 16 bytes a piece. Each bit represents a possible candelabra. Obviously a 1 is a candelabra a 0 means none. Each row extending from start of level to finish with 16 bytes gives 128 candelabras possible locations for a full level. This should be plenty but the number of bytes for each level could be changed. But as far as the candelabra go this hits a total of 64 bytes for storing raw candelabra data. Items from them is a diffrent matter.

the big hurdle to overcome is asymetrical playfield that scrolls. There won't be alot of resolution verticaly. Most areas are low pixel height except for significant detail where something has to stand out from the rest which is only in specific locations like dragon skull canons. There shouldn't be alot of color variations to the playfield graphics.

I now have some help with the game making process; unlike past projects, so hoping things go well, there may be a demo in the future. Anyone is welcome for their wisdom and insight if they feel this could be a viable project.

I also have started porting graphics over and hope they look good enough for a player to enjoy the game. I will append this soon with some images of characters I have came up with based from the originals.

I now have some simple layouts of simon with all 3 verions of his main weapon

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

[Robert M]

Why not eliminate the side scrolling and use static screens instead?

[grafixbmp]

Why not eliminate the side scrolling and use static screens instead?

I had considered that and may just go that route if no form of side movement can be viable. It is crazy that the original sidescrolled and staticaly moved in vertical directions compared to the 2600 which can verticaly scroll but with tons of difficulty going horizontaly. lol

I will be up for the static frames if a few others would like to lend a hand. The other cool thing would be to try to get the movement of simon close to the original.

[roland p]

I know the MSX 2 version does not scroll: , so that's no problem. Although it would be very cool if it did scroll, so why not try it?

The playfield of the MSX version just looks like a 16x11 tile grid. the atari 2600 version will probably be something like 20x...

if you create an kernel that could draw those tiles, then scrolling would be only moving 1/2 tile.

EDIT:
The scrolling will probebly look strange when Simon walks up the stairs. The movement of Simon is in a perfect diagonal line, while the scrolling is in big steps

Edited by roland p, Fri Sep 26, 2008 10:00 AM.

[grafixbmp]

I have decided to not have scrolling. But I may have vertical scrolling which goes up only so that if you fall off you die. However if you are on platforms or stairs, you can scroll down. I also decided that if multiplexing allows, to have the "II" tile but not the "III" tile.


All items will have to be multiplexed from player 1 so that if an item is shown on screen, it will have to be gotten before going to another candelabra. Otherwise, the first will vanish unless is is a neccesary item that must be got.

v heart
V large heart
!> Upgrade
X cross
# holy water
$ money bag depending on the color will indicate it's value
+ holy cross
& potion
II times 2
- dagger
/^ axe
@ chicken
O next level
ii candelabra

With this crappy representation of symbols and text, this will show all things I hope to have as things/items you can get. Now I just need to do the graphics for them.

On a completely diffrent side note, it might be cool to have a new type of game playable on computer where all things in game are represented with ASCII like the art form just like I demonstrated up above. Imagine ASCII Castlevania, ASCII Mario Bros or ASCII Zelda. LOL just a passing thought.

Anyway I have ripped some sprites from castlevania (or rather downloaded them from a sprite site) and redid some of the sprites for the 2600 version. What do you guys think sofar?

[roland p]

Anyway I have ripped some sprites from castlevania (or rather downloaded them from a sprite site) and redid some of the sprites for the 2600 version. What do you guys think sofar?

The sprites look nice. I wonder what the playfield would look like. I don't get the ascii representation, ascii is not one of the the Atari 2600 strenghts

Are you going to write the game or are you looking for someone to write it? (I'm not volunteering as I'm completely dedicated to Ballblazer )

[grafixbmp]

Anyway I have ripped some sprites from castlevania (or rather downloaded them from a sprite site) and redid some of the sprites for the 2600 version. What do you guys think sofar?

The sprites look nice. I wonder what the playfield would look like. I don't get the ascii representation, ascii is not one of the the Atari 2600 strenghts

Are you going to write the game or are you looking for someone to write it? (I'm not volunteering as I'm completely dedicated to Ballblazer )

The only real things I would like help with are Music and sound FX, maybe some help with fiting dynamic (using term loosely) sprite code together, and some help optimizing. Trust me when I say tons of optimizing.

The task at hand would be to create graphics to work with and displaying diffrent senarios concisely on screen. When I know things will look good and work porperly then comes the task of aranging level data in as little space as possible. I will work on the first level initialy being it is simplest. I know over time I will probably be asking tons of questions so that will help the most. The biggest thing I will thrive on is second opinions and third party perspectives. That way I can get other peoples ideas and input on how to aproach certain problems along the way.

Thanks for asking though. I atleast want to get some code started here sooner or later.

And the ASCII thing was a non Atari related side thought. Like a remake of any general popular game where ALL graphics in game are represented by ASCII only. though in color though where each ASCII character is its own color.

[tokumaru]

Very cool! Strangely enough, just the other day I was thinking about which of 2 games I would get the inspiration from, for a 2600 game. One of them was Castlevania, but I ended up choosing the other one. I had settled for static screens from the beginning though. There's just not enough time to update sprites and background and still have them look good.

I hope to see more of this project, the idea is very good, as are the sprites. Please keep working on this!

[grafixbmp]

Quick update: I finished a rough draft of a 3 frame animation on simon done in full 2600 supported graphics and it may be a bit jerky but it is an awesome start. Hope ya like it. I will try to code some stuff later to get the color bands and display the graphic animating when the stick is pushed. Movement will come later. All color bands line up the same for every frame.



This is the 2600 version. And for comparison, here is the NES version



both have the same animation speed and amount of frames.

This one is about the same but with true Atari 2600 aspect ratio.

Edited by grafixbmp, Sat Sep 27, 2008 11:49 AM.

[haroldoop]

On a completely diffrent side note, it might be cool to have a new type of game playable on computer where all things in game are represented with ASCII like the art form just like I demonstrated up above. Imagine ASCII Castlevania, ASCII Mario Bros or ASCII Zelda. LOL just a passing thought.

Something like that? Fable of Griselda

[grafixbmp]

On a completely diffrent side note, it might be cool to have a new type of game playable on computer where all things in game are represented with ASCII like the art form just like I demonstrated up above. Imagine ASCII Castlevania, ASCII Mario Bros or ASCII Zelda. LOL just a passing thought.

Something like that? Fable of Griselda

Very slick. I like it. Now just some other games need to join ranks. I want that zelda game though!

On a side note, I have a few simple ideas for playfield graphics but would like some input from others about the backgrounds, colors and designs. The only playfield things I came up with was the Dragon Skull cannons.


If anyone wants to atempt the first levels music with the first channel leading and the second being used for either music support or pricussion, and sound effects. The SFX would take priority over music only for the second channel.

[grafixbmp]

I now have an animation of simon with the first stage mace and it looks great. I have it working on a combination of 3 frame groups followed by the standing still sprite. The first frame is of a normal player sprite with a modulated missle sprite preceding the player sprite. The missle is alterd every other line for better programing room. The width and location are altered to give a whip looking mace. This is done for the first 2 frames. The third is an idea I had where the missle now comes after the player 0 sprite with the width on at a 4 color clock width. While this is taking place, the player itself has had doubles turned on prior to this and before the second copy is displayed, the sprite is changed to display the mace ball. The final frame is of the previous walking animation where he just stands still. I hope to have this part done after I get the walking animation done.

The regular whip is done just like this but the long mace is increased in distance by doing player 0 with doubles but using tripple width and going from a 4x missle to an 8x missle and positioning it every other frame 8 pixels shifts one cloase to simon and the other close to the whip . I hope I have memorized the TIA's abilities correctly.

Edited by grafixbmp, Wed Oct 1, 2008 10:25 AM.

[Random Terrain]

This is looking pretty good, but when do we get to start licking the 2600? Do we lick it at the same time or do we take turns?

[grafixbmp]

This is looking pretty good, but when do we get to start licking the 2600? Do we lick it at the same time or do we take turns?

That is Simon's job. He will lick it with his mace.

[tokumaru]

I hope I have memorized the TIA's abilities correctly.

Well, memorizing all the capabilities doesn't really mean you'll be able to implement a particular combination of them in your kernel! =) Changing the graphics of the player to draw the mace could be very difficult, with the player moving around and all. Hope you can pull it off though! =)

[grafixbmp]

I hope I have memorized the TIA's abilities correctly.

Well, memorizing all the capabilities doesn't really mean you'll be able to implement a particular combination of them in your kernel! =) Changing the graphics of the player to draw the mace could be very difficult, with the player moving around and all. Hope you can pull it off though! =)

I was thinking that when the mace animates, he does not move until it finishes animating. But that might not work either. I was going to try to get a demo finished here in a few weeks (LBW) of him animated for walk and get him moving too. The rest I will have to shoot from the hip.

[tokumaru]

I was thinking that when the mace animates, he does not move until it finishes animating.

Even though he doesn't move while attacking, he does attack while standing at various X coordinates, that's what I meant. This means that the exact moment at which the graphics must be changed varies depending on the X coordinate of the player, and that will be very hard to accommodate considering that there will be other tasks to perform on the same scanline (so you can't just use a loop to wait for the time to switch graphics).

[grafixbmp]

I was thinking that when the mace animates, he does not move until it finishes animating.

Even though he doesn't move while attacking, he does attack while standing at various X coordinates, that's what I meant. This means that the exact moment at which the graphics must be changed varies depending on the X coordinate of the player, and that will be very hard to accommodate considering that there will be other tasks to perform on the same scanline (so you can't just use a loop to wait for the time to switch graphics).

I was thinking about something a bit diffrent than just a loop. Depending on where simon stands or more exactly when he is to start being drawn, switching to an unrolled kernel subroutine that accomodates enemies as well as the animations of simon. The whip only has to start one pixel behind the player0 sprite then it's position is altered every other scanline horizontaly. This happens for several actual frames of the first and second main frames of the aniamtion. The 3rd is simpler where the missle is only in one spot and the duplicate sprite has data drawn for 6 scanlines where once it is done then the player one sprite is single again. The offset value for horizontal positioning is what is changed every other scanline like for the first 2 animations to accomplish the displaying of the mace behind simon. For the other direction another unrolled subroutine preforms it in the opposite direction This time having dupicates on for the third frame repostioned before the first frame of the third is started but the first duplicate one is blanked until the mace is to be drawn. Something like that.

Besides the horizontal position changes constantly in space invaders and they are changing images too. And there has been a horizontaly moving 48 pixel wide image demo made before (not sure who did it). I only need to change a single byte during display of this instead of 4 in a row like thoes.

Edited by grafixbmp, Tue Sep 30, 2008 2:12 AM.

[Ben_Larson]

Well, memorizing all the capabilities doesn't really mean you'll be able to implement a particular combination of them in your kernel!

Yeah unfortunately asymmetrical playfields are sort of a killer in terms of CPU usage. A full-screen asymmetrical playfield will take at least 42 cycles per line by itself (out of 76). Comprimises could be made though: could just do a 32-pixel wide asymmetrical playfield in the center, which would only take 28 cycles. Also you could draw the playfield every other line (blanking it out on the odd lines) and use double-height sprites. I haven't done all the calculations, but this might be the only way to get the color sprites and the asymmetrical playfield, as well as a ball or missile...

[Nukey Shay]

...or a self-modifying line kernal, which allows up to 10 transfers from anywhere in rom to hardware registers (potentially consuming nearly half of native ram temporarily, tho). In such a case, you'd use multiple variations of the looped routine that goes into ram and decide which of them to set up and branch to while less-demanding scanlines are being displayed...and leave the same way. The results could fool you that the display was created by a 2600.

[grafixbmp]

Well, memorizing all the capabilities doesn't really mean you'll be able to implement a particular combination of them in your kernel!

Yeah unfortunately asymmetrical playfields are sort of a killer in terms of CPU usage. A full-screen asymmetrical playfield will take at least 42 cycles per line by itself (out of 76). Comprimises could be made though: could just do a 32-pixel wide asymmetrical playfield in the center, which would only take 28 cycles. Also you could draw the playfield every other line (blanking it out on the odd lines) and use double-height sprites. I haven't done all the calculations, but this might be the only way to get the color sprites and the asymmetrical playfield, as well as a ball or missile...

What I was going to do was, depending on which scanline was being drawn, most if not all only use about 4 out of the 6 register writes or just leave on the first 3 fo a repeat. Basicaly a full completely asymetrical playingfield won't be used. The playingfield will most always be less than that.

Bottom line is not all of the screen is treated like an asymetrical playfield at any given time.

[tokumaru]

Besides the horizontal position changes constantly in space invaders and they are changing images too. And there has been a horizontaly moving 48 pixel wide image demo made before (not sure who did it).

I see... but those didn't have any background, did they? Maybe you could do it like Ben_Larson said, reduce the background resolution so that you have a full scanline to work on the player.

Edited by tokumaru, Tue Sep 30, 2008 11:15 AM.

[grafixbmp]

Besides the horizontal position changes constantly in space invaders and they are changing images too. And there has been a horizontaly moving 48 pixel wide image demo made before (not sure who did it).

I see... but those didn't have any background, did they? Maybe you could do it like Ben_Larson said, reduce the background resolution so that you have a full scanline to work on the player.

I will in a way do what he said but spread out over the entire screen. some bands across will be done in one way and others gaped in other areas.

Like above:

Basicaly a full completely asymetrical playingfield won't be used. The playingfield will most always be less than that.

Bottom line is not all of the screen is treated like an asymetrical playfield at any given time.

[grafixbmp]

As you can see, with this first screen and the playfield that is displayed, clearly some objects in the background are not changed from the left to the right but others are. I am hoping that this can aleaviate enough clock cycles to keep simon and the whip animations together. I intend however to keep the objects and enemies to double pixel height. Hoping once again that this will allow enough time for simon. I am thinking about mini kernels that are stuck together to form the terrain and the terrain data can then be reused to form ALL the levels in the end. Also keeping many of the terain parts chunky like you see below saved space in the long run for all the graphics for the levels.




Update: I have done the outside torches animation and colors true to the hardware (as close as possible) here it is.


I did one other animated variation that might be beter or worse. You guys decide.

Edited by grafixbmp, Fri Oct 10, 2008 9:37 PM.

[grafixbmp]

I now have a design schematic of sorts for all level design. Only upto 2 out of the 3 PF registers are allowed to be changed for any given line. As to which ones depends on how far down the screen and to which subroutines are used for the mini kernels. Here is the first sequence of screens for the game and I hope many will find this doable. I have great confidence in the abilities of the 2600 in accomplishing this.



Update: New screens. I needed to figure out exactly how the interior of the castle was going to lay out. I became happy with this design but would like some second opinions. once again I designed all screens so that only 1 or 2 of the PF registers need changing. I also have designed 1 screen, like the last in the first 3, to change color mid scanline. This part is around the red curtain and the window. I thought about having a small color table in ram that changes like a pallete to help alot with this.

Edited by grafixbmp, Tue Oct 7, 2008 9:28 AM.