Jump to content

The Southsider

  • entries
    81
  • comments
    767
  • views
    135,969

PoP Development

Sign in to follow this  
Guest

335 views

I have been dropping hints for some time about a new Supercharger project that I have been working on. However, I am now finally ready to reveal some details about this project. The main reason for the delay was that I had some difficulties getting my head around the oddities of the Supercharger. On reflection it doesn't appear too complex now, but the lack of clear documentation (now fixed thanks to Eric), and the way you have to read memory to write caused me some big headaches. I ended up rewriting the code several times over to get around the various problems I faced. The project is an attempt to produce something for the Stella Programming Contest. It is a joint project between myself and jussts, where I will take on the coding and he will produce the graphics. The project can also be seen as a continuation of this long running thread. If you haven't already guessed, the basic idea is to produce a Supercharger version of the first Prince of Persia (PoP) game. This has been one of my long-standing favourite games, and judging by the comments on the forum, many other people have fond memories of it also. Obviously, some relatively severe compromises will have to be made to produce a 2600 version, but that is what I hope to do. I can't promise to finish the project as it is clearly a very big undertaking, and my time is limited by other demands. However, I am hoping to move things forward from where the project stalled before. I think one of the main problems was that there was nobody to do the graphics, but this should not be an issue now.post-4913-1100942565_thumb.jpgIn my opinion, the game is ideal for a multi-load supercharger game. The multi-load feature will allow the different levels to be loaded on-demand, and the extra memory means that we will be much less restricted (over a regular 2600 version). I was originally intending to take the kernel that Thomas Jentzsch wrote and modify it for the Supercharger. However, I eventually rewote the kernel from scratch as too many things had changed. I also devised a new way of representing the screens which is very similar to the technique used in Hunchy 2 (thanks to supercat). The source code and binary should be attached to the top of this entry. The binary (pop.bin) can be run in either Stella or Z26 - I haven't tested it on a real Supercharger yet. As usual for a project at such an early stage, the source code is in a bit of a mess, and is likely to contain many bugs. I have encoded all of the screens from the first level of the game in this demo. If you walk off the edge of the screen, you will be taken to the next screen. Here are a few notes about the demo in no particular order:

  • There are 22 screens in total, and most elements of the original game are represented (apart from the palace guards).
  • The kernel has code for displaying the sword, but it hasn't been tested yet.
  • Some of the prince sprites will be wider than 8 pixels. To overcome this problem, a missile sprite is drawn next to the player, which should permit a few extra pixels width. However, this is also not used in the current version.
  • There are still some spare cycles in the kernel. I would like to put a missile sprite next to the P1 sprite, but I haven't managed this yet.
  • The texture on the walls is generated by using a bit of self-modifying code. Looking at the kernel now, it might have been possible to do this another way, but it is a Supercharger project!

Anyway, I how that you enjoy the demo! There is still a great deal of work to do, but I have to start somewhere. Any suggestions for improvements and feedback will be most welcome.Chris

Sign in to follow this  


13 Comments


Recommended Comments

Holy snap that looks awesome! I am glad that someone is picking this project up, and glad that you have, so far, outstripped what we thought was possible!

 

That extra RAM really helps, I imagine :)

Share this comment


Link to comment
Holy snap that looks awesome!  I am glad that someone is picking this project up, and glad that you have, so far, outstripped what we thought was possible! 

That extra RAM really helps, I imagine :)

 

Thanks! It was very useful to read the discussions that you and Thomas had - I doubt I would have been able to do this otherwise. At the moment, I think my kernel could be done on a regular 2600 with a lot of ROM, but the RAM certainly helps, and will be very useful later in the project. It is just a pity that writes on the Supercharger are so expensive (10 cycles) which makes it hard to use in the kernel.

 

Chris

Share this comment


Link to comment

Out of curiosity, what is your plan for the fight scenes?

Looks like you are repositioning the 2nd sprite, so I assume the palace guards will be no problem, but what about the swords?

 

Will you be using the ball for that? And will you be flickering it to get two swords on screen at once?

 

EDIT: And why would you need to *write* to RAM during your kernel?

Share this comment


Link to comment
Out of curiosity, what is your plan for the fight scenes?

Looks like you are repositioning the 2nd sprite, so I assume the palace guards will be no problem, but what about the swords?

Will you be using the ball for that?  And will you be flickering it to get two swords on screen at once?

EDIT: And why would you need to *write* to RAM during your kernel?

 

I am currently planning to use the ball sprite for the sword (flickering between the player and guard) just as in your version. The kernel currently contains code for repositioning and drawing the ball on every second scanline. However, the player already has a missile sprite at the side, so it might be possible to use this instead (without flicker), though the colours might be a problem. I still need to do some experiments to see which method will work best ...

 

The main playfield (3 sections) is drawn using absolute indexed mode (e.g. lda Tile,X; sta PF1) to save cycles. The pointers are updated between sections by self-modifying code, which requires a write operation. However, now that the kernel is complete, there appear to be enough spare cycles to use indirect indexed mode instead.

 

Thanks for your comments, and let me know if you have any suggestions for improvements.

 

Chris

Share this comment


Link to comment
Wow, amazing progress here! Continue with that speed you're done in a month! :)

 

Thanks, but I think I have only done the easy stuff so far :) The collision detection and animations are going to be a real headache!

 

Chris

Share this comment


Link to comment
Thanks, but I think I have only done the easy stuff so far :)  The collision detection and animations are going to be a real headache!

 

What's the problem? Collision-detection for PoP looks like it should be simpler than Hunchy2 (no ladders etc. to worry about). If you could manage something like Hunchy2, you should be able to manage this.

 

BTW, would you have enough cycles to change the playfield color on alternate scanlines? I don't know if that would improve appearances or not, but it might be interesting to try.

Share this comment


Link to comment
What's the problem?  Collision-detection for PoP looks like it should be simpler than Hunchy2 (no ladders etc. to worry about).  If you could manage something like Hunchy2, you should be able to manage this.

 

I think the basic wall collisions will be simple enough. However, I anticipate problems with things like clinging onto ledges, and the fight scenes, though I could be worrying about nothing. In any case, there is still a lot of work to do before the game will be playable.

 

BTW, would you have enough cycles to change the playfield color on alternate scanlines?  I don't know if that would improve appearances or not, but it might be interesting to try.

 

There are currently around 9 free cycles in the main loop which should be enough to read a colour table and write to the PF, though it will require some work as they are currently in the middle of the scanline. Did you have any colour scheme in mind (e.g. blue colour bands)?

 

Chris

Share this comment


Link to comment
I think the basic wall collisions will be simple enough.  However, I anticipate problems with things like clinging onto ledges, and the fight scenes, though I could be worrying about nothing.  In any case, there is still a lot of work to do before the game will be playable.

 

Speaking of fight scenes, will the guards be restricted to platforms that don't have anything else interesting on them? Also, is there any reason the playfield is in front of the player? I know in Hunchy2 you had to do that to 'hide' unused missiles, but is that an issue here?

 

There are currently around 9 free cycles in the main loop which should be enough to read a colour table and write to the PF, though it will require some work as they are currently in the middle of the scanline. Did you have any colour scheme in mind (e.g. blue colour bands)?

 

I don't know what all you're going to want to show in your backgrounds, but if you color the playfield with two different colors on alternate scan lines, you can make things more colorful. For example, if you were to use cyan and orange stripes, then places where the playfield was 'solid' would be whitish while other areas could be blue or orange. If desired, the colors could be made more subtle (e.g. blue and green, which together would yield cyan). Note that Apple II games formed colors this way, except using adjacent horizontal rather than vertical pixels.

 

Note that for this technique to work well, you'd have to double the vertical resolution of your playfield. This may require changing how things are stored. My inclination would be to suggest that you have your playfield stored much like you do in Hunchy, using fairly short tiles (16 scan lines or so) and then have the map be composed of mega-tiles. When you walk into a room, use a set of translation tables to convert the screen full of mega-tiles into the smaller tiles. If you have nine cycles free per scan line, things should work out: you spend four extra to use indirect addressing instead of indexed, and five to do an LDA #color / STA COLUPF. Note that the code can be patched on the fly if different rooms are supposed to be tinted differently.

Share this comment


Link to comment
Speaking of fight scenes, will the guards be restricted to platforms that don't have anything else interesting on them?  Also, is there any reason the playfield is in front of the player?  I know in Hunchy2 you had to do that to 'hide' unused missiles, but is that an issue here?

 

The guards will be restricted to empty platforms as they will be drawn using the same sprite as the torches, potions, etc. I don't think this will be a problem as the guards in the original are essentially fixed at a particular location. The playfield pripority is set this way because the player moves behind the pillars in the original. This makes the fight scenes more difficult, as you have to ensure that you don't get caught behind a pillar. However, I may remove this in the 2600 version as it looks a bit odd with the players feet visible under the pillar!

 

I don't know what all you're going to want to show in your backgrounds, but if you color the playfield with two different colors on alternate scan lines, you can make things more colorful.  For example, if you were to use cyan and orange stripes, then places where the playfield was 'solid' would be whitish while other areas could be blue or orange.  If desired, the colors could be made more subtle (e.g. blue and green, which together would yield cyan).  Note that Apple II games formed colors this way, except using adjacent horizontal rather than vertical pixels.

 

I am not sure this is such a problem on the Atari. As I understand it, the Apple II could only display 4 or 8 colours on screen at a time, so they had to use dithering to generate more visible colours. I guess this technique would make the bricks appear to have more colours at the edges though?

 

Note that for this technique to work well, you'd have to double the vertical resolution of your playfield.  This may require changing how things are stored.  My inclination would be to suggest that you have your playfield stored much like you do in Hunchy, using fairly short tiles (16 scan lines or so) and then have the map be composed of mega-tiles.  When you walk into a room, use a set of translation tables to convert the screen full of mega-tiles into the smaller tiles.  If you have nine cycles free per scan line, things should work out: you spend four extra to use indirect addressing instead of indexed, and five to do an LDA #color / STA COLUPF.  Note that the code can be patched on the fly if different rooms are supposed to be tinted differently.

 

Having looked at the code again, I don't think I can change to indirect addressing and still have the sprites drawn in the correct place, unless I unroll the kernel loop. I think it might be easier just to change the colours every scanline but keep the 2-line tile resolution if I can find the cycles.

 

Chris

Share this comment


Link to comment
What's the problem?  Collision-detection for PoP looks like it should be simpler than Hunchy2 (no ladders etc. to worry about).  If you could manage something like Hunchy2, you should be able to manage this.

 

I think the basic wall collisions will be simple enough. However, I anticipate problems with things like clinging onto ledges, and the fight scenes, though I could be worrying about nothing. In any case, there is still a lot of work to do before the game will be playable.

I would imagine that it won't be technically difficult, it will just be very complicated and kind of a pain to get everything to work correctly.

Partly because a lot of that stuff won't be based on the collision registers (hardware) but rather on positioning (software collision), which is kind of a hassle.

Share this comment


Link to comment

Ahh, good to see that someone else has taken up Glenn's challenge. And I wouldn't mind at all losing to PoP 2600; I recall playing the PC version fondly. (Well, some of the traps/puzzles were a little annoying.) I wish you the best of luck, you've taken on a very challenging task.

 

My only advice is to play through the PC version and make careful notes about everything. When I started thinking about Leprechaun (then known as Gold Digger) I made the explicit decision not to try to duplicate Lode Runner simply so I wouldn't have to worry about trying to recreate the gameplay exactly. You may find yourself making the same decision, although it appears you are doing a fine job of adapting the look of PoP.

 

I also wouldn't worry too much about performing collision detection in software. Although hardware collision detection takes away the comparison requirements, it puts a lot of strain on making the graphics work right. Since you are using the ball for the sword, you could try to use the ball<->player HW collision detection, but I think you would find it very difficult to avoid false hits and misses.

Share this comment


Link to comment
Ahh, good to see that someone else has taken up Glenn's challenge.  And I wouldn't mind at all losing to PoP 2600; I recall playing the PC version fondly.  (Well, some of the traps/puzzles were a little annoying.)  I wish you the best of luck, you've taken on a very challenging task.

 

Eric,

 

Thanks for the message of support, and good luck with your project also. I believe that we are the only ones to announce a Supercharger project so far, but I understand that vdub_bobby is contemplating a Supercharger RPG. I am not sure if I will be able to complete the project, as it is a large undertaking, and I have some big changes to my work schedule coming up. However, I am going to give it a good try, together with jussts doing the sprite graphics. I am basing my code loosely on SNES version, but I keep getting sidetracked actually playing the game itself! I think all the collision detection will have to be done in software, but I can probably reuse a lot of the techniques from Hunchy 2. There are definitely going to be some elements of the game that won't be possible on the 2600, but I am trying to stick closely to the original for now. I think the fighting scenes are going to be the hardest element to code, but we will see...

 

Chris

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...