mrsid

I have to copy the C64 sprites from cartridge ROM to RAM and mask them as part of that copy loop. Each sprite is a 24x21 pixel image (well 12x21 wide pixels) which are 63 bytes in size. One game character is made up of 4 sprites (in different configuration such as 2x2, 4x1 or 1x4).

Yes, I did change code that was drawing too much, and I also simplified things (like the falling plates) to speed things up. The A8 should be fine, since it has a faster 6502 than the C64, but there are a lot of redraws involved. Check the Atari ST version to see how slow it can get... I tried to stay away from optimizations that might lead to new bugs.

Yes, that's correct. The first one is in RAM for me, and the second one (QUICKFLOOR) is only called as part of setupKid/setupShad which is required for drawing the characters into the bitmap. In my case, that code is replaced with sprite stuff, so it's not in my version.

All the code is decompressed on startup. But at some point I couldn't fit in all of the code anymore, so I started to keep it in ROM and call it there directly. I think the only self-modifying code I came across was the bitmap drawing routines. All the game logic seems to be safe to run from ROM. So there are two parts, the resident code in RAM, and an additional 8K ROM bank. I also initially removed all the jump tables, but then I re-added one just for the parts of the code that were kept in the ROM bank.

Well, once I decided to go via the cartridge route, I didn't have to optimize for memory size anymore, so I optimized for speed instead. So e.g. the level blueprint data is no longer compressed and aligned to bank boundaries, to allow it to be accessed directly (about 40K). Also all the background drawing (and clearing) code is unrolled (about 64K). The title screen picture and the title cards are stored as bitmaps (about 72K). The music code and data is about 8K (data streams converted from MIDI data, no patterns or other size optimizations). The cutscene (princess room) background bitmap is another 10K. The animation frames for the kid are aligned to fit into hardware sprites, so they take up about 40K per direction. The frames for guard, fat guard, skeleton and vizier are about 8K each, for each direction. Dungeon and Palace backgrounds are about 16K each. The main part of the code is 24K compressed, and some code (about 8K) is kept uncompressed in ROM, to execute it directly (such as the AI and sword fighting logic). There's also a little intro with a manual reader (about 24K). The sound effects are in their own 8K bank. The rest is miscellaneous stuff and alignment overhead, and some free space to save the game state to the flash. The characters are drawn using hardware sprites, and need to be re-masked whenever they move, so it seemed easier to build up the whole mask first as part of the initial screen draw, instead of having to figure out the part of the screen that needs to be used for masking by walking the image lists again. I'm sure the other way round might have worked as well, but it's essentially another speed vs. memory trade-off.

@rensoup Wow, great achievement so far! Good luck with finishing it. Let me know if I can be of any help...

So cool to see someone else get to this point. Great achievement! But it does make the A8 people look bad... come on guys, you can do it!

Motivation is not a constant, it comes and goes. Trust me, you'll need all the motivation you can get to pull through with this, and any time you get positive feedback you have a little bit less of a reason to finish, because you've already got some of the gratification. IMHO it's best to defer all the praise to the end of the project, so you have something to look forward to. But, hey, what do I know?

I'd recommend not posting any more previews, it'll demotivate you. Keep moving forward...

This sounds exactly like what I do. I use the heavy duty nylon cable ties to attach power strips to the horizontal metal struts underneath the desk, then after wiring everything I use velcro ties to make the cables run close to the desk support. Also I attach all wall warts that way. There's nothing on the floor.

To answer the actual question, the fat guard appears only in level 6. He's the only guard in that level. It's the short one where the Shadow closes the gate in the end and forces the player to fall down to level 7. See http://vgmaps.com/Atlas/C64/PrinceOfPersia-Level06.png

Or http://hvsc.perff.dk/MUSICIANS/L/Linus/Harden_Your_Horns_edit.sid

Nice effort, but now try some more interesting tunes. E.g. http://hvsc.perff.dk/MUSICIANS/L/Linus/Harden_Your_Horns_edit.sid or http://hvsc.perff.dk/MUSICIANS/H/Holt_Hein/Cheap_Porn.sid Would love to hear these through your emu...

Signing off... I wish we had a C64 forum like this one...

I wouldn't have expected tools to be the problem... There are tons of 6502 assemblers out there, and many very capable text editors and even some full blown IDEs. People are making stuff for 6502-based platforms with these all the time...

https://github.com/jmechner/Prince-of-Persia-Apple-II

Oh and I'll bet some money on the Speccy version being based on the official Amstrad version. If I could stand to look at Z80 code I would check...

The PC version is an exact port of the Apple II version, it uses the same data structures and has the same behavior (except for a few fixed bugs and a few new ones that were introduced). The Spectrum version is quite close, but some levels had to be modified slightly...

Collision detection in PoP is not about collision between sprites or something like that, where hardware registers might be useful. It's about detecting the level environment around the player to determine which actions are possible and which aren't. You need to look ahead in the running direction, not just at the player position. This logic is complicated and the levels were designed with those algorithms in mind. If your code is just slightly different, it might be impossible to complete a certain level. But since everybody is an expert here, I'll shut up again...

VladR is oversimplifying the game a lot. With an approach like that, you're not going to get anywhere. The collision and animation system is some of the most complicated code I've seen on an 8bit machine, and comparing it with other jump'n'runs is a fatal mistake. Even though the game runs at 12fps only doesn't mean that you have cycles to waste, and writing the game logic in C is not really going to cut it. Also, why reimplement it in C if there's 6502 code available? People have tried to do that and the result is an unplayable joke (Freeprince project). But yeah, maybe I shouldn't post here, since I have no A8 experience. But then I don't like to see people fail, I would much rather help in getting PoP onto the A8.

10 each

What if the player is standing behind a gate or a chopping jaw? Let me remind you of this:

There is no c64 source...

Any tile on the screen can be animated at the same time. There are levels with multiple blades and doors and they're moving independently. Try looking at this:

The trick is to get started.