Prince of Persia

[potatohead]

http://fabiensanglard.net/prince_of_persia/

[popmilo]

You are more than welcome to give it a try! PoP on A8 would make bunch of people happy

...My initial plan is to take the original source code analysis together with the analysis made by MrSID (C64 port). Correct me if I am wrong, but it seems that he didn't release his source code, anyway there is invaluable help in his development blog.

MrSID worked from Apple 2 binary data and used graphics converted from PC. That way he skipped 'problems' with strange apple 7bit 6colors graphics.

On the other hand he had to pair graphic tiles and sprites manually. Lots of work anyway...

 

ps. There are links in his blog to couple of resources like extracted apple graphics. Think it wouldn't be strange for him to just upload source code if we ask him nicely

[Franco Catrin]

 

Finally, here is a code review. This is NICE! It didn't exist before. Reading it now.

 

WOW This one?

 

http://fabiensanglard.net/prince_of_persia/index.php

 

Fabien Sanglard had made many code reviews, the guy is a god!

[Franco Catrin]

Sadly, Fabien Sanglard stopped the code review too early. Anyway there are good sources available.

[potatohead]

E-mail him about it. I just did.

 

Who knows?

 

A quick glance through the comments and searching related to that partial code review shows how this game influenced a lot of people. I've kept an Apple around just because of it. Other things too, but it's just beautiful.

Edited April 7, 2015 by potatohead

[pusakat]

 

And that one can build games for Atari. Bill Budge did this, among others. Write Apple version, then modify for Atari. (which is why some Apple games never really used Atari specific resources....)

 

 

Bill Budge put up both the Apple and Atari source code for Pinball Construction Set on GitHub. https://github.com/billbudge

https://github.com/billbudge/PCS_Atari800

[popmilo]

Well, after couple coffees and some free time here is something to show:

Hires sprite:

 

Simple NTSC color artifacted emulation:

 

BG tile 68 hires:

 

BG tile 68 color:

 

Small python script can extract all images from any of original Apple 2 source files.

As in game every image can be drawn with different methods (flip, mask, shift etc...) visualization is not 100% correct.

 

Ntsc artifacting works at hires resolution so it does not represent what could be possible with Atari specific conversion routine. That I'll try next

 

pps. Here are all images in zip file.

images.zip

 

[popmilo]

My available time is variable, last year I released a pair of "big projects" in my free time (17 calendar months total), so a timeframe of several months is not something I would be afraid of. If you want to help fix bugs, that would be great.

Installed your RetroBoxTV project just now. Looks and works great !

If you do similar work on A8 that will be great

ps. Welcome to the AtariAge btw!

[Franco Catrin]

Well, after couple coffees and some free time here is something to show:

 

[..]

 

Small python script can extract all images from any of original Apple 2 source files.

As in game every image can be drawn with different methods (flip, mask, shift etc...) visualization is not 100% correct.

 

Ntsc artifacting works at hires resolution so it does not represent what could be possible with Atari specific conversion routine. That I'll try next

 

pps. Here are all images in zip file.

images.zip

 

 

Just in time!

Tonight I was checking the graphics from the PC version (VGA) and they are too far from what an Atari version may use. Can you share this python script?

 

Thanks

[Franco Catrin]

Installed your RetroBoxTV project just now. Looks and works great !

If you do similar work on A8 that will be great

ps. Welcome to the AtariAge btw!

 

Now that you mention it, I fixed the famous "16 bit sound" bug in the Atari800 emulator. Not sure if the trunk version has that fixed. There was a problem in a division result where calculating the buffer size, which sometimes resulted in an odd number, so the buffer never gets filled and the sound never get thrown to the audio device. Well, thats another topic.

 

RetroBoxTV 2 will be released soon BTW.

[popmilo]

 

Just in time!

Tonight I was checking the graphics from the PC version (VGA) and they are too far from what an Atari version may use. Can you share this python script?

 

Thanks

Of course! If you need any help or have some ideas on how to convert PoP, let me know.

 

First part in decoding original data was extracting raw byte values from files. Fortunately format of data is described in one of the documents on github project page.

 

Second part was converting raw bytes to something visible. First I did conversion to hires. As I've seen that highest bit was set on most of images, I've simply ignored it and constructed images from 7 bit segments.

 

Third was converting that hires image into something resembling kind of ntsc artifacting emulation. That meant finding if set bits are on even or odd columns, coloring pairs of pixel with one of Apple colors and coloring pixels white where more than one pixel is set next to each other.

 

Here is source code (I tested it as ipython notebook, but even if you don't use that or Python you'll get the point on how it works).

a8pop_tile_extractor.py.zip

[Franco Catrin]

Thanks popmilo!

 

I thought that EGA planes where weird, didn't know about Apple II graphics system!

 

I'm using a mix of many sources for my initial graphics testing. I'm using the Apple Graphics tiles because they are mapped 1 to 1 with the list published in Jordan's PDF. The graphics extracted by your script seems to be inverted horizontally, and care must be taken before using them because some of them are masks to be applied, and others use a specific bit wise logical operation.

 

I need help to understand two things:

 

1) I'm testing with the first background set (dungeon). According to the file format, there is a header pointing to each tile and each one of them has two bytes with the width (in bytes) and height, then there is graphics data. I found this weird data (tile 1 is the first)

 

image[47].offset = cc0 3x10

image[48].offset = ce0 3x10

image[49].offset = e00 230x209

image[50].offset = d20 3x10

image[51].offset = d40 3x10

Look at tile 49. In your extracted bitmaps this is 3x10, and the offsets are consistent with this 3x10 size, but in the file downloaded from git I have 0x8C, 0xD1 at 0xE00. I downloaded the file using git clone and then using the web browser with the same wrong data. What do you have in your file?

2) Apple II color graphics are insane. For what I can understand, the MSB bit indicates what color group will be used in "01" and "10" cases, then only 7 bits will be used for pixel data. Combinations of 00 means black, and 11 means 0, but how should I interpret this binary data (MSB = 0)?

 

00000001 01000000

 

Taking the MSB out:

 

0000001 1000000

 

Will this be black pixels, one white pixel and then black pixels? how many black pixels?

Or this will be 3 black pixels, one "10" pixel, another "10" pixel and 3 black pixels?

 

Thanks in advance

[dmsc]

Hi Franco!,

 

2) Apple II color graphics are insane. For what I can understand, the MSB bit indicates what color group will be used in "01" and "10" cases, then only 7 bits will be used for pixel data. Combinations of 00 means black, and 11 means 0, but how should I interpret this binary data (MSB = 0)?

 

00000001 01000000

 

Taking the MSB out:

 

0000001 1000000

 

Will this be black pixels, one white pixel and then black pixels? how many black pixels?

Or this will be 3 black pixels, one "10" pixel, another "10" pixel and 3 black pixels?

 

Thanks in advance

It isn't as insane as it sounds, the problem is the people describing it :-)

 

The hi-res mode is 280 pixels wide, and each pixel takes half a "color clock" width. This is the same as NTSC ataris, but narrower (280 instead of 320). The 280 pixels are the 7 lowest bits of each of 40 bytes. If you use a B/W monitor, this is all that you see.

 

If you use a color TV to display the image, the same artifacts are shown that in the Atari: each pixel alone is seen as a short color pulse by the TV and decoded as a colored pixel of about twice the width. And if the pixel is at odd positions is seen as blue, and at even positions is seen as orange. But two white pixels blend and show only white (with some banding at left/right).

 

Now the oddity: the MSB of each group of seven pixels alter the NTSC phase by delaying the signal a quarter wave. This means that the orange/blue is replaced by purple/green in the seven pixel group.

 

See more explanation in http://www.lazilong.com/apple_ii/a2pix/dgr1.htm

 

Daniel.

[Franco Catrin]

THE BEST explanation that I have read!!!

 

Now I'm decoding the graphics as expected!

 

 

(Apostaría a que eres Daniel Serpell)

[Franco Catrin]

Hi guys!

 

I just wanted to share this first rendering of Prince of Persia for Atari [*]

 

This is not just a screenshot, it's real code running against the original Prince of Persia data. I've taken the graphics posted here to recreate 4 "tiles" using the "ABCD" rendering method, then I run the logic for the first screen on level 1 (level 0 is demo).

 

I know that there are errors. This is the first run and I'm surprised that it worked in the first try!

 

 

[*] NOTE that this is not 6502 code yet. For testing I have implemented a small emulation library to write code in Java against the Atari graphical restrictions (4 colors per line, 4 pixels per byte, DL and so on). Once I got the high level routines working, it will be easier to take them to the 6502.

 

[Heaven/TQA]

Cool.

[Franco Catrin]

New update!

 

Testing the rendering in several screens of level0. There are many graphics missing, but it's nice to see at this stage.

 

http://screencast.com/t/nrOw53Ed6

[José Pereira]

Can you kindly post here some/any of the screen(s) because I'm far away from a computer and it needs Adobe Flash Player that I can't install in this old damn mobile phone.

Thanks.

Edited April 11, 2015 by José Pereira

[popmilo]

Can you kindly post here some/any of the screen(s) because I'm far away from a computer and it needs Adobe Flash Player that I can't install in this old damn mobile phone.

Thanks.

Here are some:

[popmilo]

The graphics extracted by your script seems to be inverted horizontally, and care must be taken before using them because some of them are masks to be applied, and others use a specific bit wise logical operation ...

Must admit I was puzzled with that once you pointed it out. Kind of went over it when I was coding it as I was focused on extracting data from original files and thought there is some strange reason for it. And then this morning I've remembered reading Apple manuals in high school and how it seemed strange that hires screen bit order is different from any other computer at that time

 

These new screenshots look great!

How do you convert Apple pixels to A8 4-color mode ? Some kind of resampling or maybe something simpler ?

 

Great work!

 

[Franco Catrin]

These new screenshots look great!

How do you convert Apple pixels to A8 4-color mode ? Some kind of resampling or maybe something simpler ?

 

 

I'm not using the Apple data directly. I'm using them as a reference for identifying which graphics I need to paint each block.

The Apple data files are in sync with the documents released by JM, and I can make a match "easily". For example the PC version has different graphic maps and I cannot map them directly AFAICT.

 

Another problem with the Apple graphics is that they use squared pixels, 7 bits per byte and 6 colors in some cases. It will be hard for an automatic method to give good results. At least not as good as the drafts published at the beginning of this topic.

 

So I started with those hand made graphics, which I found awesome. I splat them in 32x63 blocks, resize them to 16x63, and then I have converted them to the special drawing method of prince of persia. It's not a direct tiling method, there is an order in which each graphic must be rendered, and there masks and shifts included. That restriction throwed away any intention to use char based graphics, simply there many combinations to cover.

 

Next step was to load the level data and run the algorithm with some graphics, that is what you see in my first screenshot. Then I began to add more graphics, fix some rendering edge cases, and so on. Then I tried the algorithm to render any scene, that is what you see in the slide show.

 

Now I began to add other missing graphics using the same atari graphics as a reference of "technique", and the PC graphics as a reference of dimensions and colors. The PC graphics are more similar to the graphics that you can have in Atari (using 160 pixels per line).

 

It's a slow method, but very enjoyable. It's like completing a Jigzaw Puzzle. You add a graphic and the screens are more and more richful each time.

[José Pereira]

You're going very well.

Apple2 and C64 use 3x63 scanlines that is 3floors more 3scanlines at the top that is the previous screen bottom floor. This gets into the Apple2 192scanlines screen.

You said that you can't go into charmode, right?

I converted all gfxs level maps so that you have 3x64 and that top is 8scanlines, in total turns into 200scanlines/25charlines and it is all of those gfxs chars alligned. If you use this then would it be possible that you can get things running in ANTIC4/GR.12 charmode?

I did all this on the past soo that I can have the very usefull PF3 colour register for the fire on the torches.

I have things like this:

-> PF0: white for all the game (we'll need it for the prince, enemys and skeleton)

-> PF1: dark luminance colour

-> PF2: middle luminance colour

-> PF3: yellow [EE] - torches fire colour

(this way and like on C64 changing PF1 and PF2 to get different levels colours)

 

If you want to see I can post/send you what I have. This is just because I am right now thinking in how will you colour the torches fire...

Edited April 12, 2015 by José Pereira

[Franco Catrin]

Let me see those graphics. May be I don't need to continue drawing (it's not my strength).

 

I discarded using chars at the moment. Take in account that each level has more than 128 graphics, and many of them are larger than 4x8 pixels. They are mixed in several ways. I can tell you because I had to make several little adjustments to get the rendering right, including shifting and masking.

 

If that's not enough, PoP has transient graphics, like floors falling, spikes going up, and so on. In this game, rendering speed of the background is not that important, because there is no scrolling. I think that taking the char route will put too much complexity upfront. Let's make the thing, we can do optimization later.

 

I wouldn't care about the torches yet. If their fire move, the color would not be that important.

[José Pereira]

I'll send you probably by Monday.

Yes you can't go with one charset.

What I did and what was talked is that using what I usual talk over here as Interleaved Charsets that on PoP will be 4. They work like this:

Each floor is 64scanlines that is 8charlines so on eachone you'll have:

-> Charline1: Charset1

-> Charline2: Charset2

-> Charline3: Charset3

-> Charline4: Charset4

-> repeat these charsets in the same order for the other floor charlines.

(the floor at the top is charset 4 - previous screen charline8)

 

Using this way you have map if I remember it right as about around 80chars on each of these charsets and that gives you space for the guys soft sprites.

But I also have game gfxs somewhere to be in bitmap mode. I will search it and then I'll send you together with the guys sprites :-).

[potatohead]

Re: Converting apple graphics.

 

For one, they don't convert well, due to the pixel art often taking advantage of single pixels having color. Think about graphics 8 vs graphics 15. In graphics 8, we get 320 pixels, and a single one of those can be turned on, and it will appear as red or blue, assuming a black background and white foreground. In the 4 color modes, a single, small pixel, can't ever be turned on. There are only 160 pixels, but they have four palette colors.

 

So the Apple art loses some detail because of this.

 

However, if one did want to convert, the 7 pixels per byte means having to work with a whole scan line, or two bytes minimum to convert. There are even and odd bytes. This means even bits in an even byte will show as one color, say orange, and those same bits in an odd byte will appear as another color, say green. This is because the number of pixels per byte isn't even. It also means Apple games require two sets of images, or they need to perform some shift kind of operation while drawing.

 

Working with two bytes, back to back, helps, because that bit pattern will work across the screen and a color translation to 4 color modes will make a lot more sense.

 

The X is the high bit, used to color select.

 

x1001000_x1001000

-eoeoeoe_-oeoeoeo = 14 screen pixels

 

The "-" is not displayed, "e" and "o" represent even and odd pixels as seen on the screen, which represent two colors. The "_" is just there to separate the two sequential bytes. Notice how the same bit pattern presents as different colors?

 

Most other computers, and for sure the Atari, have 8 bits per byte that actually are pixels. The trade-off is only getting two artifact colors, but the gain is the same bit pattern displays the same colors no matter where it's at on the display.

 

01001000_01001000

eoeoeoeo_eoeoeoeo = 16 screen pixels.

 

That's the difference, and why conversions don't map directly to other machines.

 

The actual pixels themselves are basically the same size. There are just less of them on an Apple display, due to that high bit being used as a color shift, not a pixel. 40 bytes per scan line for both machines.

 

Of course, this all makes draw routines on Apple computers complicated. A look up table for "Y" addresses makes sense, and is fast, and common to a lot of machines. C64, Atari, etc... The Atari has linear bytes, which make for a fast, simple draw routine. The Apple is messy because of how the even and odd pixels work out. Two bytes of shift data are needed. The C64 has it's high resolution pixels ordered for fast character drawing. Linear bytes stack vertically on that one. So it needs lookups in both directions, or clever draw ordering...

 

@Franco: Nice work so far man!

 

IMHO, using the Apple art as a reference is best, because of the single, high res, color pixel being possible on a high resolution screen, but not on a 4 color screen.