Prince of persia for intv is crazyness?

[vprette]

I think Joe need to have a new project after space patrol :-)

a very challenging quest for him woul be porting Prince of Persia...

this may be not impossibile: see the just distributed

!

 

Joe, give a feedback on this: too difficult?

 

:-)

[intvnut]

Don't look at me for this one! :-)

[GroovyBee]

You could do a game in the style of Prince of Persia e.g. exploring tombs and solving puzzles type of thing. However the Inty would not be well suited for attempting the full game in my opinion.

[Chuck D. Head]

That c64 version looks pretty damn good! I've gotta try it.

[Rev]

You could do a game in the style of Prince of Persia e.g. exploring tombs and solving puzzles type of thing. However the Inty would not be well suited for attempting the full game in my opinion.

You could do a game in the style of Prince of Persia e.g. exploring tombs and solving puzzles type of thing. However the Inty would not be well suited for attempting the full game in my opinion.

 

 

Sounds a little like Rick Dangerous.

[BladeJunker]

Well let's look at the basics of the concept, first you have a highly layered perspective system in POP which would cut into on screen sprite limits but the typical POP level doesn't usually use many actual game sprites. I'd say the smooth animation is a pain to fit into the GRAM, bank switching could help but its more work and cart hardware. I don't think there is enough room in the GRAM for background tiles so you'd have to approximate something using the GROM table. Definitely a challenging homebrew for the INTV but it would be pretty cool if you got it to work.

[intvnut]

If someone seriously wanted to try this, the original developer posted the source code for the Apple II version recently.

 

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

 

The README makes it sound as if Ubisoft considers Prince of Persia an active property. But, still, read the rest of the README. There's plenty of interesting stuff here to go through, such as game design notes, and the "porting package" set of notes / instructions the original programmer gave to the teams that ported Prince of Persia to other platforms after the Apple.

 

I personally think this game is a bigger stretch for the Intellivision than Rick Dangerous.

[belfedia]

 

[Flojomojo]

You could always adapt the PoP style into something different, like the Ketchapp version from last year. I think it's fun when people make new and interesting things out of old parts. 
 

https://blog.en.uptodown.com/prince-of-persia-escape-ketchapp/

 

 

[Zendocon]

I sure hope nobody turns POP into a runner game.  I like the original game the way it was.

 

Also, I know the posted video is supposed to be a proof-of-concept.  Does it display all those animation frames with the amount of GRAM the Intellivision has, or will it require additional GRAM?

 

That said, I really would like to see this happen.  POP was a great game on the PC and also the SNES.

[skywaffle]

14 hours ago, Zendocon said:

I sure hope nobody turns POP into a runner game.  I like the original game the way it was.

 

Also, I know the posted video is supposed to be a proof-of-concept.  Does it display all those animation frames with the amount of GRAM the Intellivision has, or will it require additional GRAM?

 

That said, I really would like to see this happen.  POP was a great game on the PC and also the SNES.

This is all being done in IntyBASIC, and runs fine on stock Intellivision hardware.  The main character is done with 4 sprites, using 7 and occasionally 8 grams.  These grams are redefined and the sprite positions are adjusted for each frame.

More compromises will likely be made to have the sword fighting elements, and even drawing an additional character on the screen, as well as having falling platforms.  The 8 sprite limit, along with 64 unique grams will make things difficult. 

[+Black_Tiger]

The sword fights in the original game quickly got old for me, but I love the resr of the game.

[Austin]

If the combat is executed properly, this could be absolutely amazing for the system.

[Zendocon]

20 hours ago, Austin said:

If the combat is executed properly, this could be absolutely amazing for the system.

In the original game as well as the SNES port, the easiest way to win a fight is to pin the enemy against the wall and keep striking.  While backing into the wall and then stepping away, the enemy cannot fight back or defend himself, so you can keep striking until he dies.

 

Maybe there could be a difficulty setting to either keep it that way or to fix it.

[Austin]

18 hours ago, Zendocon said:

In the original game as well as the SNES port, the easiest way to win a fight is to pin the enemy against the wall and keep striking.  While backing into the wall and then stepping away, the enemy cannot fight back or defend himself, so you can keep striking until he dies.

 

Maybe there could be a difficulty setting to either keep it that way or to fix it.

That's a rare situation and only occurs a handful of times over the entire game. What I am talking about is handling the combat the same way the original computer versions did, which the NES, Genesis and SMS versions did not (combat wise, those were clunky messes with no rhythm or rhyme to the action). The SNES and Sega CD replicated the computer game combat properly, so hopefully this INTV version can do the same.

[+cmadruga]

On 11/15/2019 at 9:52 AM, skywaffle said:

This is all being done in IntyBASIC, and runs fine on stock Intellivision hardware.  The main character is done with 4 sprites, using 7 and occasionally 8 grams.  These grams are redefined and the sprite positions are adjusted for each frame.

More compromises will likely be made to have the sword fighting elements, and even drawing an additional character on the screen, as well as having falling platforms.  The 8 sprite limit, along with 64 unique grams will make things difficult. 

How do you redefine all 4 sprites on a single frame? Could you elaborate? Do you use VARPTR?

Edited November 28, 2019 by cmadruga

[skywaffle]

5 hours ago, cmadruga said:

How do you redefine all 4 sprites on a single frame? Could you elaborate? Do you use VARPTR?

That's correct.   Attached is an example of how all the animation is done.  It was thrown together just for testing animation frames and aligning the sprites for each frame before being put into the game 

 

Up and down will change the animation frame and left and right will change the direction

pop_jump2.bas

[+cmadruga]

Pretty cool, thanks for sharing!

 

A few questions if you don't mind...

 

- How did you arrive at the values for the X/Y tables? Trial and error, fine tuning, etc?

- Would you mind showing me what "pop_jump.bmp" looks like?

- Are you really multiplexing the shoes by alternating 2 consecutive frames? 

- Is #CHRCOL5 used for other types of movement not shown in this code?

[skywaffle]

The x/y offset table values are done through trial and error.   I use paint.net to create all the graphics (using layers to reflect each sprite), and with that I can determine if each frame will have a double wide sprite which I can easily set in the tables.  pop_jump was the file for when I converted the BMP for all the animation frames into a BAS file using INTYCOLOR.EXE.  I just take all the bitmaps and copy them to another file.  As I would tweak the animation frames, or redraw certain graphics, I would always have one file with raw bitmaps, and a second for the animation routines.

 

I was trying to limit the number of sprites used, because I use an additional sprite as a mask for foreground elements, and that only leaves three to be used for an enemy sprite, or possibly falling platforms.   On the jump animation, his feet are so far apart, there was no easy way to draw both without using an additional sprite, or multiplexing, however that is the only animation I have that uses that.

 

#CHRCOL5 really hasn't been used for anything, and I should have removed it,  early in development I was experimenting with using BEHIND, but I had found a better method to make the character disappear behind objects.

 

 

[skywaffle]

Here is another animation that might be a bit more organized.   As I worked on different animations, I would find nicer ways to work some of the tables and try to keep the overall sprite definitions the same between every animation.   In the actual game, all the tables are combined, and the sprites are all set up with a subroutine, I also have an ON / GOSUB routine that will call specific logic required for certain animations (like being able to grab a ledge while jumping).

 

Here is the set of animations that have been flattened (originally it was layered to allow for easily repositioning and tweaking of individual sprites)

 

 

Once I have run out of patience working on graphics, or feel satisfied with what I have, I reorganize the graphics like so:

 

The pants are the first two grams, then arms, then turban/vest, and then shoes.  After that I recolor the image to two colors so Intycolor won't invert any of the bitmaps.

 

Once this is done, I run Intycolor with the arguments -b -a to convert everything to IntyBASIC, and lastly move all the data statements from the generated BAS file into the program attached and get to work on setting up the correct offsets in the various x and y tables.

pop_climb5.bas

[+cmadruga]

I can only admire the patience it all took. What a meticulous job, clearly a labor of love. 

 

Could you elaborate on the use of that one sprite to mask foreground elements? How does it work in practice?

 

Also, you are leaving 3 sprites for the enemy, but then again the hero would need an additional sprite for the sword, no?

And another sprite for the enemy's sword. That would leave only 1 sprite to represent the enemy's entire body... ?

[skywaffle]

Thank you,  it's been fun to see it come together as far as it has, and just to see something like it run on the Intellivision.

 

For the foreground element, things get a little complex.   I try to organize all the grams into background (no collision), then foreground (also no collision), and lastly solid tiles (walls, floors, etc that would use collision)

 

The foreground sprite is something that turns on and off dynamically.  I use sprite 0 since it overlaps all other sprites, and the gram is solid (all 1s).

Basically as the player moves, the backtab in front of the player is looked at for grams that are greater or equal to the reference point for foreground grams.  Once this is found, a static x and y position is established and sprite 0 gets enabled using the "behind" flag.  Once enabled, distance from the player to the foreground sprite is checked, and if greater than a set amount, it turns off the sprite

 

Here is the code I use.   X and Y reflect the player's position, and #flip is the direction the player faces.

 

    TEMP = (X / 8 ) * 8 + 8 
    TEMPY = (Y / 8 ) * 20
    IF FOREGROUND_OBSTRUCTION_X = 0 THEN 
        SPRITE 0,0

        IF #FLIP <> 0 THEN 
            OX = X + 4
        ELSE
            OX = X - 16
        END IF
            #TEST = #BACKTAB ((OX / 8 ) + TEMPY) AND (GRAM + FGBG_CARD_DATA_MASK) 
            IF #TEST >= $0908 THEN FOREGROUND_OBSTRUCTION_X = (OX / 8 ) * 8 + 8: OBSTRUCT_Y = Y - 3
    ELSE

        SPRITE 0, FOREGROUND_OBSTRUCTION_X + VISIBLE, OBSTRUCT_Y + ZOOMY8, SPR63 + SPR_BLACK + BEHIND
        IF #FLIP = 0 THEN 
            IF X > FOREGROUND_OBSTRUCTION_X THEN 
                IF X - FOREGROUND_OBSTRUCTION_X > 18 THEN FOREGROUND_OBSTRUCTION_X = 0
            ELSEIF FOREGROUND_OBSTRUCTION_X - X > 9 THEN 
                FOREGROUND_OBSTRUCTION_X = 0
            END IF
        ELSE
            IF X > FOREGROUND_OBSTRUCTION_X THEN 
                IF X - FOREGROUND_OBSTRUCTION_X > 11 THEN FOREGROUND_OBSTRUCTION_X = 0
            ELSEIF FOREGROUND_OBSTRUCTION_X - X > 13 THEN 
                FOREGROUND_OBSTRUCTION_X = 0
            END IF
        END IF
    END IF

 

As far as the sprites go, I am still undecided how to approach enemies.   I figured in areas with enemies, I could remove foreground elements and have that sprite available to use and possibly multiplex to display both swords for the player and enemy.   I still am unsure how faithful I want to be to Prince of Persia to be honest.   I have contemplated doing something different, and just having traps, keys, doors, and various puzzle elements.  It could make for an interesting adventure experience, but I haven't given up yet.

 

Edited December 4, 2019 by skywaffle

[+cmadruga]

I got the general logic of the foreground sprite, thanks for elaborating. 
I like how you divided GRAM into those 3 portions. For HELI, I also found very useful to organize it, particularly for the solid tiles. It really simplifies collision tests.
How did you arrive at the value of $0908 as the condition for the test? Sorry about the detailed questions!

[+cmadruga]

On 12/4/2019 at 10:31 AM, skywaffle said:

As far as the sprites go, I am still undecided how to approach enemies.   I figured in areas with enemies, I could remove foreground elements and have that sprite available to use and possibly multiplex to display both swords for the player and enemy.   I still am unsure how faithful I want to be to Prince of Persia to be honest.   I have contemplated doing something different, and just having traps, keys, doors, and various puzzle elements.  It could make for an interesting adventure experience, but I haven't given up yet.

An interesting challenge... Personally, I think the puzzle element is the main attraction here.
Still, another idea could be to lock the distance during a fight, and represent both swords with either one tile/sprite, or one sprite over one tile.

 

[skywaffle]

18 hours ago, cmadruga said:

I got the general logic of the foreground sprite, thanks for elaborating. 
I like how you divided GRAM into those 3 portions. For HELI, I also found very useful to organize it, particularly for the solid tiles. It really simplifies collision tests.
How did you arrive at the value of $0908 as the condition for the test? Sorry about the detailed questions!

The value is just based on the reference point at which foreground tiles begin, so everything >= $0908 (card 33) will dynamically create the foreground element, including solid objects that can't be walked through completely.

 

I keep a specific order for all the tiles, 0-8 are for the character, 10 is for the torch, 11-36 are tiles that can be walked through, however tiles at 33 or higher will have the foreground element.   Tiles 37 and up are solid tiles.  and 63 is used for the foreground mask.

 

These positions have changed as I have reworked the graphics, but I have settled with that for now.  On other game projects, I have just made variables for separation of background to solid tiles, especially if the number of tiles used for background versus solid changes from one level to the next.