Wich one of these two Prince of Persia you prefer?

[emkay]

That's something to start with. Nice.

 

 

 

While the PAL machine seems to have the possibility of a 50fps game, the NTSC for sure needs a drop down to 30 fps.

 

This explains much. As most games were done for NTSC machines.

Edited November 3, 2011 by emkay

[Rybags]

Throw in pillar masking and the PMG processing and it'll soon drop below that.

Then there's almost the entire same process for an enemy.

Not to mention animation and movement of the dungeon objects, and enemy AI and other processing.

 

25 FPS is acceptable. It'd be better to have a constant FPS with speed drops only when it's real busy than one that wildly fluctuates.

[popmilo]

...25 FPS is acceptable. It'd be better to have a constant FPS with speed drops only when it's real busy than one that wildly fluctuates.

Yes. 25fps in PAL should be doable without any problem.

 

You might noticed how stable the time spent is. As I used tables for shifting, sprite routine always takes same time (does not depend on shift position).

 

Next step is masking so I would hold my breath till than

 

ps. And what's all that fuss about NTSC ? I have PAL 800xl, why doesn't everyone else ?

[emkay]

Throw in pillar masking and the PMG processing and it'll soon drop below that.

Then there's almost the entire same process for an enemy.

Not to mention animation and movement of the dungeon objects, and enemy AI and other processing.

 

25 FPS is acceptable. It'd be better to have a constant FPS with speed drops only when it's real busy than one that wildly fluctuates.

 

When doing the "complex" version, sure. As we know, even 25fps were not needed for the game.

Using "my 3 colour per object" solution, makes just some dli code (or vcount programming)necessary, for adjusting the PM shapes, foreground (Pillar)handling not needed. 50Hz could get suitable.

[Rybags]

Additional - I forgot to mention that if mirroring is required, ie - both facings not kept in ROM, then that adds more time.

[Rybags]

The game emkay envisages has already been produced:

 

http://www.youtube.com/watch?v=oezBzU6PpRg

[emkay]

Depending on "how the game is done for the apple", it surely will run better on the A8.

Just like putting the protagonist that far behing a Pillar/Wall when climbing up, you simply don't have to draw it. How could it get faster?

[emkay]

The game emkay envisages has already been produced:

 

http://www.youtube.com/watch?v=oezBzU6PpRg

 

You're a funny guy.... sometimes

[sack-c0s]

Throw in pillar masking and the PMG processing and it'll soon drop below that.

Then there's almost the entire same process for an enemy.

Not to mention animation and movement of the dungeon objects, and enemy AI and other processing.

 

25 FPS is acceptable. It'd be better to have a constant FPS with speed drops only when it's real busy than one that wildly fluctuates.

 

I don't think pillar masking will cause much hassle - as far as I can see pillars are always a multiple of a byte wide, so you just drop those columns of bytes. I reckon being partially obscured by a column would be one of the faster rendering cases. The gates are going to be a kicker though.

[tinctu]

Well C64 have PoP... Well maybe "Aladdin" or our "Xeladdin" will be better alternative to them...

 

 

They will not criticise our Prince Of Persia... I am not coder. I can do music and title graphics only...

 

And Aladdin is on 8bits too... And maybe there are spritesheets, sprites on internet...

 

Nintendo NES

youtube>

http://www.youtube.com/watch?v=8es_5oQkNOc&feature=related

 

Sega Master System

youtube>

http://www.youtube.com/watch?v=XWwgY2CVKTE

 

Gameboy Color

youtube>

http://www.youtube.com/watch?v=AXzYtHDWwqk

 

;o)

Edited November 3, 2011 by tinctu

[potatohead]

Why are we talking about a 50Hz game? For that matter, why even discuss 25?

 

Unless there is a plan to update the animation data, there is no need to update the screen every frame. The balance of the game, in terms of how it plays, movement, etc... would be seriously disturbed running that fast.

 

Re: "better than the Apple"

 

In terms of just software sprites, yes! The Atari is quicker, and it's got a nice screen layout, and memory options not present on the Apple.

 

In terms of the display? Debatable. The Apple hi-res screen is goofy, but very effective. 6 colors are available on byte boundaries, and because the Apple does artifact color, it also has pixel art advantages as a color pixel can be both wide and narrow. Atari's only have 4 artifact colors, if the pixel size is a consideration. On the hi-res screen, the Apple is superior because of that.

 

If things are done in color mode on the Atari, which the Apple basically doesn't have, then more colors are on the table, as well as palettes! Palettes are a clear strength for this title because the display can have a lot of texture in terms of color. However, resolution then is fixed at 160 pixels, requiring some changes to the art. Those have been done, and there are nice options. IMHO, these are just differences.

 

The cost of color mode is having to use complex display manipulations to exceed 4 displayable colors. All in all, the Atari will do the play of this game very nicely, but the cost will be display work and cycles spent which brings the CPU speed advantage down to a level that's not such a clear advantage.

 

Apples may run at 1Mhz, but they do not have CPU cycle wait states for video access. Once all the DMA cycles on Atari are accounted for, and the cycles needed to manage the display get added, overall throughput for a given frame isn't so different from the Apple, particularly given the need for either software sprites on both machines, or complex manipulations of the hardware ones, or those manipulations for a combination of both.

 

One very nice element in play here, ignored consistently for some reason unknown to me, is the game runs about 15Hz tops, and that's just great!

 

For reference, cartoon animation is 6-10 FPS, with a lot of them being 8. Higher quality toons hit 15, with the newer CGI productions up to 30 where it makes sense.

 

This game isn't a twitch game, and a whole lot of what makes it a lot of fun, and a classic, is the animation and how that connects to the environment. It was a significant accomplishment on the Apple, and for the time it was written. Citing "50Hz being possible" is just goofy, given how the character motion is done, and why it was done that way. Have some of you just not read the development blogs on this one?

 

Please do go and do that. They are a great read, both the original and Mr. Sid's work in progress. Your appreciation for this title will incorporate some of the more subtle elements, and ideally render a whole bunch of this discussion moot.

 

The Apple game is great in 6 colors. It's great because of the pixel art, and because of the animation, and those colors being just flexible enough to make most things possible on that machine. The color scheme proposed by Jose' is a great balance that would put similar results on the table. Frankly, that is all one would need to make a great conversion. Some polish when it's done, and use of the larger color space on the Atari would more than make up for some limitations in overall detail color placement on this title. Color placement that isn't really necessary to do a great job on this game.

 

As far as the Apple goes, I find it quite interesting to see the sheer amount of work required to even reach PAR with the lowly Apple ][ Yeah, it doesn't have custom chips, but it also doesn't have DMA to contend with, unless somebody has put a DMA capable card in there. What the Apple does have is great design and a very nice balance of features that turned out to be very competitive, despite the age of the design.

 

Later models fully exploited that simple design to deliver higher resolution dot-addressable graphics than most all of it's peers, and 16 color any pixel anywhere graphics.

 

Point here isn't to go bashing on non-Apple machines. The point IS one can't just write something off because it was done on the Apple, that's all. Not a solid assumption all things considered, which does not appear to be the case here, more than it does.

 

Sound? Yeah, Ataris have a lot of great sound options. No brainer, IMHO. In the words of the author of this title, "This machine is such a piece of shit!" referring to sound. LOL! Spot on, unless one has a Mocking board installed.

 

**On a side note, somebody needs to build a card to place the favorite sound chips inside the Apple. What a hoot that would be! Stuff a POKEY, SID and YM chips (found on Mocking board anyway, I think) and go to town! And that's the beauty of the Apple machines. Pack it on the card, and stuff it into the machine. Nice.

 

(goes back to watching this with morbid interest, hoping some people here just go and do some fun reading)

Edited November 3, 2011 by potatohead

[emkay]

Yawn...

 

Ofcourse 15fps were mentioned and debated. On 60Hz machine the best choice (60Hz / 4).

Having a different count of frames means to redraw the sprite data , or to have the animation at a wrong speed.

If this ridiculous NTSC "artefacting really counts for colours, well, make a version with artefacting colours, and use the available "10" colours (player colour + through-shining colours of colour 1) and the resulting artefacting colours of that.

Enough resulting colours in hires to feed 2 C64

 

Btw: If an Apple is rotten, throw it away , otherwise it could make you ill

[potatohead]

Why throw Apple machines away? They are GREAT machines! Great in ways different from Atari machines, similar in some ways too.

 

Since I'm in the mood, let's talk about "counts for colors"

 

Is it ridiculous because, say the Atari machine doesn't do it like the Apple one does? Maybe a nice 16 color any pixel anywhere 140x192 screen is just out of reach? Or is it simply that it's a real bitch to put more than 4 colors up on the high resolution screen, with placement flexibility like the Apple has. The first color cells appeared on Apple computers., just FYI.

 

Then we get to "doesn't count for colors" So, tell me what does?

 

Now, I did run a few artifact tests on my Atari 8. 4 colors is doable. Now, on Atari machines those colors are inconsistent, due to how the machines varied in some ways. Maybe that's part of ridiculous? Apple computers do not vary, generating the same colors every time.

 

That variability aside, I got some interesting results. Where it kind of breaks down is the background won't stay black, or maybe I didn't use the right combination of PM / GPRIOR, etc... It DOES generate some more colors though, and I suppose somebody could get a kernel written to get some zones where more artifact colors are seen. Won't be straight up easy though, which was my point. Maybe some potential there. Deffo worth a look.

 

But that's just a side note. How do they not count for colors?

 

Here's a noodler for you. Do the lo-res colors count as real colors in your opinion? If so, how are those different from the hi-res colors on Apple?

[emkay]

Connect that Apple thingy to a PAL TV set and get some "nice dots" .

Connect an Atari PAL TV set, use colour mode and get the colours.

Connect the Apple via S-Video? hum...

 

[potatohead]

Oh, is that it?

 

Well, pity. Very enjoyable machines really. Too bad you've got shit displays. Picky things. At least that explains things.

Edited November 4, 2011 by potatohead

[José Pereira]

The Apple looking on PAL I don't know (would like to see someone show some examples, just for the curiosity) but about A8:

NTSC with Artifacting (something like Apple):

The same if you Load it on a PAL T.V./Machine:

 

Where's the colour Mode on PAL?

You have to make all the game from the begining in 2:1ratio:

Edited November 4, 2011 by José Pereira

[emkay]

Oh, is that it?

 

Well, pity. Very enjoyable machines really. Too bad you've got shit displays. Picky things. At least that explains things.

 

I was always wondering, how someone could watch to that false colourwash, named NTSC. While PAL TV sets always had good colours.

And with splitted chroma/luma, you can have clean readable hires and straight colours. Not that always coloured "hires".

[potatohead]

Yeah Jose' PAL artifacting works much differently, and it's not compatable. NTSC artifacting basically allows color on high resolution graphics. Even pixels are one color, odd pixels are another color, like blue / red, or green / cyan, depending.

 

On the Apple computers, there are 7 pixels in a byte, they can artifact to either be color pixels, which they are as long as they are not adjacent, or solid black or solid white, if they are adjacent.

 

The high bit in the byte shifts the display slightly, allowing for two other colors.

 

A high-res screen then is basically a 6 color screen. There can be 4 colors per byte, and those are either: black, white, green, cyan or black, white, blue, orange(red). Technically, the black and white colors are different between the two sets, as they are shifted slightly from the other set, by a quarter pixel to create the alternative colors.

 

PAL displays have different clocks, and so then act like S-video ones, meaning no colors are seen.

[potatohead]

Well, I've got both displays here. NTSC and PAL.

 

PAL is the more picky display. The device driving it needs to output a very precise signal. PAL has color flicker across frames, as alternating phase takes two frames to complete. The downside is 25Hz color, the upside is very nice artifacting, like the Project M. I find the adjacent frame color scheme distracting on some color combinations, though I do find it very enjoyable for movies and such.

 

NTSC displays anything close! I like the horizontal artifacting as lots of great color tricks are possible. I don't like the lower vertical resolution, but I do like the higher frame rate, and 60hz color resolution possible. Atari computers, in particular, have great, rock solid, fast motion colors. Then again, Apple like graphics are possible too. Best of both worlds, IMHO.

 

Overall, I think the PAL display is better, but I referred to it as "shit" simply for the fact that it's picky as hell, which it is. Otherwise, it's not shit at all. Perfectly fine to look at, which I do regularly.

 

My favorite though is NTSC, because it's hackable and very tolerant. Besides, it works on the Apple native without a card, and I love Apple computers as much as I do Atari ones, simply for both of them being the first.

Edited November 4, 2011 by potatohead

[Eagle]

Talk is cheap :P

Do not complain. Done in three hours.

PoP.xex

[popmilo]

Talk is cheap :P

Do not complain. Done in three hours.

Nice, I see its mode E, what about cpu usage ? did you use preshifted sprite data or some other method ?

 

And yes, code rules!

[sack-c0s]

We've been able to use PAL60 on most TVs since the 90s, so we get PAL resolution and the NTSC framerate

[Eagle]

popmilo

Yes, preshifted sprite data.

2/3 vblank - but it was written on quickly.

No optimization of the program and memory.

 

f.e. part of code

lda (msk),y
tax
lda (sour),y
and tabmask2,x
sta buf  
tax
lda (dest),y
and tabmask,x
ora buf
sta (dest),y

 

You do not have to explain what it does?

Edited November 9, 2011 by Eagle

[José Pereira]

popmilo

Yes, preshifted sprite data.

2/3 vblank - but it was written on quickly.

No optimization of the program and memory.

 

f.e. part of code

lda (msk),y
tax
lda (sour),y
and tabmask2,x
sta buf  
tax
lda (dest),y
and tabmask,x
ora buf
sta (dest),y

 

You do not have to explain what it does?

 

 

Of course I could explain but I prefer to put you some questions :

 

-> Pre-shifted means that you have copies each steps/each time the guy is moving?

 

-> To get things Universal/to all screens and possible in all situations it wouldn't work like that?

From the C64 Gfxs. you have, for example, the Pillar: and the Pillar Mak:

This is a large Block but if now we put a gfx that has empty places on it...

It is a little more tricky but it is still something like a soft sprite routine, right?

 

-> There is something that it was also needed in a software sprite routine for the A8 PoP that me and Popmilo also talked:

You have the guy with the PF0,PF1&PF2 on it's shapes but for the PMs stuff we also need that the shape also have Backgr. colour Register:

- PRINCE: Eye pixel

- ENEMY: on the coloured clothe colour (like, for example, Blue, Green, Purple,...)

(this is where the PMs would take their colours because it's above Background register colour)

Edited November 9, 2011 by José Pereira

[Rybags]

PMs don't have "background colour", the "0" data is always transparent.

 

You get "forced background colour" in softsprites by having it defined in the mask data.