There are some nice pictures at
http://www.msx.org/photo20gal44.html

But has this project ever been released ?

It cant be done properly on MSX - at least for now; sprites would have to be too small to pull it off; in some levels you have the player + enemy + sword(s) + "that razors that cut you in half". that would take too many sprites (more than 8 per line) on MSX.

And I didnt even thought about how to store the hundreds of frames prince uses on the player (yes, more than 200 frames!)

That, btw was only a test I made showing dynamic pattern changes on the sprite, to simulate the "sprite passing below graphics" (or: prince walking behind columns); although fast enough to make the game, the reasons above put me off doing it.

Of course, if you change to MSX1 it can be done (see prince on spectrum), but not with the quality I had in mind...

but maybe this will change... last week I did a small test trying to make tmnt arcade on scr5 (NES graphics quality) and almost got it working at a decent speed... so if I try the same technic on Prince it may actually work...

but for now I have some other projects I am working on.... news soon

Why not use normal gfx? Just backbuffer and copy the stuff into place. There's really not that much action going on in Prince of Persia anyway, so it should be more than fast enough. You could use VRAM for the game graphics, and store all the 'sprites' in main RAM. It would prolly require more than your average 128kB RAM, but still, it's a game that would be worth it.

Just the opposite! First the player moves very quickly (take a look when you run and jump), also in the later levels there are a lot of stuff going on at the same time...

And you cant use sprites for player and enemies.... would require too much sprites per line - just the player has a frame with width more then 40 pixels, which would use at least 3 sprites, from 8 per line on MSX2!

Then, if you want to get a really colorfull char, you will use 2 sprites on the player, which will take 6 sprites, leaving only 2 for the sword and the enemy!!!!

It's a tricky thing to be done... but I think there's a way - using sprites for the player and shapes for the enemies; but then I have to create a small test-demo to see how it will perform speed-wise...

I've made a animation system using 'hardware' and 'software' sprites at the same time (we're talking OBJECTS here, no matter what type) for the Nosferatu and Fubsy game engine. Test result were pretty ok. Don't expect super speed when dealing with 'software'sprites (you know, them 'normal' gfx thingies) but it'll do if you use some extra tricks. might wanna checkout the old parallax website for some hints.
but for high speed animation, sprites are THE thing to work with.

i don´t understand, why one should use sprites for player + enemy + etc + etc on making MSX(1) conversion

You do worry too much about using sprites.

Player can be made from sprites of course

I haven´t played Prince of Persia for a long time, but I have played it on my amiga and I do remember that enemy guards just stood still where they were, and when player got near enough they woke up and approached fast!! ie I am sure you can use characters to animate enemy guards and same thingy to that horrible razor which cuts human being to human beans....
I think there is no problem if enemy don´t move at one pixel accuracy, it is MSX version, NOT amiga or pc version.

I also think, that you think too much about that problem how you can hide player and enemy behind the columns, it is of course nice effect, and may cause nice stress to player when you can´t see what´s going on during fighting, but still I think that it is not that important to gameplay. I think you can forget that problem, or then, invent simpler way to do that, that if player hides behind column, you just do same as Konami did, hide player sprites, of course that does not look as nice as sprites do disappear before player is behind the column or sprites disappear after he is standing "behind" the column, but I think that is minor "problem" me thinks.

And same can be done to enemy.

Quote:

Just the opposite! First the player moves very quickly (take a look when you run and jump), also in the later levels there are a lot of stuff going on at the same time...

Well, you said there were over 200 frames for the player. Assuming a tiny and fixed size of 16x32 pixels, that would only barely fit in VRAM. Hence the suggestion to put the tiles in VRAM, and the player in RAM. The tiles are almost always solid and will have even X coordinates, so you could use highspeed copies and have a speed boost there. The player frames will always be logical copies, so the speed difference between RAM an VRAM copies is much less. Apart from that, you would be able to mirror the player sprites by using an LMMC transfer and save yourself 50% memory.

How quickly the sprites move is of little importance in this case. Prince of Persia usually has only one sprite on screen, sometimes 2 or 3. Assuming you go for 24x40 pixel sprites, you'd be looking at 3x24x40 = 1440bytes at HMMM speed to erase the characters, and another 3x24x40 = 1440bytes at LMMC speed to plot the characters on the screen again. That would put it well within the 30fps range, with 3 big sprites on the screen.

Quote:

And you cant use sprites for player and enemies.... would require too much sprites per line - just the player has a frame with width more then 40 pixels, which would use at least 3 sprites, from 8 per line on MSX2!

Of course I didn't mean hardware sprites. They have little to no use, and should just be turned off completely to gain some extra command speed.

Quote:

Then, if you want to get a really colorfull char, you will use 2 sprites on the player, which will take 6 sprites, leaving only 2 for the sword and the enemy!!!! It's a tricky thing to be done... but I think there's a way - using sprites for the player and shapes for the enemies; but then I have to create a small test-demo to see how it will perform speed-wise...

Well, I've done a lot of tests myself for a game we were once making for the FutureDisk (Contra II), and even with five 24x40 pixel sprites on screen, the game wasn't even that slow. It was of course nowhere near 60fps, but on MSX there really is no way to get and big full-color sprites and a high framerate. It's either one or the other...

Contrary to your last statement, Core Dump did quite well, thankyou

Coredump is *nowhere near* 60fps. It is however the perfect example that 60fps is not needed to make for a great game.

So, I guess that no MSX1 version, huh? Too bad!

it´s a shame, as those screenshots look much like MSX(1) ! Colours are the same too!

Hey this thing has been ported to zx spectrum any chance we see an msx version?

I'm agree with MäSäXi on his game planning comments. For Prince of Persia (of course, MSX1), I would spend the whole sprite thing for the main character and make backgrounds and enemies with patterns... well, this will cause 8x8 moves for the enemies (they do not move that smoothly as the prince), but you'll still have the smooth moves for the main character with full sprite color power and some decent enemies and backgrounds. We can take Yiear Kung fu as an example of relatively big starring character using sprites and relatively big enemies using patterns. And I'm sure those 200 frames can be somehow reduced (removing some frames here and there, mirroring the left position using the game code...)

How on earth did they do it on the much limited spectrum?Did the use all of 200 frames?Msx is much more powerful than spectrum 128+.Ula of spectrum can't be compared to the msx video hardware.Msx is lights of years ahead.I wonder what is the problem and it hasn't been ported yet

I guess it was not cheap those days to make a proper MSX version for the game, and porting from zx to msx is not easy sometimes, as video memory is located in RAM on zx spectrum, allowing big and fast transfers (RAM to RAM)... a "direct" MSX port usually results on using the same routines (but RAM to VRAM), slowing down the thing A LOT...