LS_Dracon

I don't like to draw background graphics, anyway I did some tests converting the level 4 (yellow temple) to the atari 2600 graphics. Here is the result:

I'm not working on prince sprites because Le Geek still interessed to draw them. What I could do is create quick (and ugly) sprites as placeholder, with all frames and once Le Geek comes with new sprites, just change the graphic data. It's ok for you?

Ok. I've post all the sprites of the guardian I did. I need to check if I miss something. See, there's not much sprites. The trick is the recovery animation. These sprites is set right after get hit, attack and defense anim.

I think less... Some animation share common sprites. Another very rough calculation by head : Step,jump,run,fall,climb,drink... Each animation with about 10 frames = 60 The sword fight I think uses the same number of the guardian, about 35 And other small animations or sprites alone, really don't know here, let say about 15 sprites... 110 in a very very rough number. Nathan, join with me and Le Geek! Let's create a sprite team for this project! What you think?

Hehe... I post much you said about 1 minute ago in my blog About level design, it doesn't require much rom for draw one screen, I think about 24 bytes (1 per playfield) or using nibble reduce by half. Each level uses about 20 screens (more or less) 20x24 = 480 bytes per level, about 4k for the entire game. If I'm correct, we need 8 kb for the all levels and sprite data. On melody cart you have 32 kb free for use IIRC the unique situation of more than 2 sprite are prince-guardian-trap at same row. It's a rare case and like the original game, running at 12 fps, the flicker is not so terrible that is, you can flicker 2 or 3 times the object before set a new frame or motion. EDIT - Check the latest bin posted by Chris in this thread and you have a good idea how the game is going to be. The first level is done, only lack the prince animations/physics and the guardians.

Me too And the amazing is, althoug this game seems complex, it's fit perfectly the vcs hardware : - 2 Sprites per row, using both missile for sword or increase the sprite resolution. - Ball for falling bricks (my suggestion, don't know if possible) - Fixed screen, assimetrical playfield for level design. - Like the original, this game uses 1 action button only. Everthing flicker free! Ok sometimes there's a guardian and one trap at same row, and the flicker is necessary, but it's a rare case. The biggest problem on the vcs was the ram. However with melody cart it's no more a problem. The universe is conspiring for this game be real

Thank you, Thomas :)I post a new gif, to shows some of the guardians color scheme.

I've finished all the guardian sprites for the PoP project.This gif show more or less the final result. I have better sprites here, just not update them to the gif (it's quite boring). The animations are : 1 - stand, atack pose 2 - walking - 3 - Touché! - 4 get hit - 5 die with pain!The block animation (defending the prince attacks) is done also. Hm... I need draw the special death such split by half if the guardian goes to trap (that kind of "wall blade", don't know the name of that).The dead animation don't know if possible to look like that. It doesn't require a special color table for each frame, the trick is to move the sprite vertically (and the color must follow the sprite) see the example below, but I don't know if the kernal support this.Trust me, the animation looks even cooler in motion. These animations uses a static position and don't make much sense. Just for record, the grey pixels is a missile object, it share the same player color, you notice I use some pixels sometimes to draw the feet. I'm using another color to help me in the binary conversion. Get hit and die animation require a bit more work. What really matter is how they look in the real hardware, not in this gif.Feel free to post feedbacks, critics and others. I don't care if you say it's sucks, since you spot me what exactly sucks.

Congratulations!

I'm not trying to boost the game development, I just want to finish the sprites soon as possible because I need to work in my others projects. Although now PoP graphics is in top of my priorities. Don't worry, I know you have others projects too, all I want is see this project realised, doesn't matter if this will be done in 2011, at least the sprites can be finished this year. I'll retouch this guardian animation, the arm and elbow looks bad in some frames. I'll create one blog entry to show my sprites, and keep this tread for programming and others relevant posts about PoP conversion. In a very rough number, I think the game uses about 200 sprites, including background elements such torch, blocks and others. The character uses 17 pixels tall, 17x200 = 3400, plus title screen and others game graphics, 4kb for the graphics data is enough. Don't know much about the data for the levels design, but I think 32kb is enough for the wole game. Or even less. I now we have 32 kb free for use in the harmony/melody, so the rom is really no problem, even using rodoscope animation Maybe we can find some rom space for extra levels... Well it's too early to talk about it.

Finished the first guardian animation with sword. The missile is grey, I know the missile share the same player color, this help me to know what is missile pixels when convert to binnary. The animation is the guardian stand pose, fight pose and walking.

Hey another great news! First, thanks for GOD, cheats for the game! prince of persia DOS cheats Level select, background disable (for rip the sprites!) and others. Why!!! Why I never think to find cheats before! And some resources : All musics in midi : prince of persia midis All maps : PoP maps in png Le Geek, don't worry to finish the sprites soon, my first test I'll use the running, turning and jumping animation, already done by you. I'll be glad if you convert the "yellow" levels graphics (start in level 4, I think) because I'm bad to draw backgrounds, and I really apreciate your graphics style.

I'm from Brazil. Sorry the english mistakes... I'm never good to learn foreign languages... I'm the unique here that really code for the 2600, I'm feel like an alien at my own coutry In Brazil the most common computer in 80's was the msx, z80 based. This explain why there are many programmers codding for z80 (msx, master system), there are many brazilian games for this computer. 6502 processor is very obscure here. CCE (yes, the same who did pirate carts for 2600) had an apple 2 clone in 1981, this explain the knowledgement for graphic hacks. But this clone doesn't make sucess. Probably the guys who code MegaBoy are reminescents from this era, I really like to know who did it, but I have no information. I asked to Dynacom information about it, but they reply: "We not produce it anymore"... OH really!!!! Well I not "live" that era, I'm started to play videogames in end of the 80, so for me don't matter if the processor is z80 or 6502. My first computer was an 286 PC. Back to the topic. I recorded one avi at 60 fps. The torch animation changes every 5 frames, so the game run at exactly 12 fps. Check the avi atached. The animation will require a table, and the characters has more than 16 frames, so is necessary 1 byte per frame. Jaffar animation share common sprites, I think if we need to display one sprite more than 5 game frames (so, must to be 10 or 15 etc...) is better to duplicate the frame in animation table. Or create one code to uses 6 bits for the sprite pointer and 2 for the timer, but I think not worth.... The code will be bigger in rom usage than duplicate in the animation table. Not counting the Vblank time wasted. Just my 2 cents, I'm not trying to teach anyone. torch.zip

In my discover, we don't need the frame delay, as everthing run at same timer %CXXX CYYY C = coordenates, 0 for positive, 1 for negative Ex: 0001 1010 = Move the player 1 pixels right, and 2 pixels to up. 1011 0000 = Move the player 3 pixels to left, and no vertical movement. Yes, I will like to do, let me finish the sprite drawing first

Chris, the gravity also run under this rule. I've made a quick AVI demonstrate better what I'm trying to say. Note the prince animation and position is changed at sime time of the torch animation, using global timer. I don't know exactly the timer, but let's say every 5 tv frames, you change the animation and position, freeze the screen in 4 frames, then change the animation frame and position again. 5 frames / 60 = 12 frames per second, the game frame rate. Roland, yes! But I'm thinking how to implement this. I figure using 1 byte to send the X and Y coordinate, left nibble for X and right nibble for Y, I have 15 options for position shifting, enough. The problem is I need change between negative or positive (lef/right, up/down). I could set 1 byte for this, but reduce the position shift for at maximun 7 pixels. I need to see if there's an animation that move more than 7 pixels per frame (falling are the faster one I think), if not, I can use this. (The sprites are smaller than original, this means less pixels range to be movimented also). As all the changes happen at same time, is not required an individual timer for each object, turning the things a bit easier. Chris I could do this job if you want. Or... synchronized the animation and speed like a normal game, but the game will lost the "stop motion" looking. Edit : 1 byte per frame, if the run animation uses 6 frames, I need 6 bytes to move the character. It's a reasonable rom usage. I think I'll not require more than 150 bytes for all characters animation. PoPteste.zip

Yesterday, when I get the first guardian sprites, I discovered one amazing thing : This game is like stop motion animation! Is hard to explan, let me try.... I'm not talking about how the animation frames was created. I'm talking about global timer for the animation and position changes. Let uses the example of Pitfall. If you press left or right the character obviously run. The animation and speed are the same. Let's say, if you press the button, the character run faster. A good programmer will bost up the timer for animation, to keep animation and speed synchronized. Here's the point! I have 2 distinct things : Animation and motion speed. Don't care the animation timer, if I change the speed, the animation keeps the same. The character will run far, but the animation will looks the same. On PoP there's not a motion speed! The position changes by animation frames, and it's uses a global timer. I notice the guardian changes the animation frames at exactly same time of the flames in torch. And the prince moves under this rule too. It's a trick created by Jordan Mechner to give a illusion of a movie. And this is the reason that PoP looks like a movie! Here's a graphical example of what I'm trying to say. You see Jaffar walking in two rows. There's 2 frames of animation (legs in, legs out). The first row is like a common game motion, every "game" frame the character moves 4 pixels, don't care what animation frame the character is. On second frame, he moves 4 pixels to right, but still in the first animation frame. On the second row display how the characters moves in prince of persia. Note like the first row, Jaffar start in point A (white line) and finish on point B (yellow line) and in both is needed 4 frames to reach point B. The "speed" are the same. But in this row, Jaffar only moves when the animation frame is changed. And in every changes, he "jump" 8 pixels, instead 4 like the first row. And in PoP this happen under a global timer rule. All characters, animation and position, changes at exactly same timer. Dude it's Stop Motion animation! Hats off for Jordan Mechner! So you think it's bad, because there's is a brocken fluence. But it's masked by the huge number of animation frames, turning the motion smooth. Every frame must have own X & Y coordinates. I have plans to test it, but let me finish the sprites, first.

I asked about ball because I think to use this object as falling bricks. If ball is already used for the doors/gates, the flicker is required. Is not required changes in sizes, just an option for HMBL.

I know. I have plans to create one bin to test animation, and convert sprites to binnary. This kind of problem will be solved then. Here's how I can fix the problem in this sprite : PS: Chris, the kernel support ball object?

I thought about possibility o use missile, but I did'n know your kernel support variable missile size. For this sprite the missile must be positioned in back of the player, because an impossible 1 bit combination if displayed in front (see the yellow pixels). Assuming the missile is always positioned in front.

One frame from jump animation require 12 pixels wide. There's no way to fit in 8 pixels, with good results. My suggestion is use 2x wide sprite only for this frame. Below you can check how it looks. The first sprite is original, red area is the over pixels. Second sprite is double wide. It lost resolution, but the frame is displayed very fast and I think there's no problem (hell it's Atari 2600). Another possibility, to use a missile, I think double wide is the best solution. The code is something like (on jumping code) : lda #0 ldx #5 ;Frame to be scaled cpx FrameNo ;Assuming there will be an animation frame counter, is frame number 5? bne SetSize ;No, A = 0, set to NUSIZ0 txa ;Set double wide (x = 5 = 00000101) SetSize sta NUSIZ0

About 3 minutes per frame... I think all these frames I did in 2 hours. 1 hour yesterday (walking and stand pose), 1 today (the others). Like I said, when animated, I need retouch some pixels. Jaffar turn animation was the most hard do finish. I tried to scale down the sprites (the perfect value is 35%) but for me, this not help much, because first I need "clean" the scaled down sprite, removing wrong pixels, then convert to 2600 style. Is way faster for me already start on 2600 style from scratch, I think (and by the feedbacks), the result is good.

Sure. I don't like to copy, personally I preffer draw from scratch, but I'm trying to be most precise as possible. The trick I created now and it's very usefull, is a kind of axis under the sprites, this axis help me to move the pixels better. The process is - Run the game under DosBox emu, them recorder the screen as avi, then cut the sprites and paste into a bmp, clean background using photoshop and finally, using ms paint (for pixel drawing you don't need better) I draw frame by frame. You see I did the animation by steps, first I did the walking animation, then save each sprite as gif and create the animated gif, this is very usefull to know how the animation is going. I do some fixes, then create another animated gif to see if everthing is ok. Looks complicated but for me it's easy, I do this since end of 90's so I'm very familiar whit this process. Here's the example of Jaffar "sprite sheet" (all sprites in one image). Also you notice how many resolution I lost PS: this image contain the hourglass sprite too.

Don't want to flood the tread with my wip sprites, but this animation was hard to do. Jaffar animation from the intro, all frames is here. Poor Jaffar, all he wants is some fun times with the princess. I think if he buy flowers the thing could be more easy. He not make sucess with women, The problem is women aren't atracted by guys with pink clothes.

Thank you I'm using Le Geek's prince sprite as reference, it is 16 pixels tall. Jaffar is 1 pixel bigger, for me its a good size, the characters can't be much bigger or I have problems to draw the sprite, such the legs, note the Jaffar animation is very tight in the 8 pixels wide. Some sprites such climb need be taller becouse the arms, about 3 pixels, I think 18~19 pixels tall is enough. Or you say about the possibility to use double wide charaters, like the previous test? For me this size is good. I'm free for suggestions anyway.

Fixed the princess animation (alot better, mainly the hair movement) and Jaffar walking.