tag:blogger.com,1999:blog-1155250278529986220.post9126044243911528111..comments2023-12-01T11:53:34.241-08:00Comments on Prince of Persia C64 - Development Blog: Part Six - Playing hide and seek with pixelsmrsidhttp://www.blogger.com/profile/11145154244292497777noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-1155250278529986220.post-47402062798404561392011-11-01T19:15:05.774-07:002011-11-01T19:15:05.774-07:00One query - the occlusion of the kid when he's...One query - the occlusion of the kid when he's on or near a left-facing ledge tile. Whilst walking toward the edge, he has to have priority but when climbing (or falling, probably from the opposite side) that same ledge should then have priority.<br />So, do you perform such masking based on the kid's animation frame or something?<br /><br />Or does the bounds check + relative positions that the animations have just take care of it anyway?Rybagshttps://www.blogger.com/profile/06219075103623549298noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-78202715286124451152011-10-31T20:18:13.887-07:002011-10-31T20:18:13.887-07:00@mrsid
I have three questions.
1. How to skip the...@mrsid<br />I have three questions.<br /><br />1. How to skip the levels by using some kind of a key? I am going to test converted custom levels.<br /><br />2. Could you please let me know all the differences between C64(Apple) and PC version have been identified? The compatibility issue may be minimized by some conversion algorithm.<br /><br />3. When floors fall down, the game speed is slightly slow down. Is this a bug or do you have some plan to improve it?starwindzhttps://www.blogger.com/profile/03285178901816683577noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-37233542546756331512011-10-31T08:40:56.862-07:002011-10-31T08:40:56.862-07:00@mrsid
PoP:C64 Launcher and custom levels pack hav...@mrsid<br />PoP:C64 Launcher and custom levels pack have been released on lemon64 forum. Current version is 0.2 and please feedback any comments.<br /><br />http://www.lemon64.com/forum/viewtopic.php?t=40024&start=0&postdays=0&postorder=asc&highlight=starwindzhttps://www.blogger.com/profile/03285178901816683577noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-12867085928922791352011-10-31T06:19:26.399-07:002011-10-31T06:19:26.399-07:00Nice!Nice!mrsidhttps://www.blogger.com/profile/11145154244292497777noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-60512611573676227272011-10-31T06:08:38.632-07:002011-10-31T06:08:38.632-07:00OK, here's a quick improvement to the masking ...OK, here's a quick improvement to the masking code:<br /><br />Omit the command sta CurrentMask+2,<br />and just keep the value of CurrentMask+2 in accu. Then, replace all those asl CurrentMask+2 commands by simple asl commands. The code gets 10 bytes shorter, and uses 27 fewer cycles (assuming CurrentMask+2 was in zero page).S.E.S.https://www.blogger.com/profile/15765976975599531194noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-40661037970842330012011-10-31T05:18:45.919-07:002011-10-31T05:18:45.919-07:00@mrsid
I think I just figured out the offsets of ...@mrsid<br /><br />I think I just figured out the offsets of each level banks by using the method and information you told me.<br />* 1st bank: 0x100d0 (3 levels)<br />* 2nd bank: 0x140f0 (3 levels)<br />* 3rd bank: 0x18110 (3 levels)<br />* 4th bank: 0x1c130 (3 levels)<br />* 5th bank: 0x20150 (2 levels)<br />(Total 14 levels which do not have the potion level.)<br /><br />There may be some questions after further development of launcher.<br />Regarding launcher, I did not know that you do not have Windows but I will send and share the modified version of each pop.crt files which have custom levels to you and other people.<br /><br />Thank you.starwindzhttps://www.blogger.com/profile/03285178901816683577noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-7340783533312436562011-10-31T05:17:33.270-07:002011-10-31T05:17:33.270-07:00This comment has been removed by the author.starwindzhttps://www.blogger.com/profile/03285178901816683577noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-54310132867064894862011-10-31T04:52:58.706-07:002011-10-31T04:52:58.706-07:00@starwindz:
1. Yes, 2304 bytes.
2. 14 level bloc...@starwindz:<br /><br />1. Yes, 2304 bytes.<br /><br />2. 14 level blocks in total, demo level is not included.<br /><br />3: Yes.<br /><br />4: Read this: http://ist.uwaterloo.ca/~schepers/formats/CRT.TXT<br />Each bank starts with a CHIP header. You have to skip 0x500 bytes after the first three levels to get to the next CHIP header, then skip 8KB past that to get to the next CHIP containing level data. There are always 3 levels per CHIP block, except for the last one.<br /><br />You should also be able to find each of the levels by searching for the the first few bytes of the PC data.<br /><br />I don't have Windows, so I won't be able to run your launcher.mrsidhttps://www.blogger.com/profile/11145154244292497777noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-36250135649286988592011-10-31T04:40:21.920-07:002011-10-31T04:40:21.920-07:00@mrsid
Unfortunately I could not figure out the lo...@mrsid<br />Unfortunately I could not figure out the location of the each data block where all level data located in the pop.crt. Several questions for this are shown as follows.<br /><br />1. The size of each level data block is 2304?<br />(I think the total size of Apple II level layout you mentioned before is not 2304. Is it right?.)<br /><br />2. The number of level data block is 15? Demo level is not included?<br /><br />3. The offset of the first level data block is 0x100d0 in pop.crt?<br /><br />4. What are the offsets of 2nd and other level data blocks? For examples, 2nd offset is 0x?????, 3rd is 0x????? and others.<br />I have figured out that the first three level blocks are in sequence but I could not find out the location of other levels.<br />I could not understand the concept of memory banks since I do not have much C64 hardware knowledge. Sorry for that.)<br /><br />By the way I am developing the prototype of PoP:C64 Launcher in order to load custom level data made by many PoP fans. <br /><br />Please see the following screenshot. http://i43.tinypic.com/2brzn6.jpg<br />Custom level launcher for PoP:C64 could be usefule for many lovers of PoP:C64 you have developed.<br /><br />Thank you.starwindzhttps://www.blogger.com/profile/03285178901816683577noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-71807615315042039922011-10-30T16:50:57.241-07:002011-10-30T16:50:57.241-07:00>And now I'm not gonna bother anymore...
I...>And now I'm not gonna bother anymore...<br /><br />I perfectly understand that :)<br /><br />But maybe somebody else will do that if you publish the source code at some point...?peterfireflyhttps://www.blogger.com/profile/05050847835479172236noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-57944655643514754672011-10-30T16:49:17.283-07:002011-10-30T16:49:17.283-07:00On the other hand, since the mask generation isn&#...On the other hand, since the mask generation isn't exactly real-time, you could try something simple first: just do a byte-by-byte comparison with the last row. No checksums, no detection of other repetition patterns.peterfireflyhttps://www.blogger.com/profile/05050847835479172236noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-75723843249186697112011-10-30T16:47:27.139-07:002011-10-30T16:47:27.139-07:00A flaky wifi connection just ate my last comment. ...A flaky wifi connection just ate my last comment. This is an attempt to recreate it.<br /><br /> ---<br /><br />It should be pretty easy to compress the mask image on the fly so you can still piggyback on the drawing code.<br /><br />For each line, calculate a checksum. You might be able to get away with something as silly as a 1-byte sum or it might be something slightly more "grown up" (but still cheap) like Fletcher's checksum.<br /><br />For each of the already encountered unique rows in the mask image, you store their checksum.<br /><br />Search through the list of those checksums (backwards is probably slightly faster since most rows are like the previous row) and do byte-by-byte matching when the checksums match. It is probably going to be very rare that more than one row has a matching checksum.<br /><br />After you have compressed the mask image, you generate the shifted mask images easily, since they have the same compression pattern.<br /><br />Oh, and the row pointers should maybe be relative pointers.peterfireflyhttps://www.blogger.com/profile/05050847835479172236noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-57446143768725803502011-10-30T16:37:10.941-07:002011-10-30T16:37:10.941-07:00@peterfirefly:
No, that actually sounds like a goo...@peterfirefly:<br />No, that actually sounds like a good idea. Might be doable, but the more complex the solution, the longer it will take to implement. And now I'm not gonna bother anymore...mrsidhttps://www.blogger.com/profile/11145154244292497777noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-84737758987181005172011-10-30T16:29:37.986-07:002011-10-30T16:29:37.986-07:00Couldn't you compress the masking tables?
It ...Couldn't you compress the masking tables?<br /><br />It seems to me that most lines are identical to the previous line (or some other line). How about having a table of pointers for the start in memory of each row mask? And then not duplicating those row masks?<br /><br />And wouldn't that gain you enough memory that you could keep four versions of the mask image?<br /><br />(Maybe use relative pointers so you could share the table between the four shifts?)<br /><br />Of course I might be spouting nonsense, given that I have never programmed a Commodore 64 or played PoP much.peterfireflyhttps://www.blogger.com/profile/05050847835479172236noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-83223350498211079042011-10-30T12:08:35.495-07:002011-10-30T12:08:35.495-07:00Talk about tight fit ha ? :)
If 6x256 bytes were ...Talk about tight fit ha ? :)<br /><br />If 6x256 bytes were a problem I bet you had to make lots of decisions like that...<br /><br />Never mind that - best programming diary this year for sure!Vladimir Jankovićhttps://www.blogger.com/profile/10805585830662544511noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-72075019731212728102011-10-30T08:07:29.790-07:002011-10-30T08:07:29.790-07:00Very interesting Sunday read again.Very interesting Sunday read again.Og2thttps://www.blogger.com/profile/04410544331962002380noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-45319917950919516622011-10-30T05:47:04.917-07:002011-10-30T05:47:04.917-07:00@Vladimir:
That was obviously the first idea I ha...@Vladimir:<br /><br />That was obviously the first idea I had, but it takes a lot of extra memory that I don't have, and banking in/out ROM in the inner loop is not going to make it faster either. The code size explodes a bit when doing this, and I have to keep this code in RAM, because the data I'm reading and masking has to be in ROM. In the end, this was the best option under the constraints.mrsidhttps://www.blogger.com/profile/11145154244292497777noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-48221893760325923072011-10-30T05:42:55.293-07:002011-10-30T05:42:55.293-07:00@starwindz:
1. I think you don't quite unders...@starwindz:<br /><br />1. I think you don't quite understand how this works. There's no memory available to set up a new screen in advance, and clearing is not what takes the time. It's drawing the new screen, and that's done while the screen is turned off. You could only show the previous screen longer, but the delay would be the same.<br /><br />2. The level data is almost exactly the same. The only differences are in the way the guards and their location/skill/color is handled. <br /><br />Here's the Apple II data layout:<br /><br />B700:BlueType<br />B9D0:BlueSpec<br />BCA0:LinkLoc<br />BDA0:LinkMap<br />BEA0:Map<br />BF00:Info<br />BF40:KidStartScrn<br />BF41:KidStartBlock<br />BF42:KidStartFace<br />BF46:GdStartBlock<br />BF5E:GdStartFace<br />BF76:GdStartX<br />BF8E:GdStartSeqLo<br />BFA6:GdStartProg<br />BFBE:GdStartSeqHi<br /><br />Subtract 0xb700 to get offsets into the normal data for one level. In the .crt not all the levels are directly after each other, there's some alignment padding to prevent the data from crossing a bank boundary. Also there are bank headers in the .crt, so you need to figure that out. There are 3 levels per bank, and they start at 0x000, 0x0900 and 0x1200 in bank 4:0, 5:0, 6:0, 7:0 and 8:0.<br /><br />3. You can modify the .crt if you want and distribute it, but change the texts at 0x6882b in the .crt file: <br />The name of the game, and the version number and date at 0x688ab. These are in C64 screen codes, not ASCII, so you need to figure that out too. 01 is A, 02 is B and so on.<br />But you have to be aware that you might run into problems caused by code that specifically handles spawning of certain things in certain levels. E.g. the shadow man will appear in levels 4, 5 and 6 in specific screens. You need to avoid those screens. The mirror will spawn in level 4, the mouse in level 8 and so on. <br />Make sure you test everything properly, there are no checks, so if you overwrite something else in the .crt, the game will most likely crash.mrsidhttps://www.blogger.com/profile/11145154244292497777noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-64161089653674777082011-10-30T03:10:37.456-07:002011-10-30T03:10:37.456-07:00Wow, 8K for masking data... But it does make code ...Wow, 8K for masking data... But it does make code much much simpler...<br /><br />I know game is done and it works perfectly, but here is how I do shifting:<br /><br />Depending on X-offset you have 4 routines. (shifting is done in multicolors pixels)<br /><br />For offset = 0 you do simple lda and sta.<br /><br />For offset = 1<br /><br />ldx CurrentMask<br /><br />lda shifted_1_right_part,x<br />ldx CurrentMask+1<br />ora shifted_1_left_part,x<br /><br />and (RomSpriteImagePtr),y<br />sta (SpriteImagePtr),y<br />iny<br /><br />lda shifted_1_right_part,x<br />ldx CurrentMask+2<br />ora shifted_1_left_part,x<br /><br />and (RomSpriteImagePtr),y<br />sta (SpriteImagePtr),y<br /><br />For other offsets you just have different piece of code that has "shifted_2" and "shifted_3" tables.<br />"shifted" tables are simple left or right parts of 256 bytes shifted by offset that the table is for.<br /><br />This one uses X register, but you can keep its value on zero page anyway.<br /><br />This method is much faster (especially in case of shifting by 6 bits) and more consistent in time it takes.<br /><br />------------------------------------<br />Hey, great read for Sunday morning!<br />Thanks for sharing code once again!!!Vladimir Jankovićhttps://www.blogger.com/profile/10805585830662544511noreply@blogger.comtag:blogger.com,1999:blog-1155250278529986220.post-76319563661788697902011-10-29T15:56:11.232-07:002011-10-29T15:56:11.232-07:00First of all, I express my respect to you for your...First of all, I express my respect to you for your great masterpiece, Prince of Persia for C64! I am starwindz, one of PoP reverse engineering members(for Mac Levels) and developer of Prince of Persia 1 Total Pack( http://forum.princed.org/viewtopic.php?f=73&t=875 ). I have serveral questions for your splendid work.<br /><br />1. Room-To-Room transition screen enhancement<br />Blank screen will be shown in a while when the prince moves to the next room. How about changing some program codes as follows? I expect the showing time of blank screen will be very short by using this technique.<br />* BEFORE: Clearing current screen -> Setting up next screen -> Showing next screen<br />* AFTER: Setting up next screen -> Clearing current screen -> Showing next screen<br /><br />2. More information of level data format<br />Could you please let me know more information of level data format for PoP C64? I have seen your previous post(Part Four) and have compared PoP.crt to original PoP1 level data file(levels.dat) using some hex editor. I found that the level data sturcture of C64 and PC are not identitcal. Please me know more information of level data such as starting offset, size of each room data and etc something like following format(PC format).<br /><br />Length Offset Block Name<br />----------------------------<br />720 0 pop1 foretable<br />720 720 pop1 backtable<br />256 1440 door I<br />256 1696 door II<br />96 1952 links<br />64 2048 unknown I<br />3 2112 start position<br />3 2115 unknown II<br />1 2116 unknown III<br />24 2119 guard location<br />24 2143 guard direction<br />24 2167 unknown IV (a)<br />24 2191 unknown IV (b)<br />24 2215 guard skill<br />24 2239 unknown IV (c)<br />24 2263 guard colour<br />16 2287 unknown IV (d)<br />2 2303 0F 09 (2319)<br /><br />3. Permission of distributing modified PoP.crt file<br />I have some plan for adding PoP C64 to PoP1 Total Pack. This means that numeriois fan made levels and random level generator(made by me) can be played in PoP C64. What do you think about that?starwindzhttps://www.blogger.com/profile/03285178901816683577noreply@blogger.com