Wich one of these two Prince of Persia you prefer?

[mrsid]

You're likely to have to change that mode mid-time through the work, because of a feature in the game you didn't know about.

[José Pereira]

You're likely to have to change that mode mid-time through the work, because of a feature in the game you didn't know about.

 

What change? In Gfx. Mode from Bitmap into Char-Mode?

Because of what? More colours isn't, because C64 Multicolour Bitmap Mode has even more and freely choosen colours possible.

 

What feature? It is present in the original, later or in all versions?

Edited October 12, 2011 by José Pereira

[mrsid]

Imagine you're working on the game, and suddenly you find out that the game has falling floors, which don't fit into your graphics mode plans. So you have to throw everything away and start from scratch. Trust me, the various animated bits of the game are the hardest part. It's not just background and a few character sprites...

[José Pereira]

Imagine you're working on the game, and suddenly you find out that the game has falling floors, which don't fit into your graphics mode plans. So you have to throw everything away and start from scratch. Trust me, the various animated bits of the game are the hardest part. It's not just background and a few character sprites...

 

Yes, but that way you're talking in coding stuff (Moving Grid door and floor, flames,...) and I was worried it was about the colours...

Thanks.

[Heaven/TQA]

If I would start to do it... I would go for bitmap mode... why? because Apple 2 is bitmap, too and would give an authentic port... DLI handling is easy and you still could use PMs for spicing up the stuff.

 

and as far as I know from the game it does not have much sprites going on per frame?

[emkay]

You're likely to have to change that mode mid-time through the work, because of a feature in the game you didn't know about.

 

That's the point.

You HAVE to think of it all BEFORE you chose a graphicsmode.

You often see "sprite tests" people doing on the A8 with the screen turned off. "Oh, look how fast it is"....

You have the choice to use all 240 lines from scratch, in the linear gfx mode, and to reduce the lines , if CPU Cycles were missing.

If CPU cycles were missing, you also can do interleaved movement on the objects. You find this style very often in C64 Demos where they try to show 3D objects.

 

You also can use the double scanline modes , if moving objects get rather big on the screen.

 

PoP definately needs the colourmode 160x200, to resemble the original game.

[emkay]

If I would start to do it... I would go for bitmap mode... why? because Apple 2 is bitmap, too and would give an authentic port... DLI handling is easy and you still could use PMs for spicing up the stuff.

 

and as far as I know from the game it does not have much sprites going on per frame?

 

As PoP has to be done that way, best, I'd still like to see some A8 special game. Just using any GTIA mode + full shape formed PM based moving objects. Perhaps in another battling game.

[José Pereira]

If I would start to do it... I would go for bitmap mode... why? because Apple 2 is bitmap, too and would give an authentic port... DLI handling is easy and you still could use PMs for spicing up the stuff.

 

and as far as I know from the game it does not have much sprites going on per frame?

 

As PoP has to be done that way, best, I'd still like to see some A8 special game. Just using any GTIA mode + full shape formed PM based moving objects. Perhaps in another battling game.

 

On another game Emkay, same about using GR.7... It's for another game ...

[Heaven/TQA]

let's assume that the source code for the c64 will be available public. how many working RAM does PoP64 need? Is it bitmap mode using? So as far as I have understood... an A8 port of the c64 version can be done relativly quickly? it uses a lot of ROM code for unrolled code and maybe the ROM space for not "depacking" all gfx on the fly, maybe because of less RAM and or slow CPU.

 

if we would use AnticE 160x200 then some routines need to be adjusted... but if we mimic c64 bitmap mode in charmode.... a potential coder would be faster... the hardware sprite routines "simply need to be" recoded for bitmap sprites+overlays.

[Heaven/TQA]

and I vote for Tezz/Wrathchild or Sheddy for going with this port... they know the whole bank switching type of thing.

[José Pereira]

let's assume that the source code for the c64 will be available public. how many working RAM does PoP64 need? Is it bitmap mode using? So as far as I have understood... an A8 port of the c64 version can be done relativly quickly? it uses a lot of ROM code for unrolled code and maybe the ROM space for not "depacking" all gfx on the fly, maybe because of less RAM and or slow CPU.

 

if we would use AnticE 160x200 then some routines need to be adjusted... but if we mimic c64 bitmap mode in charmode.... a potential coder would be faster... the hardware sprite routines "simply need to be" recoded for bitmap sprites+overlays.

 

 

Do you think it can be ANTIC4 and still having soft sprites+PMs. overlays?

It is possible to waste more cycles on the soft sprites? And going for what, 3Lines=1Charset?

 

 

But it probably wouldn't work in a direct port as the Tiles of the Apple2 converted to C64 have 63scanlines high... The things, from what I read, doesn't fit in normal chars high size.

Edited October 12, 2011 by José Pereira

[Bryan]

Guys, I'd recommend less talk and more code. Figuring out the graphics mode is the least of your problems...

Code? You must be new here.

 

[José Pereira]

Guys, I'd recommend less talk and more code. Figuring out the graphics mode is the least of your problems...

Code? You must be new here.

 

 

 

Code, coding?

Edited October 12, 2011 by José Pereira

[Heaven/TQA]

Bryan, you are a blasphemor...

[Heaven/TQA]

oh... just discovered his Youtube channel... http://www.youtube.com/user/JordanMechner#g/u

[potatohead]

Yeah, nice isn't it? He puts a lot of data out there. Stumbling on that was worth entertaining the thread. I like how he will share various things. Been some interesting reading really.

 

I really liked the data document you linked. There is some real insight on how things get done on a 6502 in assembly land. The coordinate system, for example. I know I would not have thought it through like that, getting things down to a simple compare. And the tile draw order needed to pack the background detail into RAM efficiently. Great stuff.

 

Couple of interesting bits from his story blog... One was the creation of the music. His father is classically trained to some degree, and they would compose for the games. "This machine is such a piece of shit" referring to the 1 bit speaker sound output the Apple has, LOL!! Or, to his prospective MSDOS conversion team, "I check on byte boundaries". My favorite though is the back and forth on story and computer game programming. When he referenced the double high-res "Airworld", "Effect looking for a game." Just played that one recently, and that was my exact impression. Looks cool, but WTF???

 

Honestly, how many times have we seen "effect as game" on various machines?

 

After reading all of that, I wonder what he would have done with the Atari and C64 machines? On the 64, given no screen scrolling, I'm pretty sure he would have doubled up the sprites to draw the characters, and used a packed data format for the background and color cells, optimizing the levels around the color clashes, etc... Given the number of sprites, I'll bet he would have buffered with them too, drawing to one, then popping the result on screen, so the other can be drawn off screen, toggling each frame, draw, switch, draw, switch... Would look spiffy, as the user would never see screen drawing. And a nice speed up too, as no character to background combine operations need to be done. IMHO, that frees up 8 K right there, as it's buffered off screen to get done on the Apple.

 

On the Apple, that was very nicely done, with only the occasional ripple. He and that Roland guy touch VBLANK on the //e and c, where many titles didn't too. Older Apples required sophisticated timing and some wizardry to detect and keep track of the VBLANK, as it was not offered up as a readable value. One can infer it with some clever code, that's it. The Apple version displays well, all things given.

 

On the Atari?

 

Given his style, I'll bet it would have been straight up 4 color, P/M for decorations, maybe overlay for one of the characters on screen. Dev would have been just 4 color bitmap, put it on the screen, make it move, then pretty it up, IMHO. Doing otherwise might end up, "Effect as game" The 5 color antic mode would require a fairly complex kernel, compared to others. He might have done it though. It's not like the Apple display addressing wasn't bizzare anyway. Once a lookup table becomes needed for fast blitting as it generally is on the Apple, what's the difference between one lookup and another?

Edited October 12, 2011 by potatohead

[Heaven/TQA]

Potatohead... yup... watching Karateka I, too, would assume he would use Antic E in 4 colors as the "core engine" is already done... so that's why I would go with the apple 2 source... obviously bitmap is a pain in the ass regarding the frame data (f.e. 30k only for the player data if I remember that correct) so using sprites save some time...

 

maybe someone can send some lights why the c64 port needs the whole cart as ROM space? all rooms already depacked?

[Heaven/TQA]

and yes... everything above 160x192x4 is "effect as a game"

[potatohead]

Yeah, that's what I was wondering too.

 

The Apple touches the disk for various things. It's mentioned in the data doc, where he designated things as RAM or DISK. I think there's your ROM right there on C64. I kind of want to play that one now. Spent some time on the Apple game, and it's a lot of fun. Never played this one back in the day. Was one of those B0rderbrund marketing victims it seems.

 

POP ate up all of the 128K on the Apple, and still touched the disk where needed. Granted, some 8 K of that is a extra buffer where combining can be done before blitting. Don't need it on C64. Would need it on Atari though.

 

Deffo Apple source. It's much closer to what is needed. If it were me, I would compensate some by offering a greater color variety for the various screens and call it good. Some clever pixel art could make the most of the 4 colors... Would have to redo and nudge the art anyway, right? Apples only do 7 pixels / byte. All else works as given, minus changing the addresses of things, or not... Maybe just put the bitmaps where the Apple did.

Edited October 12, 2011 by potatohead

[mrsid]

I will release my reverse-engineering work of the Apple II version shortly after the release of the C64 conversion.

 

The reason it needs a cart is because the player sprites alone take about 40K (and are pre-mirrored on the C64) and there's about 32K of code and also lots of tables.

Background graphics tiles also take a fair amount of space (15K for palace levels). And then there are two bitmaps (8K each) for double-buffering, and lots of other smaller things

(music, sfx, animation data, etc.).

Edited October 12, 2011 by mrsid

[mrsid]

The Apple II version hits the disk between levels (to load the level description and the animation frames for the guard in that level) and when showing a cutscene (to load the background image and the animation frames for that). Also when the level changes from dungeon to palace it loads a different set of bg graphics.

[Rybags]

I would guess that the C64 cart probably maps 8K into the system and possibly the player sprites are uncompressed and used directly.

 

The enemies have much less range of movements and would probably be copied to RAM as needed. The need to keep all graphics in one 16K region leads me to believe these things. Although even if the player data was copied or decompressed on demand, it shouldn't impose too much of a huge load.

[mrsid]

The VIC-II chip cannot read data from ROM, so it has to be copied to RAM, but that's fine because the sprites need to be masked anyway.

[potatohead]

Not using sprites then? Bitmap buffer 'n draw like Apple?

[Rybags]

The VIC-II chip cannot read data from ROM, so it has to be copied to RAM, but that's fine because the sprites need to be masked anyway.

 

Didn't realise that... I thought cartridges could override the default behaviour re Vic reads.

 

Do you have some stats regarding how much memory use for kid sprites, level data, enemy sprites, game code etc ?