Prince of Persia

[Creature XL]

Alright then! For me the rendering is not difficult and for you the logic and so on is easy.

So just do it together! Of course, if you want to code the rendering yourself I am not too eager to do it

Edited February 10, 2013 by Creature XL

[VladR]

No, I do not want to mess with the rendering on A8, actually. I did that, 25+ yrs ago, but don`t really fancy it anymore.

 

I am not, however, willing to mess with 6502 ASM again and would strongly prefer C since it is two orders of magnitude more productive to write in and find bugs than ASM.

 

What are the options of integrating your ASM drawing routines with C on A8 these days ? I know there are some IDEs for Action language and for 6502. Not sure if there is anything for C on A8 other than some command-line compiler like gcc. But, IDE is not really important, since I can just just NotePad++, and invoke a batch build script from within Notepad++, which can copy the binary into emulator area.

 

I hear cc65 is pretty good and offers some level of integration of ASM and C.

 

 

Before anyone starts screaming that C is slow, please realize that the most that I'd use from C lanugage are the following lanugage constructs:

- conditions

- for loops

- memory access

- structures

- bitwise operators

 

All of the above should be implemented pretty fast in the compiler, so I doubt there would be any meaningful performance difference.

 

And let`s not forget that the game will run at 12 fps, so there`s more than enough times to check through few very small arrays (medikits,enemies,traps) doing very simple conditions.

Edited February 10, 2013 by VladR

[mrsid]

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.

[VladR]

I don't think I am oversimplifying. Did you even read my posts till the end ? Did you notice "C for gameplay, ASM for everything else" ?

 

I stated that the animation system is way, way more complex that just running around the level and loading game screens.

 

Just check my post where I list all the animation states. I am very well aware that each of them has different conditions and scenarios and it can get very easy to introduce a bug over there.

 

 

And the answer to your question - "why C" is very simple - because you can get an awful lot done in a single weekend or few evenings.

 

We may, very well, approach the limits of available CPU time, but not because of C, but because of the algorithms used.

 

 

Just because you are using ASM is not going to cut it either, if you're doing something extremely stupid. Been there, done that. Many times.

 

 

 

What do you think is better ? Spend 2 yrs fiddling with LDA,STA, DEX, BNE or just 2 months in C, to figure out if it is doable ?

Edited February 10, 2013 by VladR

[emkay]

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.

 

 

Yeah. The Apple has no collision registers. This must be a very hard approach for people who usually, poke some x and y positions on Sprites.

 

And, yes , comparing PoP with other Jump and Runs is a fatal mistake, because the game avoids many of the optical possibilities.

As the enemies never cross, they just swap (for example) .

 

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.

 

Well, in summary, we'd need a capable coder, knowing game programming and the A8's features.

 

As we have seen right yet, "CreatureXL"s Sprite routine is useless for PoP, without a closer look at that.

Edited February 10, 2013 by emkay

[emkay]

I don't think I am oversimplifying. Did you even read my posts till the end ? Did you notice "C for gameplay, ASM for everything else" ?

 

I stated that the animation system is way, way more complex that just running around the level and loading game screens.

 

The animation system is the essential of the game. The game mechanics are rather easy, even the "slow" Apple can stand it.

 

That's possibly why it never will be on the A8. The animation System is underused in allmost all games on the A8. The "Protagonist mostly plays like it has a broom in the back, or moves in a "one frame / one pixel" manner.

[VladR]

The collision 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.

Just because you saw, say, 20 pages of collision detection code does not mean it is the best and only way how to do that ! Collision detection is something that you have to do nonstop, so it is obvious you have to precalculate as much as possible.

 

if you are not willing to spend a single KB for the precalc`ed collisions, then you have to pay the price of doing it ar run-time.

 

But that`s just extremely stupid and naive way.

 

It all depends on how you DESIGN the algorithm.

 

After you precalculate the collision, there is no need for the main collision detection code to be longer than few lines of code that call the following 4 functions:

ColDet = CurrentScreen->CollisionData [CurrentQuad]; // Updated only when we cross the quad boundary

bool CanGoLeft ()
{
 if (SubStep >0) return true;
 if (ColDet & LEFT) return true;
   else return false;
}

bool CanGoRight ()
{
 if (SubStep <2) return true;
 if (ColDet & RIGHT) return true;
   else return false;
}

bool CanGoUp ()
{
 if (SubStep == 1) return false;
 if (SubStep == 0)
   if (ColDet & LEFTUP) return true;
 if (SubStep == 2)
   if (ColDet & RIGHTUP) return true;
 return false;
}

bool CanGoDown ()
{
 if (SubStep == 1) return false;
 if (SubStep == 0)
   if (ColDet & LEFTDOWN) return true;
 if (SubStep == 2)
   if (ColDet & RIGHTDOWN) return true;
 return false;
}

 

Now, of course, there are countless ways how to make the same functionality way more complex, error-prone and slower.

 

 

Then again, for some, the code above might really look extremely complex...

Edited February 10, 2013 by VladR

[emkay]

Just because you saw, say, 20 pages of collision detection code does not mean it is the best and only way how to do that ! Collision detection is something that you have to do nonstop, so it is obvious you have to precalculate as much as possible.

 

The collision is best done, using "Hitboxes" , calculating the real screenpositions and size of the "Sprite". Using hardware collision detection is wasting resources with that game. The "Sprite" movement on the screen is always similar... just showing what's happening, not acting on any hardware colission.

[VladR]

The animation system is the essential of the game. The game mechanics are rather easy, even the "slow" Apple can stand it.

 

That's possibly why it never will be on the A8. The animation System is underused in allmost all games on the A8. The "Protagonist mostly plays like it has a broom in the back, or moves in a "one frame / one pixel" manner.

Well, i thought you guys already figured out that it is more than possible to render the scene in 25 fps, or in the case of slow drawing routines in 12 fps ? I am not going to comment on that, since I don't really know - but CreatureXL and Jose seem to know very well this area ?

[potatohead]

You know, I don't get it.

 

This is a bitmap game. It runs on a 1Mhz Apple ][, and because of how the Apple does it's video DMA and RAM refresh, it's quicker than one would expect from 1 Mhz, but not as quick as an Atari 8 bit is. Deffo quicker than a C64 though.

 

What that means is the Atari can just do the bitmap graphics straight up with no worries! The *ONLY* issue is the artifact color and how that relates to the pixel art on the Apple. However, if that were set aside the rest of it basically works. Sound is just the Apple speaker clicks, and that can be moved to the GTIA click for testing, or just ignored for a time.

 

Seems to me, the most effective and genuine path would be to take the Apple code as is, use ANTIC to just put the graphics screens where the Apple puts them and deal with disk I/O and memory mapping. That would get the game running fairly quickly. From there, edit the graphics to work with 8 bits instead of 7, and mix in the sounds. Done.

 

The 6 color vs 4 color issue then can be dealt with after the fact. There will be enough time to do this. IMHO, the very simplest thing is to simply use the PM overlay to assist with the artifact colors, which would preserve the pixel art. There are some issues with that, but nothing like the complexity being mentioned here.

 

This isn't a matter of the game being doable. An Atari running simple bitmap mode can do the game.

 

re: C

 

Well, it seems to me a trip through the source code of either version would yield the C framework fairly quickly. The idea that C could be used for a frame work makes sense to me. The Apple spent a ton of time rendering, with the rest of it being game states and the I/O management. I don't see an issue there, other than making sure RAM use is kept in check. When I read through Jordan's development log, he structured things to minimize touching the disk, and he had 128K to deal with. Today, we've got big carts and or the game could just touch the disk at different times.

 

In NTSC land, the Apple game art can be used with just the modification to work with 8 bits / byte instead of 7. Of course, Apples do 6 artifact colors, not 4, but maybe very simple PM overlay can be used to deal with that. In PAL land, the artifact colors don't work.

 

That means using one of the 4 color modes and some changes to the game art. Same PM overlay can get the other colors where needed, IMHO.

 

Really that all adds up to simple bitmap mode more than it does the rest of the stuff being discussed for the most lean path to do the game.

[VladR]

The collision is best done, using "Hitboxes" , calculating the real screenpositions and size of the "Sprite". Using hardware collision detection is wasting resources with that game. The "Sprite" movement on the screen is always similar... just showing what's happening, not acting on any hardware colission.

Do you see any HW collision in my code above ? I did not mention any HW collision being used.

 

And, for the record, hitboxes are an absolute CPU overkill for the collision detection with environment in Prince.

Perhaps, that`s what MrSid mentioned ? I can see that 6502 would be totally overhauled if it had to calculate hitboxes with the environment every single frame. That's why you have to simplify the whole problem space to as few instructions as possible (space/time trade-off).

 

Even for the "collision swap" wien fighting the enemy, hitboxes are not really needed and can be simplified down at run-time to a simple comparison (for the astounding "price" of about 20 Bytes - yeah - horrible, I know !).

 

Now, my background is 99% 3D games - I never really worked on some 2D games. But it doesn`t matter if you have 1.79 MHz or 1.79 GHz CPU. You are still bottlenecked the same in what you can do and how you can do it.

[emkay]

Well, i thought you guys already figured out that it is more than possible to render the scene in 25 fps, or in the case of slow drawing routines in 12 fps ? I am not going to comment on that, since I don't really know - but CreatureXL and Jose seem to know very well this area ?

 

Actually an interleave 12/13 fps would be needed to compensate the 50/60Hz issue and to have all animation-frames there.

 

They talk of multicharset - 3 layer softwaresprite handling with PM overlay in DMA Mode.

What to say? Do you really think, this is serious, anyhow?

 

I don't say PoP isn't possible. Actually in hires linear graphics with full software animations, it will work fine.

[potatohead]

Re: more than 12 FPS.

 

Why? The game art is developed for 12. (or whatever it's developed for) Unless one wants to generate new art for the animations, why not just do it as intended? When I run this game on the Apple, the frame rates vary some due to that machine not being quick enough to keep things running at speed. So long as things are not over complicated, the Atari should be able to just render things at speed, which will look pretty great!

 

25 FPS doesn't add a lot of value to this game, without 25FPS art...

 

Re: Collisions

 

Jordan indicated he checked on byte boundaries to simplify. I don't see the hardware collision being useful at all. I do believe his collision check might simplify down to something better, but then again that has dubious value given the game could run on an Atari just as it does on the Apple now.

[emkay]

Do you see any HW collision in my code above ? I did not mention any HW collision being used.

 

Which is rather nice. I just added it for the backup

 

 

And, for the record, hitboxes are an absolute CPU overkill for the collision detection with environment in Prince.

Perhaps, that`s what MrSid mentioned ? I can see that 6502 would be totally overhauled if it had to calculate hitboxes with the environment every single frame. That's why you have to simplify the whole problem space to as few instructions as possible (space/time trade-off).

 

Even for the "collision swap" wien fighting the enemy, hitboxes are not really needed and can be simplified down at run-time to a simple comparison (for the astounding "price" of about 20 Bytes - yeah - horrible, I know !).

 

 

Possibly we mean the same here. As you have a given result , checking the vertical position , then the hor. position, the size and animation frame, you simply could compare the resulting value, if it eaquals to an "enemy" or a "trap" , then it acts. If no equal value is there, nothing happens.

 

 

 

Now, my background is 99% 3D games - I never really worked on some 2D games. But it doesn`t matter if you have 1.79 MHz or 1.79 GHz CPU. You are still bottlenecked the same in what you can do and how you can do it.

 

If your Background is 3D . How'S about doing some of THAT stuff for the XL

Edited February 10, 2013 by emkay

[mrsid]

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...

[potatohead]

LOL!!

 

Well said. I really enjoyed your development log BTW. Great work!

[emkay]

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.

 

I'm pretty sure the code differs fully on the Speccy version, or even on the PC version. The handling of the given mechanics has to be correct, or even as off as on the original Apple version.

Being the coder, you "know" the position and size of the objects well, so you can set always the fitting value to handle the calculations right.

 

 

But since everybody is an expert here, I'll shut up again...

 

 

...

Edited February 10, 2013 by emkay

[VladR]

Possibly we mean the same here. As you have a given result , checking the vertical position , then the hor. position, the size and animation frame, you simply could compare the resulting value, if it eaquals to an "enemy" or a "trap" , then it acts. If no equal value is there, nothing happens.

I guess we think roughly the same.

 

If your Background is 3D . How'S about doing some of THAT stuff for the XL

I will do some 3D on atari. Just a different model - Jaguar

 

Re: more than 12 FPS.

 

Why? The game art is developed for 12. (or whatever it's developed for) Unless one wants to generate new art for the animations, why not just do it as intended? When I run this game on the Apple, the frame rates vary some due to that machine not being quick enough to keep things running at speed. So long as things are not over complicated, the Atari should be able to just render things at speed, which will look pretty great!

 

25 FPS doesn't add a lot of value to this game, without 25FPS art...

That sucks, but considering how heavy the rendering of large sprites is, I don`t think it`s a pitty we don`t have the corresponding art - meaning we'll be lucky if the end game still runs at 12 fps on A800

[potatohead]

...or do it the way it's currently done.

 

Maybe just say fuck it and do a different game? You guys should read the development logs on this one. Lots of things are done for reasons that make this game great. The idea that it can be simplified or some short cut done makes very little sense.

 

And... the code is there, and it has comments. Mr Sid had to sort all that out. Now there are two sets of comments! Seems strange to just ignore all of that doesn't it?

 

Lucky it runs at 12? Seriously?

 

Running that Apple code on the Atari would deliver what the Apple did, plus some.

[mrsid]

I'm pretty sure the code differs fully on the Speccy version, or even on the PC version. The handling of the given mechanics has to be correct, or even as off as on the original Apple version.

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...

[mrsid]

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...

[potatohead]

I wouldn't take that bet, because you are probably right about it.

[VladR]

You need to look ahead in the running direction, not just at the player position.

Did I state anywhere above that the collision detection code is COMPLETE for all player states ? No. But the basic principle stays - checking if it is possible to move,jump,fall,ledge is as simple as calling those 4 functions (in certain combinations, based on the current state).

 

This logic is complicated

The logic is complicated ONLY if it has been BASTARDIZED by endless refucktoring and failing to win over a feature creep. Or if you take several 3-months long breaks.

If you design it properly from the get-go, then it does not have to be complex.

 

Would I ever be willing to spend weeks messing with someone else`s ASM codebase trying to figure out what the hell did that guy think of when writing some piece of code ? Absolutely not ! That's an incredible waste of time !

 

What might come in handy, once the base code works and we need more performance, is to start replacing those parts of the C-code that are performance-critical by hand-written ASM.

 

 

But you gotta get there first. And, for some obscure reason, so far there hasn't been a single coder who even said he was willing to give ity a try (let alone actually did the gameplay).

 

 

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.

That is an unfortunate possibility. But if any of the legacy gameplay code is FPS-dependant, you have to address it anyway.

 

But since everybody is an expert here, I'll shut up again...

Oh, what a Drama Queen

Just get up and fight

[potatohead]

"That's an incredible waste of time !"

 

Not on an 8 bit computer, particularly when there is commented ASM code. Given that code can run on the target machine?

[VladR]

...or do it the way it's currently done.

 

Maybe just say fuck it and do a different game? You guys should read the development logs on this one. Lots of things are done for reasons that make this game great. The idea that it can be simplified or some short cut done makes very little sense.

 

And... the code is there, and it has comments. Mr Sid had to sort all that out. Now there are two sets of comments! Seems strange to just ignore all of that doesn't it?

What code ? If it`s ASM, then it's as if it didn't exist anyway

 

Do a different game ? Why on earth would someone go and do that ? There's zero point in that,IMHO...