Wich one of these two Prince of Persia you prefer?

[STE'86]

Actually, as David Crane mentiond the the magazine Hi-Res, a good game takes a year to develop.

In the UK they knocked up games during the weekend, most of them weren't any good.

 

David Crane and co also got wiped out by the "games crash" that only occurred in US. The UK's games industry boomed for 10 years so who would you say had the best business plan?

[flashjazzcat]

Here is what I did yesterday (while avoiding spending time on forums ).

Amazingly effective way of producing code, isn't it.

[popmilo]

Someone asked for executable, so here it is:

 

pop.xex

 

Forgot to mention that video is from Altirra with Pal system settings.

Cpu time left in Ntsc mode is much worse

[sack-c0s]

bloody hell! There's code in the thread

 

THERE. IS. CODE. IN. THE. THREAD.

 

who are you, and what have you done with the real A8 forum?

 

 

Seriously though - that's not going to get that much worse with preshifted graphics, masking would make a big dent though. sprite-pillar masking wouldn't be so bad as they all seem to be byte-aligned, and double-buffering means there's no beam-racing problem. I think you might be able to get to *playable* fairly quickly this way and be better off worrying about *pretty* afterwards

Edited October 24, 2011 by sack-c0s

[flashjazzcat]

If the masks are pre-shifted also, you can get quite a lot done during the interrupt (popmilo did some great work on the GUI's interrupt driven mouse renderer).

 

I quite agree with the above, though: doing projects backwards (visual tweaks first) is a sure-fire way of ensuring things fizzle out when it comes down to some honest to goodness coding.

[popmilo]

... I think you might be able to get to *playable* fairly quickly this way and be better off worrying about *pretty* afterwards

Yeah, just have to get rid of this 'work' thing that is kinda interfering with plans

Next step should be shifted graphics (want to try that before I take more memory than my 800xl has available at the moment )

And then hardest will be PM overlay. Some of PoP sprites are more then 20 pixels wide (couple of PMs combined width).

Fortunately 'colored parts' are little compared to whole sprite (hands, feet, face).

But that also means some kind of 'frankenstein' sprite routine for sprites combined from PMs with different x coordinates in different vertical regions....

 

Well, code will be the best judge

[sack-c0s]

I thought if you were preshifting the display data, then preshifting the mask to go with it was implied?

 

given that the prefabs that the levels are built from seem to align in certain ways I think there's optimisations that can be made there too. Ledges will always be in the same place relative to byte boundaries, so those animations might not need to be shifted, and walkcycles and shifts can be combined to cut down on the amount of data that needs to be kept in that respect.

 

Mirroring animation frames could be a ballsache though - even with a page-aligned LUT or 2 for flipping the graphics and mask data the process might make a big bump in the CPU time needed, unless the game looks okay at 25hz? or maybe this is one of those things a 1mb flash cart would just iron out?

[PeteD]

I doubt pop runs at 25fps anyway, probably quite a bit less and if you play the C64 version with your sprite and just 2 falling platforms it slows down quite badly.

 

As far as the tile masking etc, as I mentioned earlier in the thread, before Mr SID made it clear he was working on PoP me and Ste were working on one, a rewrite rather than a code port and as such we made the tiles sensible byte boundary sizes, all in chars and with masking areas made as code friendly as possible. That stuff is available if anyone wants to play with it although you're probably better off getting it from Ste as I don't think I got his final version.

[Rybags]

Pillar masks shouldn't need preshift for PF data. But their masking of PMG parts might.

 

The other consideration is that the piller masks also have to mask the softsprite masks themselves.

 

So the codepath becomes a bit more convoluted.

 

But, if you look at even the 16-bit versions of this game, the action slows down significantly when there's a few things happening.

[high voltage]

Actually, as David Crane mentiond the the magazine Hi-Res, a good game takes a year to develop.

In the UK they knocked up games during the weekend, most of them weren't any good.

 

David Crane and co also got wiped out by the "games crash" that only occurred in US. The UK's games industry boomed for 10 years so who would you say had the best business plan?

 

Do you want me to admit quantity before quality is the better business plan?

 

I reckon David Crane and co did, they continued to support C64, Apple ][, A8, Amiga and IBM (later NES,SNES). In the UK Activision started to support the Spectrum. That was NOT a good thing.

 

CGW mentioned that the 1985 - 1989 time frame was a very healthy computer industry, churning out excellent computer software. The games crash didn't affect the computer industry one little bit, CGW reviewed 100 games per issue or more.

 

Yes, UKs industry was booming too, I was there, I have to admit, excellent games came out for Amiga, ST, C64 (to a lesser extent); the later the 80s the better the games became.

Edited October 24, 2011 by high voltage

[flashjazzcat]

I thought if you were preshifting the display data, then preshifting the mask to go with it was implied?

I guess so - that's my input exhausted then.

[Rybags]

Yes, I misread that. Preshifted masks required, so we'll likely end up with a buttload more sprite data than the C64.

 

Mirror-flipping tables might well be needed to keep the amount down.

 

But I doubt the sprites are "symetric friendly" ie - a 0 shifted sprite facing left might equate to a 2 shifted sprite facing right.

[emkay]

Someone asked for executable, so here it is:

 

pop.xex

 

Forgot to mention that video is from Altirra with Pal system settings.

Cpu time left in Ntsc mode is much worse

 

Could you tell in numbers, how many CPU this is using right now? Framerate?

[sack-c0s]

Someone asked for executable, so here it is:

 

pop.xex

 

Forgot to mention that video is from Altirra with Pal system settings.

Cpu time left in Ntsc mode is much worse

 

Could you tell in numbers, how many CPU this is using right now? Framerate?

 

clue: it turns the border purple when it starts working, it turns it black when it's done. The border is mostly black.

 

That ought to tell you enough about how it's running, surely?

[Rybags]

VBI is right after the normal 240 scanline display finishes, emulators don't show that area.

 

So the "missing" part of the display is 72 scanlines or 22 depending on PAL/NTSC. Then throw in anything from 0-4 depending on what part of the VBI you start doing stuff.

[popmilo]

After some calculation it looks like 78 raster lines. On PAL that is 25%...

 

But any kind of calculation at this point is almost meaningless...

 

Masking, shifting, background, pilars, PMs + actual game code (must not be forgotten ) will have almost unpredictable impact.

 

ps. I am pleasantly surprised how much CPU time is available in PAL bitmap mode!

[emkay]

Someone asked for executable, so here it is:

 

pop.xex

 

Forgot to mention that video is from Altirra with Pal system settings.

Cpu time left in Ntsc mode is much worse

 

Could you tell in numbers, how many CPU this is using right now? Framerate?

 

clue: it turns the border purple when it starts working, it turns it black when it's done. The border is mostly black.

 

That ought to tell you enough about how it's running, surely?

 

Haven't been at my home PC when reading it.

 

I was wondering about "Cpu time left in NTSC mode is much worse ".

Seing the CPU usage in NTSC, let's say good night

Now, masking (front) has to be added, the shifting, and the PM , and the background objects movement.... 2 huge objects...

 

PAL version should be no problem... it seems.

[PeteD]

CPU time difference between PAL/NTSC matters less when the game runs at less than 50fps to begin with because you start to get into 2 frames on PAL = ~3 frames on NTSC in the same ms timeframe.

[sack-c0s]

I don't think 25FPS would be such an issue if it frees up time though. Frame rate isn't the issue - consistency is. I reckon a rock-solid 25 (or 30 for the NTSC folks) would be far better than occasionally missing 50/60.

 

does this absolutely *have* to run in bitmap mode though? I'd have thought that even a 128 char limit would still be enough to build the background display, which in turn would reduce some of the spot animations (flames for instance) to just cycling characters. or is there something I've missed?

[PeteD]

Guarantee it won't fit in 128 chars Maybe some screens will but there are ones that there's too much overlap of different types of tile which creates a heap of unique chars AND you've got to draw sprites into it all somehow. I've posted more info on FW about chars v bitmap..

[emkay]

After some calculation it looks like 78 raster lines. On PAL that is 25%...

 

But any kind of calculation at this point is almost meaningless...

 

Masking, shifting, background, pilars, PMs + actual game code (must not be forgotten ) will have almost unpredictable impact.

 

ps. I am pleasantly surprised how much CPU time is available in PAL bitmap mode!

 

Try to think the other way. Most games were done for NTSC. PAL Ataris "sleep" a huge part of a second with that games.

[Heaven/TQA]

which of the versions run in 50 FPS? the Apple 2 version? I mean is the gameplay based on FPS?

[potatohead]

That's what I was wondering.

 

The animation data available is 15 Fps tops. This game could run two frames and look excellent.

[PeteD]

lol, I wonder how many times I've said that in this thread so far

[potatohead]

Way too many. What I don't get is why there isn't some discussion over the excellent material Mr Sid has posted up so far: Recommended, BTW. He's doing a bang up job with the write up. I've already learned a coupla very interesting things. Seems the Jordan tradition of doing good write up detail is being continued. Very well done Mr Sid!

 

http://popc64.blogspot.com/

 

There really are two basic paths here. One is to rewrite the game, using only media assets, and perhaps a routine or two from the original, and the other is to port the original over, mapping the necessary bits into the computer capability, whatever that is.

 

A rewrite is huge!

 

The port is huge too, but a lot of core questions are already answered... A very significant amount of the discussion here so far isn't taking the original game into account.

 

A 1Mhz Apple runs this game nicely.

Edited October 24, 2011 by potatohead