Maniac Mansion?

[MacDeath]

No Magic, only loosy technologie and weird Science...

The PLUS cartridge port is one of the worst ever...
But 512K+Compression may be more than enough to get a good SCUMM-like point-and-click...

Just not as advanced as Monkey island...

[Xyphoe]

Would people generally by that excited about a Maniac Mansion / Monkey Island port first and foremost though?

[jbaudrand]

honestly I was just asking a technical do-ability, I will be more happy to play a new game instead of a remake. And furthermore LF is not  friendly for people who pretend to sold cartridge...

[arnoldemu]

Would people generally by that excited about a Maniac Mansion / Monkey Island port first and foremost though?

I believe doing a port of the scumm engine then potentially opens the cpc up to the other games based on that engine.

However, personally if I were to do it, I would make my own engine.

So for me the engine is:
1. 1 mode 0 screen (parts possibly animating)
2. a character which moves around and moves behind some things
3. you examine things and perform fixed actions.
4. it then does something based on this. (so some kind of scripting behind the engine)

The hard part, and long part is to actually make the content (the great screens, the story, and how it all works together).


EDIT: Me and a friend analysed leisure suit larry on the atari st. it had a 16 colour screen describing depth, it had another screen defining the collision areas (black/white per pixel), and the 16 colour picture itself.
We didn't work out the other parts of it.

Obviously we can't do this kind of thing on the cpc like that, we would have to do it a completely different way.
or design it so you can't go behind things

I believe leisure suit larry was coded in C on the ST, so perhaps coding an alternative engine on the cpc in C would be a good idea

[Targhan]

I really don't know why people get crazy about RAM extension and all that stuff. Don't you know how much a CPC can handle ? The whole Orion Prime intro (minus the fullscreen+digisong) is loaded in a single time. Exomizer and good memory handing can do wonders.
Zac Mc Kraken on ST loads between every screen, it's quite slow, and I'm sure we can do faster on CPC with simple trackload, like the ones I shared years ago.
The two problems are :
- Making a powerful engine is a hard and long work, especially if you want third-party to use it in a user-friendly manner.
- Amount of gfxs to draw/transfert.
Trg.Aks

[sigh]

I believe doing a port of the scumm engine then potentially opens the cpc up to the other games based on that engine.

However, personally if I were to do it, I would make my own engine.

So for me the engine is:
1. 1 mode 0 screen (parts possibly animating)
2. a character which moves around and moves behind some things
3. you examine things and perform fixed actions.
4. it then does something based on this. (so some kind of scripting behind the engine)

The hard part, and long part is to actually make the content (the great screens, the story, and how it all works together).


EDIT: Me and a friend analysed leisure suit larry on the atari st. it had a 16 colour screen describing depth, it had another screen defining the collision areas (black/white per pixel), and the 16 colour picture itself.
We didn't work out the other parts of it.

Obviously we can't do this kind of thing on the cpc like that, we would have to do it a completely different way.
or design it so you can't go behind things

I believe leisure suit larry was coded in C on the ST, so perhaps coding an alternative engine on the cpc in C would be a good idea

I agree with this. I always liked how on Monkey Island that Guybrush would zoom in out of the background.
On a normal CPC, I would go mode 1 and really stylize it. Film noire-ish using the black, grey and white for backgrounds with sharp bright colour on the sprites, in a similar look to Tim Burtons Sleepy Hollow.

[TFM]

I really don't know why people get crazy about RAM extension and all that stuff. ...

Hehehe! Well, that's like buying a bigger car... You may not need it, but you get used to it very quick - and then you can't live without it. (A new girlfriend could be also such an example, if the new one has bigger .... RAMs). 

[andycadley]

So usually you use the screen RAMs starting at &0000 and &C000. If you move a sprite, then you must be able to access both blocks. Finally your code must be located between &4000 and &7FFF.

The secondary rom mapping register in the plus can put the lower rom at &0000, &4000 or &8000, so that's not an issue and, of course, you don't have to place the second screen at &0000 anyway.

[TFM]

The secondary rom mapping register in the plus can put the lower rom at &0000, &4000 or &8000, so that's not an issue and, of course, you don't have to place the second screen at &0000 anyway.

Well, you do have to put the second screen at &0000, because at &4000 you want to bank expansion RAM in and the block between &8000 and &BFFF is the _only_ true commen memory block, which is _always_ there (as long as you use 16 KB RAM banking and not 64 KB block banking. The latter makes usually no sense).

Further the secondary ROM mapping register controls _only_ the position of the Low Bank ROM, but you can't use others that way, which doesn't bother. But using the LBR that way, screws up other aspects.

But what do you want to say? Do you think 64 KB RAM is too much for the GX4000 Well, for e.g. sprite routines my argument seems to be still right. But if you find a better solution, great!

[Joseman]

Hi

one of my dreams on cpc always been a monkey island game (my favourite monkey island 2)

i've talked a lot with some friend of mine about the possibility of doing this, but, the task is very difficult and i don't have the knowledge.

I thought too that the most easy road to achieve this was look for the weak version on pc compatibles (CGA or something like this), then, in my search i found the most strange conversion of monkey island in the world, for a calculator!!

here is the link: http://www.ticalc.org/archives/files/fileinfo/103/10378.html

the trick is that this calculator is based on a motorola 68000 cpu

anyway a curiosity

regards

[andycadley]

But what do you want to say? Do you think 64 KB RAM is too much for the GX4000 Well, for e.g. sprite routines my argument seems to be still right. But if you find a better solution, great!

ROM mapping on the pluses is pretty sophisticated, you can have any one of 8 ROMs act as the low bank, so that's 128K of ROM you can basically put anywhere and the rest having to sit in the upper ROM area. And the fact you can still write to RAM when a ROM (but not the ASIC registers) is paged over it means that paging it over the screen is rarely a major issue. In any case some combinations are fine, you're rarely writing to the screen when you have the ASIC enabled, for example. Once you've written code for a system that has to page a *lot*, it generally gets easier to work with more complex banking arrangements. 64K RAM may not sound a lot, but it's actually quite generous for a console like the GX4000 and what you get from 128K (which has it's own paging issues) is minimal at best.


I've said many times in the past that coding for the pluses can be a pain in the butt if you aren't writing for a cartridge, because the hardware configuration (like ASIC paging) is severely sub-optimal in that case and gets in the way of RAM paging which clearly wasn't considered important by the designers. Writing a 128K plus game is actually a real pain, JSW+ has pretty much the entire game running in page 7, since it's the only one that can be fixed at &C000 whilst allowing paging to almost all the RAM (the 16K in page 3 was reserved for DMA lists because it's almost unusable otherwise). Doing it for a cartridge would have been so much easier and would've required far less troublesome interrupt and stack handling, even if the cartridge had similarly been just 128K and it would then have run of a 464+/GX4000.

[TFM]

Yes, right. And so if one likes to convert a game to the Plus, the best is a complete rewirte of the banking. This way you have less exp.RAM issues and the enhanced ROM features can be used. Boiled down it's a lot of work if you want to do it really good.

One good thing is though, beginning with ROM select &80, you can access all 16 KB blocks of the cartride one by one (&C000-&FFFF). And that's important, everything can be banked to &C000, so a small common area can allow to jump from ROM to ROM without using a routine in RAM to switch ROM blocks.

[redbox]

One good thing is though, beginning with ROM select &80, you can access all 16 KB blocks of the cartride one by one (&C000-&FFFF). And that's important, everything can be banked to &C000, so a small common area can allow to jump from ROM to ROM without using a routine in RAM to switch ROM blocks.

But this means you are still just treating the Plus like it has a RAM expansion (albeit a ROM expansion really).


The real power does lie with being able to page the lower 8 blocks into various positions with the RMR2.  If you do this, you don't really need a RAM expansion or even 128kb.  64kb would do nicely and it will work on a 464+, 6128+ and GX4000.


Longshot explains it well (in French) on the CPC Rulez website for anyone who is interested. 

[TFM]

But this means you are still just treating the Plus like it has a RAM expansion (albeit a ROM expansion really).

? Eh, no, have been talking about ROM blocks.

The real power does lie with being able to page the lower 8 blocks into various positions with the RMR2.  If you do this, you don't really need a RAM expansion or even 128kb.  64kb would do nicely and it will work on a 464+, 6128+ and GX4000.

Sorry, but I can't agree. As a machine code (only) programmer I know about the power of self modifying code. This can't be done in ROM. To bring this on the point we're talking about 20%-50% speed up or even more in certain circumstances. The difference on the screen is then either ugly or looking perfect.

It's nice to have a lot of ROM, but RAM will be always remain more prescious.

Even FutureOS is executing some sort of routines in RAM for good reasons.

[MacDeath]

So lets just do it on Thomson TO8... it has a native 256K ram...

ok...\troll


Anyway I agree with the importance of RAM on computerz...
While console could work well with a ridiculously small amount of RAM, we must keep in mind there were mostly Action games (arcade) where the Ram is only used to keep track of the score, the number of lives and replays, the actual power-ups configuration and which level you are...

Also i think many console had a proper extension port as Cartridge port.
Hence you could even add Ram on the cartridge in case you want to do a more "mature" game (RPGs perhaps...

But on an Amstrad PLUS, the Cartridge is ROM only... and limited one actually.
Also the Hard-support is too limited to enable a full Hardsprite setting...
So we need soft-sprite (use Ram to get the routines...) and said RAM may also be used to uncompress or craft sprites from bits of sprites...
Or even stuff like reverse sprites (from left to right...), recolour them or whatever...


And a Game like Maniac/Monkey Island may get a bit messy if the story is well developped...gotta keep tracks of the inventory, of some dialogue already said and so on...

Also if the Backgrounds are to be "unique paints" with lot of ditherings instead of tile based simple compositions, this can really get the 512k ROMstuffed very fast.

BTW aiming for a 6128 config is the best way... Disk Drive is quasi unlimited storage (sort of).
But yeah, lots of loading then.

In case of a 464+ or GX4000... the game would have to be far more limited in content.

No Operation Stealth port then...

Also... while the 464+ can still be suitable because it has a proper extension port and a Tape Drive (lol) the GX4000 is quite difficult concerning Game Saves...

And a complex SCUMM based game do need a game save/load system !

ok perhaps using codes... erf... this will be soo fun to note or enter a 32 characters Hexadecimal sequence with the paddle...


Rom is good to have basic (not in basic, but basical...in assembly of course...erf...) engine mecanics or even some Datas... But Ram and disk drive (or even keyboard and more RAM) is also so precious...


Also there may be a limitation on the CPU speed the ROM or RAM may bring...

beyond certain point, additionnal RAM/ROM is only relevant concerning Loading time... not CPU speed.

[redbox]

? Eh, no, have been talking about ROM blocks.

I meant by only paging into &C000 it is treating the ROM like a RAM page-in, where as infact a ROM page-in can happen in different places.

Sorry, but I can't agree. As a machine code (only) programmer I know about the power of self modifying code. This can't be done in ROM. To bring this on the point we're talking about 20%-50% speed up or even more in certain circumstances. The difference on the screen is then either ugly or looking perfect.

Absolutely, but it all depends on what you're programming.  Self modifying code can be quicker, but usually it's done to be quicker when you have limited memory.  With the cartridge you don't really have this problem and you can unroll loops (because you're not worried about running out of memory) etc to attain speed increases.

[TFM]

   Well, usually the reason for using self modifying code is to make it more quick, saving some bytes is more a side effect. I mean, the CPC has at least 64 KB, so saving RAM it not really that important. But right it depends on what you want to do. So it's good to have enough RAM just in case.

However, we're getting off topic...

[redbox]

  Well, usually the reason for using self modifying code is to make it more quick, saving some bytes is more a side effect. I mean, the CPC has at least 64 KB, so saving RAM it not really that important. But right it depends on what you want to do. So it's good to have enough RAM just in case.

32kb left if you take 16kb for the screen and 16kb for the ASIC page-in.  Or 16kb left if you double buffer.  Not much room there for compiled sprites or unrolled loops 

However, we're getting off topic...

[andycadley]

32kb left if you take 16kb for the screen and 16kb for the ASIC page-in.  Or 16kb left if you double buffer.  Not much room there for compiled sprites or unrolled loops 

You don't have to leave the ASIC paged in, so it hardly counts as losing 16K.

[redbox]

You don't have to leave the ASIC paged in, so it hardly counts as losing 16K.

Absolutely, but you can't leave anything in there that you want to put into the ASIC. 

[jbaudrand]

  I never could imagine such a technical topic just by asking "maniac mansion?"

[redbox]

I never could imagine such a technical topic just by asking "maniac mansion?"

Isn't a forum such a wonderful thing.

Anything that sparks a debate, no matter what tangent it goes off at, is a good thing for a community like the CPC 

[MacDeath]

http://picasaweb.google.com/dadcezgs/AmstradCPC#5523478771345974946



Dadman seem to did this.

[arnoldemu]

http://picasaweb.google.com/dadcezgs/AmstradCPC#5523478771345974946



Dadman seem to did this.

it is a mock up.

I'm going to get a picture of farcry and convert it to cpc+ picture.
Maybe I could pretend it was real 

Think CPC+, first person shooter.....

Macdeath has had to go for a cold shower 

[Devilmarkus]

Well we all know there exist "Doom" for CPC+, don't we?