Jump to content
IGNORED

Unicorns season: Prince of Persia for the A8!


rensoup

Recommended Posts

4 hours ago, emkay said:

The biggest problem with using graphics mode is that there is no CPU saving by reusing anything. 

So the Game has restrictions in animation and movement.

That's why I'm proposing the colorization in fields and using them as additional light FX.    

I know you worship mode4 but it would just have added complexity for PoP and perhaps taken more memory than modeE.

 

17 hours ago, emkay said:

I you look at 4:22 (for example)  : The red aura around the flask.  Very easy to adapt to the Atari. 

A two color (software) object plus some Player underlay in a darker color...

Well that's nice on a xbox but I need those PMGs badly for the player and enemy. It was messy enough to do the potion with a single color player.

Not against suggestions but I need to focus on what's going to give the best bang for the buck.

Link to comment
Share on other sites

I'll say the obvious - that it's up to the developers themselves as to what should be done or not?

If you can add extra colour or tidy up the animation here or there - where required?  So much the better.

It is up to you - as to what the decision is - all the way.

 

Comments on this forum should only be considered 'suggestions' and feedback.

Prince of Persia has been way overdue on this hardware platform, to get a version done.  And it's good to see it being done proper - and not some poor C-64 or whatever conversion transported over - which looks like that hardware conversion.

There's been amazing work done so far - so take your time to get it towards it's finishing stage(s).

We waited long enough - and can wait a bit more to see that extra spit and polish (added or not).

 

I wouldn't worry much about the turban issue or other such minor stuff.  As long as the game is responsive enough - and that it is playable - would satisfy the majority who'll get to play it.  We really appreciate the big name titles - that have been missing for so long.

 

Harvey

  • Like 5
Link to comment
Share on other sites

Just heard about this.

 

NICE WORK!

 

Love the art.  So far, that first level looks spiffy!  

 

Re:  Use feature [x] because [y] 

 

You know the drill rensoup.  Even if it's just 4 color for the play area, the art looks really good.  It will be fun to play.  So, your baseline kicks some ass.  Love it.   Do what you can / will do.  When it's done, and it will be kicking ass at that point, because it has to.  Nothing to compare it to.  :D  ...when it's at that stage, all those "use feature [x] because [y]" discussions and their advocates have every opportunity to hack away.  You know, offer up something to compare to.

 

I like this game.  It's fun, and it's historic.  Made an impact.  Will be good to see it on an Atari machine.

 

Sidebar:

 

Interestingly, 6 colors is enough to do pretty much anything.  For the last couple, few years I've been taking a break from Atari 8 bitters, and (love them, and it's just how interests ebb and flow) have been having fun with an Apple //e Platinum.  Way back in the day, as a kid, these two machines were basically my roots.  We had the Apples at school, and I had an Atari at home.  Later on, got an Apple //e at home.  Got my first start at 6502 assembly language on an Apple, and later improved on it considerably on my Atari with MAC/65, cartridge version.  Today, I have a couple young ones who are going to get that Apple school experience.  Should be fun.  Then some "Star Raiders"  Also fun, but I'm way off topic now.

 

Artifact color is a strange and interesting beast.  The Apple could do 6 colors on it's high-res screen, because of artifacts and that high bit pixel shift option.  Probably, that is why the Apple version of this game uses byte boundaries.  It only made sense.  That's where the color boundaries are. 

 

In my opinion, the Apple gets a little more help on this game from how it works in two ways.  One is there being no screen DMA.  That 1Mhz is a full 1Mhz.  No interrupts, no refresh, nothing.  Good thing too, because the complicated graphics screen was a PITA to make fast.  Despite the low clock, Apples are pretty quick, due to the CPU being uninterrupted.  And the other bit of help comes from how artifact color differs from, say ANTIC mode E.   If we ignore the 6 color vs 4 color deal, the truth is an artifact color pixel can be half the size of an ANTIC mode E pixel.   On the Atari, this can be seen in mode F, by setting the background to 0, and plotting a couple white pixels at even and odd screen locations.  What people end up seeing is a red or blue (ish) pixel there.  Two of them together will form something that looks a lot like a mode E pixel, but on many TV sets, not quite the same.  Those vertical bars can appear, and that's where the actual pixels are, with the circuits of the TV or monitor sort of filling in the rest.

 

In terms of effective resolution, there isn't any real difference.  There are only so many X positions a given color object can have on either system.  But, when it comes to art, patterns and such, the Apple and it's pretty crude TV signal, could stretch those 6 colors pretty far using patterns, and how many TV sets tend to handle color.  It can look like a lot more colors, and it can look like it has a bit more detail than it actually has in terms of gameplay, motion, and all that good stuff.  Being able to get a "half pixel" is part of what I mean here, and that can be seen in the Apple PoP art all over the place.

 

I am writing this to communicate the basic difficulty of this port.  I'm not writing it to say "X is better because" 

 

It's the little things!  PoP benefits from all the little things on the Apple and it shows.  Another place this happens to show up is the ULTIMA series of games, which put the artifact color and ability to make "pseudo detailed" art to damn good use on the Apple.  That goofy 6 color screen is enough to do anything.  A 4 color screen just isn't quite the same.  And that makes things harder. 

 

Nice work man.  I like what I see, particularly the playfield art.  

 

 

Edited by potatohead
  • Like 3
Link to comment
Share on other sites

6 hours ago, rensoup said:

I know you worship mode4 but it would just have added complexity for PoP and perhaps taken more memory than modeE.

Erm. No. ;)

If you have a look at other's text contribution, you might read that Mode D is my favor ;)

At the end the mode is the best that fits best to the game. 

PoP doesn't need much colors, and the amount of moving objects is "low". The degree of moving details, and the other given facts, point to the use of Mode E. 

 

 

Quote

Well that's nice on a xbox but I need those PMGs badly for the player and enemy. It was messy enough to do the potion with a single color player.

Not against suggestions but I need to focus on what's going to give the best bang for the buck.

 

I'm only doing suggestions here. 

But , if I was doing a game, I'd try to use as much colors as possible on the Atari. Playing more with lightning, instead of trying to enhance details. 

The BBC Version shows that less details don't kill the game. But more colors could give the game a real nice touch. 

X-Box like ;)

The Atari simply has the palette to get closer to lightning logics. 

So I would stay with a "4 color" game plus color logics and special color fx. 

 

If you want, I could do a mockup  in Grapf2fnt. 

 

 

 

Edited by emkay
  • Like 1
Link to comment
Share on other sites

Surely it's up to rensoup who's doing incredible job, and I hope he keeps his ways of doing it the best looking and as colourful "classic" incarnation of PoP.

"X-box like" light effects in Atari resolution and palette? Come on, let it stay classic, not some a freak hybrid of 80's and modern consoles.

 

Can't wait for next demo :)

  • Like 2
Link to comment
Share on other sites

4 hours ago, Jacques said:

Surely it's up to rensoup who's doing incredible job, and I hope he keeps his ways of doing it the best looking and as colourful "classic" incarnation of PoP.

 

I wonder what you'd expect.

 

 

4 hours ago, Jacques said:

"X-box like" light effects in Atari resolution and palette? Come on, let it stay classic, not some a freak hybrid of 80's and modern consoles.

Since when is the Atari a 80's and modern hybrid machine?

 

 

4 hours ago, Jacques said:

 

Can't wait for next demo :)

 

Let's wait and see ;)

 

 

  • Like 1
Link to comment
Share on other sites

50 minutes ago, emkay said:

Since when is the Atari a 80's and modern hybrid machine?

It wasn't the machine I meant as NOT being a hybrid.

I meant PoP conversion to stay classic and not a hybrid of two eras, so to forget inspiration by modern stuff: your "Xbox-like playing with lightning".

Link to comment
Share on other sites

1 hour ago, Jacques said:

It wasn't the machine I meant as NOT being a hybrid.

I meant PoP conversion to stay classic and not a hybrid of two eras, so to forget inspiration by modern stuff: your "Xbox-like playing with lightning".

 

The definition of "classic" is a weird thing. Classic is "Archon" that is using the available brightness steps on the Atari. But how "classic" is the BBC Version with it's 2018 Graphics?

If you want to have an "Atari 8-Bit" version, you'd have to find the best fit. Things like palette FX come almost for free, but there have to be tactful handling to not end up in "DLI color bleeding" as in AR: The City. 

 

Link to comment
Share on other sites

11 hours ago, potatohead said:

Just heard about this.

 

NICE WORK!

 

 

Sidebar:

 

Great info ?

 

 

 

Yes the a2 graphics mode is still a little bit confusing even with your great explanation?, but I dodged that bullet thanks to the BBC port.

Before attempting the port, from what I read on Wikipedia I figured that only black and white where effectively hires while the 4 other colors were lores so basically you couldn't move any other color than black and white at pixel resolution which is why the internal coordinate system in Pop uses 140 pixels: every sprite needs to move by 2 pixels hires otherwise the colors would flip. But that may not be entirely correct...

Same with the A8 hires with artifacts mode, a little bit confusing but I've never really needed to use it so that's ok.

 

Thanks for an interesting read!

Edited by rensoup
  • Like 1
Link to comment
Share on other sites

8 hours ago, emkay said:

I'm only doing suggestions here. 

But , if I was doing a game, I'd try to use as much colors as possible on the Atari. Playing more with lightning, instead of trying to enhance details. 

The BBC Version shows that less details don't kill the game. But more colors could give the game a real nice touch. 

X-Box like ;)

Well would much rather have skin color on the Prince instead of lighting effects. Right now the game looks too uniform. the skin color will make the characters stand out a little more.

As for the BBC version, that's actually the thing that bugged me the most (along with the predefined palette), the character are so obviously lores, it's bad. it's even more obvious because some of the frames are still there and the gap with TIX's work is huge.

 

8 hours ago, emkay said:

The Atari simply has the palette to get closer to lightning logics. 

So I would stay with a "4 color" game plus color logics and special color fx. 

 

If you want, I could do a mockup  in Grapf2fnt. 

 

Well I can pretty much guarantee you 99% that I'm not going to use it (skin color first!) but I'd be curious to see it (who knows, maybe it could be used for something else)

  • Like 1
Link to comment
Share on other sites

23 minutes ago, rensoup said:

Well would much rather have skin color on the Prince instead of lighting effects. Right now the game looks too uniform. the skin color will make the characters stand out a little more.

Spot on :) With just 1 more colour on Prince and enemies (if possible), the game will look much less "monochrome", although it already looks very good. 

  • Like 1
Link to comment
Share on other sites

1 hour ago, rensoup said:

I read on Wikipedia I figured that only black and white where effectively hires while the 4 other colors were lores so basically you couldn't move any other color than black and white at pixel resolution which is why the internal coordinate system in Pop uses 140 pixels: every sprite needs to move by 2 pixels hires otherwise the colors would flip. But that may not be entirely correct...

That's basically correct.  It all comes down to the way the Apple and Atari generate their color signals.  Both computers used a fixed color phase, not alternating and they did per scan line timing so that all the artifacts stay consistent.  It was all about avoiding the dot crawl, or shimmer that can be seen on high contrast visuals.  Text and computer graphics definitely qualify.  Minimizing color fringing artifacts is also why the Atari defaults for text are White on Blue.  It's also why text fonts are done with two pixels everywhere possible.  The Apple ones are single line, and are a total mess when the color is on.  That difference probably boils down to the Apple targeting composite monitors, which were mostly monochrome, and the Atari targeting a TV.    

 

In Atari terms, ANTIC E has one pixel per cycle of the color signal.  One pixel can be any color, almost entirely artifact free.  All the color info is there for the pixel.  The Apple artifact colors line up the same way, because it's the same color cycle.  The only real difference is 7 pixels per byte (which made things a huge mess regarding color and sprites), and at 40 bytes per line, results in 140 pixels, not 160 like the Atari.  And the screen widths show the difference.  Apples have a more narrow active graphics window due to that 7 pixels per byte arrangement.

 

On an Apple, even and odd bytes artifact differently too.  Pre-shifted sprites either need to account for that difference, or the draw routine needs to handle it.  On an Atari, every byte artifacts the same, because 8 bits is even, and 7 bits is odd.  I am pretty sure, and should check again this weekend, that means toggling the high bit differently based on byte being even or odd to see the intended color.

 

Because of all that, color positioning is half the resolution = 140 pixels / line.  And the PoP internals reflect that.

 

The Apple screen draw routines use a lookup table to get all the Y screen positions.  That is due to the crazy memory map.  It's linear per line, otherwise, the lines have a more complicated start address.  And there are even holes in the screen.  Bytes are in the screen memory page, which is fixed, and are not displayed.  Woz could save a chip and did, which is why all that is true.  This crazy mapping can be seen when a high-resolution image is loaded from disk.  One can see the bands of addressing play out as the entire screen fills in narrow horizontal bands.

 

I'm only dropping that info here to highlight how bad ass Mechner was to have produced this title on a 128K Apple.  :D

 

1 hour ago, Jacques said:

Well would much rather have skin color on the Prince instead of lighting effects.

I very strongly agree.  It's not much, but will totally make the game pop.  Seems like a reasonable expectation too.  The other obvious choice is pretty grim, which is to hold a color for the prince and enemies, which would compromise the pretty great playfield art.

 

Anyway, cool beans.  Have fun.  I am eager to see the final outcome.  

 

Edited by potatohead
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

BTW, while we wait for great home brewers to do their thing, I've been watching this project:

 

https://www.facebook.com/LawlessLegends/

 

They made a mini-game, which I played through.  Excellent.  I'm linking it to show off the killer artifact art.  I think LL is very close.  Playtesting going on.  Fingers crossed.

 

Now, there are two we can look forward to in the future.  I am gonna have to score a 128K Atari...  :D  

 

 

  • Like 2
Link to comment
Share on other sites

16 hours ago, potatohead said:

 

 

The Apple screen draw routines use a lookup table to get all the Y screen positions.  That is due to the crazy memory map.  It's linear per line, otherwise, the lines have a more complicated start address.  And there are even holes in the screen.  Bytes are in the screen memory page, which is fixed, and are not displayed.  Woz could save a chip and did, which is why all that is true.  This crazy mapping can be seen when a high-resolution image is loaded from disk.  One can see the bands of addressing play out as the entire screen fills in narrow horizontal bands.

 

 

 

Much new stuff (not) read ;)

 

The Memory Alignment of the Apple Graphics is similar to the Atari Character mode. The difference is that every 3 lines the character were read new by the graphics chip .

This is where the Atari has to use a DLI for new character content every three Character mode lines. So there are 8  characters left. Using that mode (including DLIs) on the Atari allows about 1.2MHz of CPU speed.

So from that point, it is no big deal to convert Apple Stuff to the Atari.

The graphics has to be rebuild and resized to fit to the game then.

 

That mode on the Atari allows up to 9 colors without any complexity.

 

Remember?

 

 

 

 

 

Edited by emkay
Link to comment
Share on other sites

Emkay, let's see something nice, and simple.

 

Breakout, software sprite for paddle, ball.  Moving consistently, frame by frame.  Each row of bricks 6 or more colors, bonus points for each column seeing six or more colors too.  I won't respond to advocacy for that DLI heavy mode again, until I see something in motion.

 

Edit:  And I'm asking, because back in the day, when I had an Atari and an Apple, I tinkered with various schemes.  When one uses the CPU to dynamically alter the display, that is normally associated with a VBLANK routine to sort what may need to happen, cycles consumed during screen, the screen DMA, and RAM Refresh.  All those tend to add up.  

 

Here's the thing:  Memory back then was basically a couple Mhz.  An Apple will fetch, either 40 or 80 bytes per line, without stalling the CPU.  That 1mhz clock allows for a simple sharing scheme.  Top half of cycle on CPU, bottom half on refresh / video display.  Ataris run faster, but do interrupt the CPU for refresh and graphics access.  And, BTW, true to the colors = memory cycles required per line, an Apple can do a 16 color display at 140x192, when it's fetching those 80 bytes.  Due to how it's clocked and constructed, that happens with no cycle mooching from the CPU.  Still a full 1Mhz.  But, the trade-off made there was more screen complexity.  An unaccelerated Apple can't do much motion on that 16K graphics screen.  The 4Mhz ones can, and it's spiffy, but that's wandering way off topic too.

 

Point being:

 

If an Atari is displaying more colors, it's either at a lower resolution (GTIA), or more CPU time will be consumed somehow during graphics display.  There is no getting around all of that. 

 

This is true again because colors = memory cycles required per line period.  One can buffer them, C64 bad line style, or simply mooch them every line, or make two memory busses Apple style, or run with a bit faster RAM, Color Computer 3 style.  (That one can actually do a 256 color artifact display without slowing the CPU.  Super spiffy, and basically unused, which was sad.  But, maybe someone will one day.  See my blog for some sample images produced by Jason Law when the two of us were seeking to demonstrate this to the CoCo community some years back.)

 

This particular game is blasting a lot of pixels for animation.  That Mechner got it at 1Mhz on an Apple with the frame rate he did is impressive.  And one look at the draw code, which is published today, shows it was non trivial.  All the cycles are needed.  Big sprites in motion are the most taxing thing on 8 bitters that lack sprite systems capable of big objects.  All that masking, draw order sorting, etc...  simply has to get done, or there is flicker, or the frame rate goes way down.

 

If this display scheme is not too crazy, then a simple, software sprite production should not be difficult, and should leave ample CPU free too.  So, let's see it.  If what you say is true, maybe there are cycles enough for a PoP type production.  Nobody knows.  It's real work to find out.  So do some,  A soft sprite Breakout game, with a reasonable color set, and good motion will tell the tale nicely enough without being a super serious amount of work.  And you have been asked this by others.  The reason is simple:  That real work could be put toward completing a nice PoP port, or it could be put into a dynamic screen display scheme that may or may not (likely not) result in enough cycles left to do the nice PoP port.  

 

Our OP wants to complete a nice PoP port, not invest in a dynamic display scheme that is more likely not to lead to a nice PoP port.  This is entirely understandable and reasonable.

 

Otherwise, the lack of productions very strongly suggests there simply will be an Achilles Heel in there somewhere.  I have my suspicions, but prefer proof be in some pudding.  Let's see it.  Start a thread.  I'll even make sure my Atari is warmed up, and out of storage to evaluate it all too.  I stand eager to do that.

 

Now, like I said, I won't respond again.  No need to pollute this thread.  Honestly, I would strongly advise anyone not to respond, until you put some real skin in the game.  Breakout.  It's not hard.  We all can code it.  

Edited by potatohead
  • Like 3
Link to comment
Share on other sites

55 minutes ago, potatohead said:

 

Now, like I said, I won't respond again.  No need to pollute this thread.  

 

So why did you start with it? 

It is as I wrote above. This "6 to 9" color mode has still more CPU free than the Apple II has at all. And 6 colors can be used everywhere on the Screen. It is even possible to do Basic Games in that Mode than run fast enough. 

Artefacting is also not a problem to the Atari on an NTSC System. AND !!! It can use the colorization in hires using the PMg.

On the other Hand, is there a PAL Apple 2 available?  

 

 

 

 

Link to comment
Share on other sites

25 minutes ago, rensoup said:

A bit tangential to this...  we can't do too many colors in the game but what about the princess room ?

 

There's nobody doing background art on the project so perhaps someone on here would be able to create a super colorful mockup in G2F ?

 

 

That does only make sense, if the person who is going to do that knows about the engine's functionality.

As there are "two" moving objects needing their separated colors, the room might be build on background graphics only?

The colorization needs to be clear, to set the environment to a "similar" scheme.

How many DLIs would be allowed ?

.... and so on

 

 

Link to comment
Share on other sites

5 hours ago, potatohead said:

 

Now, like I said, I won't respond again.  No need to pollute this thread.  Honestly, I would strongly advise anyone not to respond, until you put some real skin in the game.  Breakout.  It's not hard.  We all can code it.  

 

Funny edit of your pollution post after been quoted ;)

What exactly do you want? That crappy Apple 2 Breakout as a mockup in G2F ? Or something more sophisticated?

Link to comment
Share on other sites

4 hours ago, emkay said:

That does only make sense, if the person who is going to do that knows about the engine's functionality.

As there are "two" moving objects needing their separated colors, the room might be build on background graphics only?

The colorization needs to be clear, to set the environment to a "similar" scheme.

How many DLIs would be allowed ?

.... and so on

Regarding engine functionality:

  • It has to be ModeE because the sprite code is for that format... the sprites can use PMG overlays as well.
  • DLis: whatever is needed, it's not like the palette needs to change each scanline, it's ok go kernel style for a few scanlines and stuff in as many colors changes in the bed/cushion area.

Those are the constraints I can think of.

 

 

Edited by rensoup
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   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   1 member

×
×
  • Create New...