Wich one of these two Prince of Persia you prefer?

[mrsid]

No, of course I'm using sprites. Otherwise color clash would make it look very ugly.

[Heaven/TQA]

will you release the source of the c64 version, too?

[potatohead]

Of course. Silly of me.

 

Where is the masking happening for the player sprites on C64?

 

Edit: I can just wait for the docs!

Edited October 12, 2011 by potatohead

[mrsid]

Probably not, but I haven't decided yet...

[Heaven/TQA]

and what makes me more wonder... the game itself can't be CPU overloading? most CPU would go for building the screens?

[mrsid]

Parts of the screen are constantly rebuilt when something is moving or animated. Gates, falling floors, flames, spikes, etc. This is where most of the time is spent.

[Bryan]

No, of course I'm using sprites. Otherwise color clash would make it look very ugly.

What?! That would mean 99% of Speccy games are ugly!!

 

 

[Heaven/TQA]

are you using bitmap mode or charmode where animations would be a piece of cake?

[Heaven/TQA]

or and is there a video of ingame footage? i only found the c64 intro on youtube.

[mrsid]

Animations would not be a piece of cake in charmode. It's a game with isometric graphics, so tiles overlap each other. Both of them can be animated, in different ways. One gate going up can be next to a pressure plate and next to a flame. If you consider all the possible combinations you will see that it requires a very large amount of characters. So you would have to dynamically generate them, and then you're basically back to bitmap drawing.

[Heaven/TQA]

I see.... then... give us the code and our pro-coders will do the rest for an A8 port...

[José Pereira]

There's no way to have the screen using ANTIC4.

 

The screen build is made like this:

-> Top: 3scanlines that are the bottom part of the previous higher screen

-> And three parts of 63scanlines that are 3Rocks high.

 

It is like this in all the Broderbound versions and it is also on the C64 one.

3scanlines and then 63x3scanlines must be in Bitmap Mode.

 

How would you change this to get it into ANTIC4?

You'll have to re-design all in a way that:

1.)- That Tile/3 Rocks high that includes the Floor has 21pixels tall in each Rock have to turn into a Char tall 24 scanlines

2.)- But you also need that the Floor be a char Tall so that it show 1char tall on the Top (from the previous top screen)

This way, for an ANTIC4 with most of things would come from Bitmap but some changes:

1A.)- Each Rock high must be pixels char talll, 21pixels->24pixels=3 char tall change needed (3Rocks high would be 3x3=9)

2A.)- And the Floor would still be the 3pixels tall and it will be seen also the other 5pixels above it/some part of the Rocks

 

In ANTIC4 the screen would be:

-> 1Chars (Previous Top Floor)

-> 3chars tall x 3 chars Rocks = 9char-lines

-> 3x3 chars

-> 3x3 chars

Would be 232scanlines total (224+8 for Energy Area)==29char-lines

Edited October 12, 2011 by José Pereira

[mrsid]

Exactly. The only version that doesn't have this screen layout is the NES version, there the top row is not 3 but 8 pixels high, so it shows more of the screen above the current screen:

 

 

Easy with 224 pixels vertically.

[Bryan]

224 lines isn't really a problem on the Atari.

 

With some DLI tricks, you can have a screen full of characters which are less than 8 lines tall (fudge VSCROL). All character rows in Castle Crisis are 7 lines tall.

[José Pereira]

Exactly. The only version that doesn't have this screen layout is the NES version, there the top row is not 3 but 8 pixels high, so it shows more of the screen above the current screen:

 

 

Easy with 224 pixels vertically.

 

 

No, you could do it on C64 with 200scanlines.

The Top previous Floor it's 1char-line

Middle are 64scanlines=8charlines each that would be three horizontal Floors=24char-lines.

 

All the screen it's 25charlines=200scanlines.

And then put the Energy Bars as hardware sprites out side the Borders.

But you'd have to re-design it all and even using NES that would be difficult as it is using 256pixels in Hi-resolution (indeed 248pixels because of the Horizontal scrolling)

 

The same would be for A8 but we could go for simple screen because it would be only 208scanlines (on A8 you can have screen with maximum 240 (239) scanlines tall)

Edited October 12, 2011 by José Pereira

[José Pereira]

Get into Char tall boundaries could be like this on A8:

 

Each of the three parts that were 63pixels tall just need one more and be 64pixels tall (8 char-lines)

But that pixel more on each of the three Rocks parts must be 'well thinked' because of the Numbers of Char/Tiles.

In this picture I just expanded it in PAINT.

Edited October 12, 2011 by José Pereira

[emkay]

Not sure what you're talking about "224" and more scanlines. The Apple version has a resolution of 280(140)x192.

An Atari version could be scaled to 168x230 , to keep the aspect ratio. Not sure for what this would be good

[potatohead]

Re: Masking... I figured it out. The kid has to walk behind something. I'll still wait for the docs, but just had to say that. Sick day today, I'm running kind of crappy.

 

Apple version is 140 pixels. When considering color, it's two pixels per color. Patterns are a special case, where the smaller pixel size can make for interesting patterns, because you still get a small pixel, unlike ANTIC 4 color mode, where the pixel is fat, consuming the entire color clock. The COLOR of the pixel is limited in terms of position placement, but the size of the pixel, at that color, in that position can either be half what the Atari does for all pixels, or the same pixel size the Atari does. This can be seen in the game art, where lighting effects are done with sparse pixel placement and variances in the overall pixel size.

 

A similar thing can be done in graphics 8 on the Atari, with the only difference being the number of possible artifact colors being half what the Apple does, because the Atari puts all 8 bits in a byte onto the screen, lacking the color phase shift bit. Enter graphics 8, set your background to black, foreground to white, and then plot a single pixel in the odd position to see one color, a single pixel in the even position to see the other color possible. That's 320 pixel precision, but only 160 pixel color placement or position.

 

Apple has two more color possibilities, due to the phase change bit 7, and it's internal dot clock being 540 pixels overall. Bit 7 literally just shifts the pixels in that byte over by 1/4 color clock, speaking in Atari terms, which results in a different artifact color for the pixels in that byte only. This cannot be duplicated on pretty much any other machine, unless it's got more than 320 pixel precision available to it, and it's NTSC, and it's got simple non-phase change color signal output to make artifacting possible. CoCo 3 can do this, BTW, because it's a 640 pixel machine. Monochrome graphics on that one can duplicate Apple double high res and high res very closely, with a slightly wider screen to work with. (160 pixels of artifact color placement) It still isn't the same though. New art is needed because the CoCo has no phase change bit, unique to the Apple as far as I know. It was the first "color cell" machine.

 

Edit: I suppose that means a PC running CGA / EGA could do it too, assuming the 640 pixel TV output is used.

 

From there, plot two even pixels next to one another, skip some space, and do the same for the odd position. You now have pixels that are as wide as ANTIC 4 color. That's still 160 pixel placement and position, but the pixel SIZE is double. Variations in color pixel SIZE are what makes for most of the Apple pixel art, just FYI.

 

That aside, it's a 140 pixel machine, if color graphics are being used, simply because positioning a color object isn't possible at every pixel position. If it's being used as a monochrome machine, then it's 280 pixels, and there is the special case of a solid white, or solid black object, both of which can be drawn at 140 pixel resolution, but placed at 280 pixel precision. This is because the Apple uses artifact color exclusively, and because of that there isn't a direct mapping of pixel art, between it and pretty much every other computer.

 

If 4 color artifacts are all that is needed, ignoring the color phase bit in the Apple high-res screen, then it's possible to reuse those graphics, once the 7 pixels per byte is accounted for.

 

Bottom line here is it's just not possible to throw out the Apple high-res screen spec and call it "the resolution", whether or not color is a consideration impacts EVERYTHING.

 

Double-high res actually is a simpler case. There is no phase change bit, meaning it's a 140 pixel 16 color machine, or a 540 pixel monochrome machine, with the same position precision vs color precision rules in play for solid white, or solid black objects, and that's true in most cases for the grey object definition as well, though I think grey has position limits that white and black do not have. (will have to try this on the Apple to know)

 

On the Atari, using ANTIC E, the best overall path would be to just use a 140 pixel play area. The code would map well from there, leaving only the art. Some of the dither patterns possible on the Apple won't work at the more coarse pixel SIZE the Atari has, but everything else will work. A pixel artist can probably get that sorted out nicely enough though. No worries.

 

Re: ANTIC 4 (which I assume is the 5 color mode.) Chars as bitmap.

 

If it were me, I would simply make a kernel that stacked up the available characters into a big ass bitmap, changing CHRBASE as needed with a DLI. The resulting graphics screen addressing would be FUNKY, but the Apple screen is funky anyway. Build the necessary lookup tables for screen byte addressing, and then build from there. The result would basically be a 5 color bitmap screen. Downside is the screen memory might be fragmented, depending on what could be done with CHRBASE. I don't remember placement rules well enough to know. Can it be anywhere, or at specific boundaries?

 

...or just make the pixel art compromise choices in the 4 color mode, and keep the screen addressing sane.

 

The above is a LOT of work for ONE more screen color. Worth it? Not sure the characters map into the sprites though. Some of the animation frames are 3 or 4 player missiles wide, and there would be color clash, which limits the utility of overlay.

 

(Which is why I think the developer would have gone 4 color back then, with some sparkle and maybe overlay used to highlight the kid and a few things, like the torches.)

Edited October 12, 2011 by potatohead

[emkay]

 

 

The above is a LOT of work for ONE more screen color. Worth it? Not sure the characters map into the sprites though. Some of the animation frames are 3 or 4 player missiles wide, and there would be color clash, which limits the utility of overlay.

 

 

Charmode is not suitable for this game imho. Charmode is a good choice , if char movement and reused gfx help building the gameplay, but this isn't given.

Linear Mode fits well. The game could live with 4 colours and some highlighted elements with PM overlays.

 

Doing the game in GR. 15 surely will leave a lot of free cycles to add PM overlays, where needed.

Masking should also be not the problem, if the pillars were created on 3 bytes. So they simply could be drawn over the softwaresprite, without any bit comparision. Height, X, and Y position gives the indication, which range of a pillar had to be redrawn.

 

 

Just a quick import to G2F . Violet ranges show byte dependency.

[José Pereira]

 

 

The above is a LOT of work for ONE more screen color. Worth it? Not sure the characters map into the sprites though. Some of the animation frames are 3 or 4 player missiles wide, and there would be color clash, which limits the utility of overlay.

 

 

Charmode is not suitable for this game imho. Charmode is a good choice , if char movement and reused gfx help building the gameplay, but this isn't given.

Linear Mode fits well. The game could live with 4 colours and some highlighted elements with PM overlays.

 

Doing the game in GR. 15 surely will leave a lot of free cycles to add PM overlays, where needed.

Masking should also be not the problem, if the pillars were created on 3 bytes. So they simply could be drawn over the softwaresprite, without any bit comparision. Height, X, and Y position gives the indication, which range of a pillar had to be redrawn.

 

 

Just a quick import to G2F . Violet ranges show byte dependency.

 

 

Emkay why get all those troubles and lots of working...

If it is for going into 4colours Bitmap there's the C64 better looking Gfxs. that are 320wide and can be ported exactly to A8 and also the Rocks masking,...

 

Lets say that A8 coder would have to do is the PMs. overlays and the soft sprite routine.

Even the C64 sprites can be almost directly ported to A8 with the Pms. overlays.

Believe me I know what I am saying.

 

 

 

If anyone thinks he can do this in ANTIC4 I can still get them the Gfxs. and the Playing area in about 3Charsets (I am seeing but I think it's possible...)

[emkay]

 

Lets say that A8 coder would have to do is the PMs. overlays and the soft sprite routine.

Even the C64 sprites can be almost directly ported to A8 with the Pms. overlays.

Believe me I know what I am saying.

 

 

The difference between me and you, is that I know what the A8 can do

 

You still have to keep in mind that you have to look at the background.... behind the Softwaresprite (masking in bit resolution) .... and the masking in front of the moving objects....

 

You know how "expert programmers" ended every time ?

 

Well, no A8 version without a perfect adjustment of "everything".

The C64 graphics is useless, except you want to have a slideshow, instead of fluent animations .

[Heaven/TQA]

I am with emkay... Bitmap Mode with some enhancements via PMs. Linear frame buffer helps in terms of drawing masking etc

[José Pereira]

 

Lets say that A8 coder would have to do is the PMs. overlays and the soft sprite routine.

Even the C64 sprites can be almost directly ported to A8 with the Pms. overlays.

Believe me I know what I am saying.

 

 

The difference between me and you, is that I know what the A8 can do

 

You still have to keep in mind that you have to look at the background.... behind the Softwaresprite (masking in bit resolution) .... and the masking in front of the moving objects....

 

You know how "expert programmers" ended every time ?

 

Well, no A8 version without a perfect adjustment of "everything".

The C64 graphics is useless, except you want to have a slideshow, instead of fluent animations .

 

 

No, you aren't seen things correct:

-> C64 Gfxs. aren't useful why?

Have the C64, the Apple or any other there's no difference.

The coding is the same...

4colours on C64 are direct port and on Apple with all that Apple2 specific Gfxs/screen/Artifacts/colouring would be a great trouble...

This trouble can be seen in Emkay's screens.

C64 can also be direct ported because it's in Bitmap and 4colours where:

-> Tiles are 63scanlines high and it fits in 1byte=4bit-pairs

(Apple2 is, in a simple talking, in High-resolution 7bit)

-> The screen build and Tiles can be directly port and the masks also.

 

 

I don't know where you, at least now, you have more knowing about A8 with this 'talkings'.

C64->A8 would look better and it's the perfect solution.

And great there's finally a C64 version or this wouldn't, probably, be ressurected again (or I remember it again, like on the past ...).

Great that we have the C64 version to get the Gfxs. and the sprites frames or anyone would ever get these into A8.

Even as Gfxs. Tiles and soft sprites frames.

for the C64 guys involved in this and all the time they spend, more than two years.

As usually I don't see anyone in A8 take all this time and still end up with a real game (only Sheddy and it was 10years to release a full/ended version of Space Harrier)

 

Why are you with this opinion?

I believe that you prefer to send this screens that I don't know what are you trying to get...

I don't know, and others here probably also don't know why...

Or I know, it is because it is C64 guys and C64 gfxs. !...

But that's a 'sad true' and I have a dream that someday, someone on A8 would get a game/gfxs./sprites/... that they want to port/convert into C64.

Untill there I have to continue asking them to use their usually great work!

Edited October 12, 2011 by José Pereira

[José Pereira]

I am with emkay... Bitmap Mode with some enhancements via PMs. Linear frame buffer helps in terms of drawing masking etc

 

Backgr. register it's Black and you will waste one more PF just to have it as Black to Mask the guys?

Oh my!.. Just to not bother masking the PMs. when you always have to Mask the soft sprite PFs shapes...

Oh God!...

 

Yes, I can go with Bitmap and my screens are Bitmap.

The sprites and overlays are on the way...

 

What I don't understand is why he wants to turn all upside down and start from scratch, higher difficulty...

What the hell are wrong in C64 gfxs. for Emkay that cannot be directly ported to A8?

I(We) know the answer ...

Edited October 12, 2011 by José Pereira

[emkay]

Let's start with converted GFX with walls of 2 colours.

GPRIOR set to PF0-PF1-PM-PF3-BAK

Missiles set to the stone colour could help with masking.

 

A very clever coder could do the moving objects with one PF and one Player, using the change of the background with one PF colour as a filter for the PMg.