There are some nice pictures at
http://www.msx.org/photo20gal44.html
But has this project ever been released ?
Login or register to post comments
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.
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.
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.
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!
Don't you have an account yet? Become an MSX-friend and register an account!