Re: Prince of Persia BTW, for anyone who's not aware: there's an existing but abandoned effort to port this game to Plus/4. GFW converted the entire cinematic intro: Prince Intro, as well as part of the first level: Prince of Persia. Movement is implemented, and the animation looks awesome, but unfortunately that's it, no real gameplay. Both of these were based on the monochrome PC version of the game.
What we're seeing here though is the real deal Can't wait!
Re: Prince of Persia I remember there was a Prince of Persia demo or something on Plus/4.. Somewhen Kichy also converted the Prince of Persia sets from Mega Drive or something.. Great to see, Prince of Persia by TCFS is also being done.
Re: Prince of Persia Yes!!! Now that's the kind of hype I'm talking about BTW I'm also really excited for this release (as well as the other stuff coming up).
Re: Prince of Persia @TCFS: But you certainly know, that a download link to the game would be much more satisfying to the good people here. Nonetheless, a fabulous job again. We are eternally grateful for having you! (kowtow)
Re: Prince of Persia Stay tuned, folks! In the rush of the party preparation, I forgot to send the final version to Csabo to publish. The game will be available to download in a few hours on the game profile page.
Re: Prince of Persia Amazing indeed, just like on PC Thanks TCFS master! I wonder if it's only me (and maybe some bad setting?) for whom it does not work in YAPE with 1551 emulation?
Re: Prince of Persia What a great release! It seems the +4 is the final machine for a port of this game among about 40 architectures. BTW I have added the proper entry to the Wikipedia table.
Re: Prince of Persia It's awsome! The details and movements are very precise. It's reallĂ playable (I only played it on PC long time ago). I think it's similar or better than that. thank you masters for this game!
Re: Prince of Persia TCFS, Csabo, Unreal Amazing release, friends! Thank you for all your work! Would you like to share some infos about the process of porting this game and the difficulties you encoutered?
Some details: the player has 200+ animation frames, and the enemies (guards, the skeleton and Jaffar) are additional 50+
Fighting with my usual memory limitations (8K for sprite buffering), the sprites are stored in compressed format, which provides the smallest memory consumption with acceptable speed. The decompression and mirroring of the sprite frames happens realtime for every screen redraw. This compression algorithm enables to display sprite frames other than rectangular form. Sometimes the player has weird postures (climbing over ledges with L-shape figure, etc.) and the sprite engine handles this situation well, focusing to draw the effective characters only.
Unlike the C64 version, the game is using character mode. The technical resolution of the screen is 320*204 pixels. (4 pixel lines are hidden on the top of the screen. The topmost character line of the screen reuses characters from other parts of the screen but for better visual experience I forced the TED to not show the top half of those characters.) The screen is splitted into 3 lines of block for the levels, but - due to the character mode - those are 64 pixels height instead of 62 as it is used for the C64 version.
There are 26 character lines on the screen. The bottom info line resides on the border area, which is the 26th row. Thr first (topmost) row is only a "half character row", showing only 4 pixels from the characters displayed there.
The cinematic into and cutscenes are rendered not using moving sprites but special "video player" which stores only the differences between 2 bitmap frames and updates only the changed area of the screen in a storage- and speed-efficient way.
The movement of the player is based on an "animation sequencer". The user is not directly controlling the player as usual in other games, but sending messages to the sequencer. It knows which particular frame of animation sequence should react to the direction inputs and where to continue the animation when that input is detected. It maintains a "decision tree" data structure which controls the fluid flow of the animation from one sequence to another. For example when the player stands still, the sequencer checks the joy for all possible directions, because the standing frame can be a start frame of various actions. Pushing the joy up will initiate the "jump up" animation sequence, which ends as "standing still". Pulling down the joy will start the duck animation, etc. When the duck animation started, around its 8th frame, the sequencer checks the joy still holding downward. When yes, the sequencer holds the frame when the user touches the ground. When the joy is released on that frame, it continues with the "standing up" sequence and that sequence also returns to "standing still" frame at the end. But when the player is touching a bottle on the ground during ducking and the fire button is also pressed, the sequencer is jumping to the "stand up and drink" animation. When the bottle is there, but the fire is not pressed it continues with the normal "standing up" animation and the bottle remains on the ground. This entire logic is stored in a declarative way using a fancy data structure in the memory. The main code of the sequencer is just around 200 bytes, but the data which describes the entire animation behavior is around 2K.
To maintain the fluid gameplay, I tried to eliminate the disturbing "loading" screens while nothing happens. The program is loading the next chunk of logic in advance when possible. For example when the player leaves the level the victory tune starts playing, but during the music play and the torch animation, the game loads the cinematic cutscene. When the music stops, the cutscene can start immediately. When the cutscene animation starts, the program is loading the next level in the background. While you are watching the animationd and listening to the music, the preparation of the next level is in progress in the background to reduce the wait time after the cutscene.
For better dramatic effect, the cinematic intro and cutscene music player is a "digi player" to be able to use bass frequencies which are not supported by TED for normal music notes.
Re: Prince of Persia Is it a secret? Those cheats were very useful for the PC games. OFF. @dLst IMHO the most impressive game conversion was the port of X-COM: UFO Defense for the Speccy.
Re: Prince of Persia The C64 port needs the flashcard, the Atari 800 and BBC Micro ports need additional RAM, but the C+4 port can run on stock hardware. It seems that only the Speccy port uses less RAM.
Re: Prince of Persia This might be an interesting technical tidbit: the music player in Prince of Persia is an improved version of the DigiSaw (first used in Defiance), used here for the first time. It's still 3 voices on a stock TED, but now the digi bass channel can have its volume controlled. This can be heard throughout the intro, the notes fade out smoothly (compared to the previous players, where the digi bass was either fully on or fully off).
Re: Prince of Persia Congrats, this version of POP is really fantastic! And that bass in the intro music! Epic! (the fluid intro animation, using a kind of lossless MPEG compression, also worth a note).
@Litwr Well, the ZX Spectrum version is much less pleasing to watch. No it's not the multicolor, but they have no background wall elements, just pure black, also the stones could have lighter and darker shades, like the Plus/4 version, but they simply went for the single color mode (as ZX Spectrum has always GFX mode on, they can select at any attribute a front and a background color). So I can say while they put a lot of efforts into the fluid animation, the gfx elements were not polished enough (although they could, it was not due the limitation of the machine)
Re: Prince of Persia @MMS Maybe they just did not have enough manpower, the team consisted of only two men: the coder and the musician. And they didn't have sources in 1995. By the way, I was wrong. The Speccy version needs 128K RAM, so it can't run on a standard ZX Spectrum 48K. So the only +4 version (like the original Apple II version) can run on a 64K RAM machine.
Re: Prince of Persia As @Litwr said, the C64 needs a flashcard, which i don't have. So dLst no comparison video. Except sombody can give me some footage of a real C64 or Apple II of the first level.
Re: Prince of Persia PSA: if you are using the STM version of the game, a new patch has just been released. This makes the game compatible with the previous firmware as well.
Re: Prince of Persia @George I tried VICE to run POP, it works. Just activate the Easyflash configuration option and attach POP.CRT - I used a file from CSDB.
Re: Prince of Persia Once again an incredibly cool conversion, and even on disk. On the C64, this was only possible with a cartridge image. The game is the main topic of our livestream on Saturday evening, July 13th, from 8 p.m.:
Re: Prince of Persia On the C64, this was only possible with a cartridge image.
Where does this idea come from? The fact that something was done in a certain way does not mean that it is necessarily the only way. A Plus/4 or a C16/C116 expanded to 64 kB is a more limited capability computer than a C64. If it can be done on a 264 series machine with floppies, in my view, it sure as hell can be done on the 64 with floppies, too. Elimination of floppy changes and, more or less, loading times is more probable as the basis of the decision to go with the cartridge. It improves gaming experience.
Re: Prince of Persia I know that. But it's still very impressive. They could have just developed a cartridge version for Emulators. But I'm glad it didn't happen. Whatever the case, I'm looking forward to report on the game in detail.
Re: Prince of Persia Very nice, works on 1551 without problems. Never thought this would be possible on Plus/4. Please go on with providing the scene with these supergreat ports.
Re: Prince of Persia First review articles on paper are coming: a XX|XX on RetroMagazine World 48, and a XXXX XXXXX XXXXX on Zzap! 13/98. Numbers speak by themselves.