The Southsider

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

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

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?

Hi there!

 

Wow, amazing progress here! Continue with that speed you're done in a month!

 

Greetings,

Manuel

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

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

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.

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

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.

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

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.

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.

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