So, as far as I am reading, an MSX (1) version is definitelly out of the question... a pity, as I really think this game is not the hardest one for an adaptation
About prodatron when he make SymbOs on msx MOST people said 'not possible, the main problem: THE VDP'.
Actually, I think the biggest obstacle was/is getting support. Back in the days, Ease already proved that a GUI could be realized, but MSX'ians are really command-line users, and atm the tools they're using on their MSX are not available for SymbOS (MB, MBWave, MBFM, Age (DD-Graph) etc.). Even with SymbOS around, I'd prefer a blazingly fast screen 0 tracker over a graphical (but slower) tracker in SymbOS, no matter how much prettier the SymbOS version will look.
I never liked the game. I never will like the game. But I do think that this game can be done on every possible screen mode the great msx has to offer. The question is not can it be done but just how much effort you want to put into.
But I see some others metioned this allready so never mind...
The problems are in the size of data required for the animations.
(and in the fact that in screen 2 it would suck... :RNFF
I can see the interest of trying to port that hame from a "see, it can be done" standpoint... but honestly for me this is one of the worse game in history. I got nausea just thinking about how bad the controls are and how frustrating that game is ! So what's the point of so much efforts to port the game ? There's plenty of perfectly good games to port instead (Sim City was a good example).
I never liked the game. I never will like the game. But I do think that this game can be done on every possible screen mode the great msx has to offer. The question is not can it be done but just how much effort you want to put into.
But I see some others metioned this allready so never mind...
Probably not as easy as most think. But i'm sure that if fudeba try to convert it from zx to a plain msx1 (like gng) the result will be good.
Not sure if worth... the effort....
The problems are in the size of data required for the animations.Megarom
The problems are in the size of data required for the animations.Megarom You mean: GigaROM
The problems are in the size of data required for the animations.Megarom You mean: GigaROM
Haha
Seriously though if spectrum version exists then we do not need a gigarom for it.Spectrum has only 6 kbytes of video ram for the ula plus 768 bytes for the pallete data and yet it has a very good animation of prince of persia characters (i dont care about color,animation is the key).If a 6kbyte vram can do it then a 16kbyte memory vram,or 64 kbytes of video ram or 128 kbytes of memory ram can do it.
some will say about the spectrum having direct access to the video ram without the bottleneck of accessing the vram through the vdp passing the data to z80.
My question is why didnt ascii ,-when they created msx2 machines-, connect the z80 to the vram directly?What was the purpose of isolating the vram and making it available indirectly to the processor through the use of out instructions?
was it for compatibility reasons?
would the vram access be such a big bottleneck for an msx version?if we supply the sprites of the main character as data ripped from the spectrum version,would someone want to do an experiment and show something preferably in screen 2?
i think the sky is the limit!
Spectrum has only 6 kbytes of video ram for the ula plus 768 bytes for the pallete data and yet it has a very good animation of prince of persia characters ...... If a 6kbyte vram can do it then a 16kbyte memory vram,or 64 kbytes of video ram or 128 kbytes of memory ram can do it.....
That's the point: as fudeba has pointed out, the more amount of vram means more data to manage, and msx have a slow vram access.... However, if a more critical Gng was successful i think also PoP can be done in THE SAME WAY.
some will say about the spectrum having direct access to the video ram without the bottleneck of accessing the vram through the vdp passing the data to z80.
My question is why didnt ascii ,-when they created msx2 machines-, connect the z80 to the vram directly?What was the purpose of isolating the vram and making it available indirectly to the processor through the use of out instructions?
was it for compatibility reasons?
@Nicodr:
Some easily does not see the key point. A little explanation shold clarify.
They say 'the vdp is the bottleneck' but really the vram speed is REALLY the bottleneck.
VRAM is BY NATURE contented in some form in all computers. CPU should have a way to write to and read from, while the video HW MUST access it in a time regular intervals.
Why accessing the vram via VDP is slow? Because the VDP itself is using the most of vram bandwidth for the task of generating video images, only a very limited amount of time is reserved for I/O from CPU. If you take a look to TMS specs you see that only 1 of 16 cycles is reserved for CPU access. (In screen 2, obviously depends on video mode) the remaining IS FOR VIDEO IMAGE GENERATION AND CANNOT BE INTERRUPTED without image corruption.
So even having a z80 access would not improve almost anything (to be precise, in some situation could improve the way we can access vram, resulting in a improvement, but on the majority this is not the true problem) because the video accesses from/to CPU MUST WAIT THE availability of VRAM. Only when VRAM is idle for the task of video generation the CPU can access. And the problem here is that the VRAM is almost always busy for video task.
Even a Pentium 4 must wait for vram availability, so a ungly z80 is halted for about the same period of time when it do a
ld a,(HL) if HL is pointing to contented vram.....
In the old days there was only an exception of the above rule of precedence. (AS I KNOW) The earlier PC CGA video cards. On those, the access made by CPU halted the access made by the VIDEO HW causing the well known snow flickering (because as said, VIDEO access MUST takes precedence, it's time critical). Most text-editors of those days have a command line option referred as 'prevent cga snow flickering', with this enabled, basically the 8086 accesses cga vram only on vblank... so no image snow flickering....
So when developing v9938, Yamaha designers have improved the vdp by eliminating some VDP related delays but cannot do more on vram speed. (Without needing a faster vram). This is because vdp access speed it's mainly dependant on VRAM speed.
Conclusion:
Even having direct video ram access does not improve the vram access speed a lot if you do not have a FASTER VRAM CHIP.
You may notice of the ADVRAM kit that do direct access via z80 on VDP VRAM.
If you look at the speed tests, you will see a great improvements only on R800 machines (=FASTER processor). Those speed improvement does not come to the direct cpu access, but is largely thanks to the FASTER VRAM CHIPS, allowing without delays CPU and VDP access in different times, at full CPU SPEED (say for example 1 time chunk for vdp 1 time chuck for z80)
if each time chunk is long as needed to satisfy the CPU / VDP requirements the trick is done!
(To be honest the VRAM test in ADVRAM are made specifically to amplify the difference between z80 access and vdp access, but that's another story)
Hope this is clear