Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Harvey ! (Registered 2024-11-25) You are not logged in - nap
CSDb User Forums


Forums > CSDb Discussions > Prince of Persia for Commodore 64/128
2011-10-09 19:28
Mr. SID

Registered: Jan 2003
Posts: 424
Prince of Persia for Commodore 64/128

So the time has finally comeĀ…

I'm proud to announce the release of Prince of Persia for Commodore 64/128 (PAL and NTSC).
The game will be available as a free download on the 16th of October 2011.

It will ship in the form of an EasyFlash .crt file. Any EasyFlash compatible cartridge will support the game (this should include the Chameleon and AlienFlash systems). VICE 2.2 and later also features EasyFlash support.
There is no disk or tape version (and there might never be one).

I will release more information during the coming week and will start to publish detailed documentation of the
development of this version (including my reverse-engineering work of the Apple II version) after the release.

In the mean time, here are some screenshots to get you psyched. I welcome all your comments and questions.





 
... 75 posts hidden. Click here to view all posts....
 
2011-10-10 11:10
Mr. SID

Registered: Jan 2003
Posts: 424
Quote: I found the POP source code documentiaon on Jordan Mechner's homepage and the game seems to use the full 128kb of ram. Would still be interesting to look into the possibility to sequeeze the game into a stock c64 and a 1541 floppy drive.

There's someone trying to do that, but I have no idea if it possible with his approach.
2011-10-10 13:17
STE'86

Registered: Jul 2009
Posts: 274
to have any chance of fitting the game into 64k, one would have to rewrite it to use charset instead of bitmap based graphics.

feasible certainly, but definitely not just "a mod". one would also find that all the background graphics would need to be redone to align to byte boundaries. and the animation frames would probably need to be evaluated with a view to stripping out extraneous animation data. (the excessive 15 frame animation to drink a potion springs to mind right away)

oh and i would take Mechners memory breakdown with a pinch of salt, as i seem to recall it claiming 48k for code. 48k in an 8bit is one hell of a lot of code for what amounts to a platform game.

Steve
2011-10-10 13:30
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: to have any chance of fitting the game into 64k, one would have to rewrite it to use charset instead of bitmap based graphics.

feasible certainly, but definitely not just "a mod". one would also find that all the background graphics would need to be redone to align to byte boundaries. and the animation frames would probably need to be evaluated with a view to stripping out extraneous animation data. (the excessive 15 frame animation to drink a potion springs to mind right away)

oh and i would take Mechners memory breakdown with a pinch of salt, as i seem to recall it claiming 48k for code. 48k in an 8bit is one hell of a lot of code for what amounts to a platform game.

Steve


Indeed... as Mr. Sid pointed out to me one day on IRC: The tiles in the original graphics are 63 lines high, not 64, making char mode and $d800-colorram a living hell on the C64.
2011-10-10 13:33
Mr. SID

Registered: Jan 2003
Posts: 424
The 48K of code is quite accurate, but it includes tons of tables for all kinds of purposes.
Don't have the exact number here, but if you want to count just the actual code it's somewhere in the neighbourhood of 32K.
2011-10-10 13:52
STE'86

Registered: Jul 2009
Posts: 274
yes but when u actually look the game dispassionately, apart from the painters algorithm and the smooth animation, it doesnt actually do a fat lot does it?

i would say that many other c64 games have to keep track of an awful lot more data and don't use 32k to do it.

also on the amstrad forum i was told that cpc version runs on a 64k machine and it's graphics use alot more space than a 64.

Steve
2011-10-10 13:57
Skate

Registered: Jul 2003
Posts: 494
this news alone should be increased EasyFlash (and possibly Chameleon/AlienFlash etc.) sales. at least, i just ordered 5 EasyFlash cartridges for me and my friends in my neighbourhood. Actually, I would order a Chameleon if I didn't have a 1541U2. I just left my Chameleon order to a new reason. :)
2011-10-10 14:13
Slator

Registered: Jan 2002
Posts: 274
Quote: Could have, would have, why bother? The crackers need work too so that they not only train and fix SEUCK games! :D

jazzasser: could be that you should stop typing and finnish off EoB instead ? ;-D <just an idea...>
2011-10-10 14:20
Mr. SID

Registered: Jan 2003
Posts: 424
As far as I can tell from Youtube videos, the Amstrad version has only half the animation framerate (they skipped every other frame) and doesn't use double-buffered drawing.
I can't stand to look at it for more than a few minutes. :)

But there's a lot more to it than just screen drawing and a bit of animation.
There's a detailed collision detection system which is quite complicated due to the many different movements the player can perform (lots of special cases that simple jump'n'runs don't have to worry about).
Then there's configurable enemy AI which gets progressively harder and not just because it has more hit points in later levels.
A good chunk of code is also dedicated to the various animated tiles, gates, chopping jaws, falling floors, etc.
Then there's a cutscene player using the game engine, a script engine to drive the animation of NPCs during the game (for certain one-off situations like the shadow man), and many other Apple2-specific bits, floppy code, keyboard and joystick scanning, music/sfx player and so on. Because the hardware is so primitive, these things are unusually complicated. Reading the current joystick direction or playing a beep on the speaker requires timed loops and stuff like that. We C64 coders are a bit spoiled in this regard.
2011-10-10 14:29
Oswald

Registered: Apr 2002
Posts: 5086
Quote: yes but when u actually look the game dispassionately, apart from the painters algorithm and the smooth animation, it doesnt actually do a fat lot does it?

i would say that many other c64 games have to keep track of an awful lot more data and don't use 32k to do it.

also on the amstrad forum i was told that cpc version runs on a 64k machine and it's graphics use alot more space than a 64.

Steve


Great news! I agree that 32k of code sounds a lot, but it does probably 10x times more stuff than we can think of at the moment. :)
2011-10-10 14:42
Mr. SID

Registered: Jan 2003
Posts: 424
I just did the calculation for the upper 64K bank (which contains the whole high-level game engine) and there's ~29K ($730d) bytes of actual code, not counting tables and other data.
The other bank contains the low-level bitmap drawing and floppy routines, so that adds another few KB.
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
LordCrass
Guests online: 83
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Wonderland XIV  (9.6)
10 Comaland 100%  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Libertongo  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Morph  (9.5)
9 Dawnfall V1.1  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Nostalgia  (9.3)
5 Triad  (9.2)
Top Coders
1 Axis  (9.8)
2 Graham  (9.8)
3 Crossbow  (9.8)
4 Lft  (9.8)
5 HCL  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.062 sec.