Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
IGNORED

Wich one of these two Prince of Persia you prefer?

José Pereira

By José Pereira
in Atari 8-Bit Computers

 Share

Sprites and colours&luminances (can be others) apart, what of these two Rocks type you think look better designed/better looking:  

39 members have voted

  1. 1. Sprites and colours&luminances apart(can be others), what of these two Rocks type you think look better designed/better looking:

    • PC original looking
      6
    • C64 remake looking
      33
  • Please sign in to vote in this poll.

Recommended Posts

José Pereira River Patroller

José Pereira

Posted
  • Author
Posted

Bitmap... Rybags mentioned that you have some kind of flag for each block or tile... but that can be done in another way like Gremlins or my Beyond Evil is doing it...you can organise a "background buffer" which can hold 255 states for each tile... so not an issue...

 

And there would be lots of clash troubles in Charmode like the Open gates, destroy Floor,...

Link to comment
Share on other sites
José Pereira River Patroller

José Pereira

Posted
  • Author
Posted

ok. I see.... so I guess masking would be the most crucial point and I guess that most of the CPU time needed...

 

again on A8 I would go for bitmap. And emkay mentioned the priority. On A8 we could set PMs more clever than on c64... would that help?

 

 

PMs more clever?

And where would you put the PMs.?

Link to comment
Share on other sites
José Pereira River Patroller

José Pereira

Posted
  • Author
Posted (edited)

Was thinking in have the foreground Pillars as PM0 and re-use it where we have more than one Pillar with PRIOR0 but lots of troubles:

-> PM0 and Oring would get 3colours but would still have the problem with the Black colour (that is Background Register) but I think I can get it with the PM0

-> Repeat/re-use PM0 if there's another Pillar... In Bitmap Mode there's no Bad-Lines.

-> Prince would use PM2&PM3 that would coloured skin and Hair (White colour it's (11) bit-pair on C64 Gfxs.)

-> There are times where you have that Grid in same Line as Pillar(s) and we would need PM1 for it

-> How to colour Enemy? With PM1 if there aren't Grid where's Enemy (what I have to see next...)

Now, what I really would like to know if there's any problem of re-using PM0 in a second Pillar?

But then, how will I get the Flames/Torches colours?

(This would be a must because the foreground would all be PMs., you would only need to Mask the soft sprite. The PM2&3 of Prince or even (if possible) the PM1 of the Enemy would be less priority than PM0)

Can we re-use PM0 at least one time (have to see if maximum Pillars at the same line are two, probably not...)?

Edited by José Pereira
Link to comment
Share on other sites
José Pereira River Patroller

José Pereira

Posted
  • Author
Posted (edited)

Was thinking in have the foreground Pillars as PM0 and re-use it where we have more than one Pillar with PRIOR0 but lots of troubles:

-> PM0 and Oring would get 3colours but would still have the problem with the Black colour (that is Background Register) but I think I can get it with the PM0

-> Repeat/re-use PM0 if there's another Pillar... In Bitmap Mode there's no Bad-Lines.

-> Prince would use PM2&PM3 that would coloured skin and Hair (White colour it's (11) bit-pair on C64 Gfxs.)

-> There are times where you have that Grid in same Line as Pillar(s) and we would need PM1 for it

-> How to colour Enemy? With PM1 if there aren't Grid where's Enemy (what I have to see next...)

Now, what I really would like to know if there's any problem of re-using PM0 in a second Pillar?

But then, how will I get the Flames/Torches colours?

(This would be a must because the foreground would all be PMs., you would only need to Mask the soft sprite. The PM2&3 of Prince or even (if possible) the PM1 of the Enemy would be less priority than PM0)

Can we re-use PM0 at least one time (have to see if maximum Pillars at the same line are two, probably not...)?

 

 

DELECTED!... forget.

That's what I was thinking almost from the begining... there's no way to work with PRIOR values nor PMs. in foreground Pillars.

There are sometimes 3Pillars (probably would be more) and there's also when Prince climb/fall the Wall on his right...

It have to be masked by software...

 

Karol is right, first have the soft sprite and just use the PMs on screen, by now in P2&P3 on two Torches (seems by now the maximum on each line)

Then if the things work we'll add the PMs overlays... if we can do that PMs overlays in PRIOR0 we then would get those guys looking all that coloured.

Edited by José Pereira
Link to comment
Share on other sites
emkay Quadrunner

emkay

Posted
Posted

I don't think it's worth the trouble of remaking graphics such that pillars always occupy a full byte where possible. And as shown, there's probably plenty of instances where partial masking within a byte is needed.

 

A better approach might be to just maintain a bitmap representing character cells where masking elements can be flagged, and/or a table of coordinates where the sprites become eligible for masking.

 

Masking softsprites on their own is simple enough - you can just treat the pillar as another kind of softsprite that doesn't move and only needs drawing occasionally, but masking of PMG data isn't so straightforward. If it's the case that masking elements are always a nice vertical shape with no indentations, then it would become a bit easier.

 

To make the pillars using full bytes, is the best for any solution.

You could also set the regions for the pillars, and when the objects hits that range, you simply do not set the object "bytes" and the Player gets hidden by the priority there.

Link to comment
Share on other sites
emkay Quadrunner

emkay

Posted
Posted

ok. I see.... so I guess masking would be the most crucial point and I guess that most of the CPU time needed...

 

again on A8 I would go for bitmap. And emkay mentioned the priority. On A8 we could set PMs more clever than on c64... would that help?

 

Masking the "front" with my method , speeds up things, because the graphics doesn't need to be drawn .

Doors can be done with players aswell, because there is no enemy near ;)

Link to comment
Share on other sites
José Pereira River Patroller

José Pereira

Posted
  • Author
Posted

I don't think it's worth the trouble of remaking graphics such that pillars always occupy a full byte where possible. And as shown, there's probably plenty of instances where partial masking within a byte is needed.

 

A better approach might be to just maintain a bitmap representing character cells where masking elements can be flagged, and/or a table of coordinates where the sprites become eligible for masking.

 

Masking softsprites on their own is simple enough - you can just treat the pillar as another kind of softsprite that doesn't move and only needs drawing occasionally, but masking of PMG data isn't so straightforward. If it's the case that masking elements are always a nice vertical shape with no indentations, then it would become a bit easier.

 

To make the pillars using full bytes, is the best for any solution.

You could also set the regions for the pillars, and when the objects hits that range, you simply do not set the object "bytes" and the Player gets hidden by the priority there.

 

 

That's it Emkay... finally I agree wiith you. That's what a good Night of sleep does :) ...

That region that you do not set the bytes of the guys PFs. could also be used for also not set the bits in that xPos. of the PMs overlays, couldn't it?

 

But we still need to get those 'not linear' Masking on the the Grid cells (if there aren't more)...

Another idea came to my mind for the cells...

Some more videos minutes to see...

Link to comment
Share on other sites
Rybags Quadrunner

Rybags

Posted
Posted

"Full byte" pillars would makes rendering much more simple, but means more work redoing the graphics.

 

If it's the case of the overall look not suffering and the efficiency gains being worth it, then it's probably the way to go.

 

But there are probably instances to be found within the game where partial masking is needed. Grates are probably one of them, although a way to overcome that might be to just not allow any overlap when they're closed.

Link to comment
Share on other sites
emkay Quadrunner

emkay

Posted
Posted

I don't think it's worth the trouble of remaking graphics such that pillars always occupy a full byte where possible. And as shown, there's probably plenty of instances where partial masking within a byte is needed.

 

A better approach might be to just maintain a bitmap representing character cells where masking elements can be flagged, and/or a table of coordinates where the sprites become eligible for masking.

 

Masking softsprites on their own is simple enough - you can just treat the pillar as another kind of softsprite that doesn't move and only needs drawing occasionally, but masking of PMG data isn't so straightforward. If it's the case that masking elements are always a nice vertical shape with no indentations, then it would become a bit easier.

 

To make the pillars using full bytes, is the best for any solution.

You could also set the regions for the pillars, and when the objects hits that range, you simply do not set the object "bytes" and the Player gets hidden by the priority there.

 

 

That's it Emkay... finally I agree wiith you. That's what a good Night of sleep does :) ...

That region that you do not set the bytes of the guys PFs. could also be used for also not set the bits in that xPos. of the PMs overlays, couldn't it?

 

But we still need to get those 'not linear' Masking on the the Grid cells (if there aren't more)...

Another idea came to my mind for the cells...

Some more videos minutes to see...

 

I don't the problem there. Just exchange the Players.

Link to comment
Share on other sites
Rybags Quadrunner

Rybags

Posted
Posted

The "ways":

 

- someone spends months/years reverse-engineering the Apple 2 version before actual programming even starts, chance factor highly unlikely.

- someone is granted use of the C64 source/resources, dev cycle reduced drastically vs first option.

 

Bitmap or character mode, partial masking or entire byte omission on softsprites vs pillars is a side issue. The technical issues have any number of solutions which could easily be benchmarked with sample scenarios. There's not really much point saying one thing is better than the other until actual performance and memory use figures are a known figure rather than speculation.

 

At least most should agree - the obvious media would be a 1 MB flash cartridge. At $20 a piece (bulk) or even $45 or whatever for singular quantities, there's no excuse not to buy one.

Link to comment
Share on other sites
mrsid Star Raider

mrsid

Posted
Posted (edited)

As I already said, I'm gonna release my reverse-engineered Apple 2 disassembly (with 1562 named labels) shortly.

I spent approximately a year in total doing that. I started coding after about 1 month of disassembling, at which point I only had enough

understanding of the animation system to draw a running guy.

Edited by mrsid
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...
×
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...