Please have a look at this link:
http://cpcrulez.fr/forum/viewtopic.php?f=6&t=4271&start=0
As i said on CPC rulez , i think it is a fake.
Maybe some interesting mockups but not real + screens.
Quote from: CPCIak on 11:01, 19 July 10
Please have a look at this link:
http://cpcrulez.fr/forum/viewtopic.php?f=6&t=4271&start=0 (http://cpcrulez.fr/forum/viewtopic.php?f=6&t=4271&start=0)
Yes it's a fake!
Sorry just had to use the new spoiler function again!

The screens have been mocked up in photoshop, reduced down to the Plus pallette.
lol Xyphoes , nice usage of the spoiler function :laugh:
it's a pity :(
The resolution is correct, colors are correct, but it's OBVIOUS those are 16-bit screencaps that have been re-rendered. Not with Photoshop but with the tools we already have - don't you recognise the dithering? In any case, this is 100% modern-day rendering techniques.
Still, nice mockup...
Yeah its a fake, but there is no reason why it couldn't be real other than it would take somebody talented, dedicated, and with a lot of time. The Plus, 128k and a Disk is perfectly capable of doing such I reckon.
As I told, the Atari ST or PC EGA versions of IndianaJones 3, Loom, Monkey Island or ZakMacKracken and maniac mansion, even leisure suit larry...
Can be achieved on a 6128+, as some of those were even released on C64...
Or with a 320x200x16 (ST and EGA).
If I could get my hand on the graphical datas, getting it on a mode0 PLUS can completely be achieved.
Of course animation would be a bit reduced and you'll get shitton of Disk access... or have to manage memory extensions too...
But not that much different to an Orion Prime like game.
Monkey Island 2 was VGA from the start, and used more advanced PC configs at the time... the 320x200x256 is not that easy to put on CPC...
But 320x200x16 can really be modified to be 160x200x16 on CPC..
Those shots really looks nice, but the fact that Monkey 2 is one of the largest amiga games of 12-13 floppies its kinda obvious that it must be a fake. Also the game was one of the first games to support hdd install. Not a impossible feat but close to impossible as the game is just so large.
Monkey 1 however was just the 4 floppies i feel is much more do-able. Most of the time you just walk around picking up stuff or talking to people, and the no of actual animations are few and small. Like being shot out of the cannon is seen from "bird" view on the island screen. The first "fight" against a pirate is cleverly happening in the next room over .. so you dont actually seen the fight but just the speechbubbles with "crash" "boom" and similar. The later fight against the sword master is speech based too. Even "complex/time"-based puzzles like you have to wait for the chef to exit the kitchen before you can enter .. seems quite do-able (and quite few of them). Still even with some sort of orignial source code/script its a massive job to do.
Still, if they could do BAT then it should have been quite possible to make some of the smaller point and click games. Like early Space Quest/Universe/Larry etc.
Its possible to do, thats a fact.
But ;-)
you need BDos and a Symbiface to do that. Timo and me we had that idea years ago and we started to write a new adventure engine and i was working at new ideas and converted some screens too.
If you install that game on a harddisc, its would be working ultrafast and fine with a CPC Plus or a normal 128 KB CPC, its not possible to play that from standard 3,5 Discs. But BDOS could handle such files and such huge Adventure Engines.
Kindly Regards
Tom
Also we have to remember that graphicall datas are quite big on a CPC compaired to most other 8 bits...
But when compaired to any 16bit, it is a small dick actually.
16K is a lot for a 64K (or even 128K) computer, yet for a 512K computer (PC, Atari, Amiga) or even 1024K Ram (or simply 640)its really nothing.
The average Atari ST 320x200x16 use twice more bits...
And an amiga despite the numerous specialised Hardwares, had music with lots of sampled sounds and 32 colours modes... this do a lot of additional bits... and as those were a lot more animated too...
A CPC can give a decent result IMO, even with only 128K, it just need shitton disk access but then a memory upgrade enable to pass through that.
So not a symbiface, just a +512K and 720K 3"1/2 disks...
The GUI can be bypassed a bit with shortkeys and joystick.
Limiting the Point and click only to the game's window, while the actions or objects are selected only with the keyboard :
F1-F9 : the 9 action.
Arrow : search inside the bag.
1-8 : select said object...
Because just having one mouse like pointer to selct on the game and actions and objects is too...slow.
Perhaps concerning Monkey Island 2... the lack of tile based graphics means it gets a bit bigger.
That's also why I suggested to dither a bit less and simplify the textures, so you can re-use a bit of tiles.
Simply because despite the sweet looking mockups, a CPC/Plus is clearly not as powerfull as a HDD VGA 386 PC with 1meg RAM.
Speaking about games using a lot of storage space, the way the HXC SD floppy emulator is taking is very impressing.With a software selection of the HFE image , that would be possible to manager multi disc games without manipulations with a "simple" floppy emulator.No need a HD , just the emulator and a SD card ;D
Quote from: Pentagon on 21:38, 19 July 10
Its possible to do, thats a fact.
But ;-)
you need BDos and a Symbiface to do that. Timo and me we had that idea years ago and we started to write a new adventure engine and i was working at new ideas and converted some screens too.
Well, FutureOS and a 3.5" floppy is enough ;-) Even if I'm busy with some small projects and even in Tolkin and me will finish Giana maybe not so quick, this doesn't mean that Gerelakos is forgotten.
Sorry but I can't se why an OS+Game is better than a purely assembler game ?
BDOS is a pure Harddisc OS and games loaded with BDOS can be load in under 1sec. So its also possible to save extreme huge data. (Like *.wav files or very Huge Picture Data) - the file size could be tons of Mbytes.
So if you code an Adventure Engine wich is using the advantages of a pure harddisc, the result is an ultrafast loading game wich is running from the "unlimited space" of you r harddisc drive.
We tried some nice things with that, like really huge wav files or big picture data. I think Prodatron did the same, but with SymbOs.
FutureOS is nice and can load fast too. But it have the Disc Limitation (a Dobbertin Disc is not avaiable anymore - so nobody can use it). I am talking about a modern solution who is usable to anybody.
Personally i would prefer a Monkey Island from SD Card. But Harddisc is so much faster thats impressive. I can load a 128Kb *.SNA File in just 2 seconds. Its "The Data Pump" for any CPC.
So anybody with a Symbiface can try that too. Monkey Island on a CPC6128 PLUS with a nice Adventure Engine (scumm like) and a overscan Plus feature graphics, running from a Harddisc. Well, sounds great and its really fast.
The solution for anybody would be the SD Card like fano told about. FutureOS could be used too, but then you need to juggle with Discs, cause nobody have an ultrarare Dobbertin Disc at home. To be honest that vintage MFM Monster.....i wouldnt trust my data on it.
I am using a 1gigabyte Seagate 2.5 Inch IDE Harddisc and its full working since 6 years now, without any issue. If you code in purely Assembler and use the Harddisc power, well it should be a fine and ultrafast game.
Kindly regards
Tom / Pentagon
I don't see why a LucasArt type game couldn't be done on CPC. Sure it would load a bit between the screens, but it's perfectly doable.
... And please, don't even consider using extra hardware or more than 128k because no one will ever be able to play the game (except 20 people).
Good loader + good compresser (Exomizer, MegaLZ), and that's it.
Trg.Aks
Quote from: Targhan on 08:56, 20 July 10
I don't see why a LucasArt type game couldn't be done on CPC. Sure it would load a bit between the screens, but it's perfectly doable.
... And please, don't even consider using extra hardware or more than 128k because no one will ever be able to play the game (except 20 people).
Good loader + good compresser (Exomizer, MegaLZ), and that's it.
Trg.Aks
I agree that it is possible, and of course ram decides how much can be done in each location. Then disc size decides the number of locations.
I also agree with Targhan about 128k. This kind of game really is only suited to 128k + disc. I would say really impossible to do for cassette so not worth thinking about.
This game would also be good for cpc+, the only thing to consider is that the man can walk behind some parts of the scenery, so that if sprites are used, then these must be masked in some way so that this works correctly.
My thoughts are that this game is really nice, but really I still think that first making a smaller adventure would be the better idea but using a similar game engine.
Keep the adventure small and then when it is completed, the team who made it would easily know the limitations they have to work with and then they could try a bigger game.
QuoteThis game would also be good for cpc+, the only thing to consider is that the man can walk behind some parts of the scenery, so that if sprites are used, then these must be masked in some way so that this works correctly.
Animating well Hardsprites for the hero is not that interesting, on the other hand using said sprites to patch the background, hence some front sceneries... may be better perhaps...
Or some little additionnal special effects or animations...
That's why I suggested to start with less coloured backgrounds (= not a VGA original), because lots of sprites will have to remains softwared.
Yeah the result may be looking inferior, but on practical purpose this is optimisation for a realistic engine.
And the screen can still manage to feature more than 16 colours because you can put more Mode/Raster changes on a plus for the Actions and inventory parts of the interface.
(And Hardsprite patches, and Border...)
Also it is to notice that even with a 128K Ram version, a lot of datas remains from one location to another...
Hero's sprite, inventory and actions part, some script elements too...
You "only" have to reload :
--The graphics for the actual location : may be something like 2-4 screens...can actually be a bit compressed or include some re-used tiles if you dither a bit less/simplify a bit the graphics...
--Some few additionnal sprites : the peoples you may interract/chat with, or the objects you can tak/interract with.
--Scripts...
Monkey Island was very graphicall, a lot of special animations and so on...
But this can also be lowered a bit without reducing the overall game's interest.
And, well... Porting an existing game is great, this eases the work to be done, yet an original game can also be achieved...
As you know, Georges Lucas is somewhat greedy and has a legion of Lawyers Jedi Clones... :laugh:
Oh, reminds me of the game NightShift...
I had it on EGA PC yet the Speccy port on Amstrad seems somewhat shitty... :'(
Quote
This kind of game really is only suited to 128k + disc.
Of course 128K may be enough to get it playable, but enabling management of more may not be that complicated then as it would just reduce the number of loading, so enable a smoother game experience, without needing a complete rework of the game's engine..
And perhaps more musics then... ;)
The good part of a game like Monkey Island is that it is devided up in parts. Monkey 1 has 4 parts and as the parts dont reuse much data its would be like programming 4 "mini" adventures.
Part 1: This is the major one with a lot of screens but few is used at the same time. The main screen is the Map screen .. used to get from one small location (2-4 screens) to the next small location (another 2-4 screens). The Amiga game loaded a LOT from disc. Even in the middle of town there is a obvious "halfway" where the game loads the next screens/data.
Usage: 128kb ram, mode 0 & 2x 180kb floppies i guess. The good think is most of the locations are "locked" from entering at first so you could add all the open areas on floppy 1 and the locked one floppy 2. One screen would take 10-12k raw ram (as the menu is the lower 1/3 of the screen). Largest panoramic view is 2 screens wide-ish and has very little action. Single (still) screens may have "taking to pirates"-pictures but these are few and must squeeze into nothing using a good screen archiver (as the pics are quite blank except for the pirate head). Leaving out audio but keeping the txt, scr, anim & engine and it might squeeze in there (or use 3 floppies, who cares when it loads so fast from 3" ).
Part 2: Very small part this one, might as well put this one on the same floppy as the 4th part. No map screen and perhaps just 4-5 actual screens to visit. Lots of talking and puzzle.
Usage: less than half a floppy.
Part 3: a bit like the first part but smaller. Much less puzzles. still a good handfull of screens and small animations.
Usage: Need another 2 floppies i think. Again some parts are locked at first so having the "open" parts on the first floppy and the rest on a second makes sense.
Part 4: this is a extremely small version of part 1 (graphics/maps/screens reused, but recoloured), but as the whole thing is quite limited only a few screens are accessible. Very little talk and puzzle.
Usage: half a floppy?
If you cant remember how Monkey1 goes there is a quick 4 min flash animation here (dont watch it if you havnt finished the game or dont want to remember):
http://www.youtube.com/watch?v=MXoO9JslgBk
Quote from: MacDeath on 00:03, 20 July 10
Sorry but I can't se why an OS+Game is better than a purely assembler game ?
If your OS is in the ROM, then the game can use the OS routines without wasting RAM for this kind of routines. For example load file, save highscore, manage expanson RAM, screen decompression etc...
And like Targhan said 128 KB is the standard today. Now subtract 32 KB screen RAM. So 96 KB remain for the game. That's just not much.
If your OS is quick, then it _will_ be used by game developpers.
If you have a relatively slow OS like AMSDOS or CP/M developpers use it only to start the game.
(see Orion Prime).
Edit: If a hard-disc shall be used, then todays solutions (SF-II and the IDE8255) must be used (there I agree with Tom) with at least FAT32 format (or higher).
Any kind of propietary format provides too much work for the user. And somebody who wants to play a game (from hard-disc) can't be forced to reformat his hard-disc first!
This means finally, in this moment there is not one suitable system, if you think about it.
Bdos could be mounted at any DOS / Windows PC too. Timo wrote a native support for that. FAT32 is not the advantage Format for a CPC. But thats an OT Discussion. Fact is, BDOS can handle it and its very stable and safe to use.
I bought a normal harddisc just for cpc. Formated to BDOS format and i can use the same disc in a DOS / Windows PC too. BDOS can handle long *.wav Files and superhuge files to stream relative into the memory of CPC. So its here, just download and use it. Give it a try and you will see its easy to use, and can do that.
I dont know nobody who is using FAT32 at the cpc for serious working. Sure it would be easier to transfer the data from PC. But since Timo wrote BDOS Driver for PC its not an argument.
But hey, thats okay, i respect your opinion very much. I just want to explain what would be possible with that system, if the people would understand and use it.
Kindly regards
Tom
QuoteMonkey 1 has 4 parts and as the parts dont reuse much data its would be like programming 4 "mini" adventures.
Same engine, different datas...
Even a disigner kit could be achieved...this would indeed be the best choice...
Enabling scripts AND screen designs/graphics integration...
QuoteSpoiler for Hiden
Fuck years...reminds me a lot...
Quote
If your OS is in the ROM, then the game can use the OS routines without wasting RAM for this kind of routines. For example load file, save highscore, manage expanson RAM, screen decompression etc...
Ok, then OS ROM means you need other hardware than disks and Basic Cartridge...so not the average 6128+ config... Yes, additionnal routines means a lot of cool stuff with no RAM wastes... but...well... while you're at it, why not simply a ROM+Disk game then ?
IMO the best a 6128+ could offer would be a 512K cartridge + a 3"1/2 with 720K disk (or even more than one...).
But hey...the problem remains... this is actually extra hardware...
And the 512k ROM would actually include quite few routines, and a lot of...graphics and stuffs...
But I aggree the PLUS range lacked a proper ROM/cartridge based OS... Loco 1.1 basic was quite not good no more...
Perhaps we'll do some hardware tests this weekend with my brother... (now he has his FPGA board...)he told me so, but I have to organize my birthday party for saturday... :P
Massive hangover and left foot (the broken one) pain incoming... :o
Anyway.... instead of all these threads about old games, that everyone has already played, being ported to CPC, why not focus on creating a new game for multiple platforms instead?
The problem with threads like this is not the impossiblity of being able to implement on the cpc, but more the improbability of somebody spending the time and effort to do so.
Clearly the way forward for this is for somebody to make a game designer, able to do a monkey islandish game, and others similar. This is basically a way that allows the non programmer types to get involved in a way they just cant at the moment.
I think as a group we need to look at ways to actually work as a community to get projects designed, and built, not just talking about it. Orion Prime possibly shows that sales can actually be fairly high (around 200). This though not a commercially viable level its a higher amount than I would have expected, and actually given the modern tools and PC based development it might be expected that a 1984/1990 3 month amstrad project might take half that time.
For instance is it possible that as a community we might develop and publish games? Some of the Revelo big box games are lovely and desirable in themselves.
And that development is shared out, and people add as much or as little as the want, including a full design doc.
That we as a community develop a number of standards formats for mapping, engine and characters so that all routines become freely available to anyone and are fully documented, and to a large part interchangable.
That existing coders should release interesting code to the community
A pool of graphics and sprites should be harvested from the thousands of existing software.
>This though not a commercially viable level its a higher amount than I would have expected, and actually given the modern tools and PC based development it might be expected that a 1984/1990 3 month amstrad project might take half that time.
Yes, but we all have day-job and things to do besides CPC. That's why games that should have been produced in 1 month has been done in 10 years (Color lines...).
Just so you know, Orion Prime disc system code takes a bit more than one KB in memory, so it really doesn't take a lot. 128k + floppy is the way to go if you want people to play your game...
Quote from: Trebmint on 09:10, 21 July 10
The problem with threads like this is not the impossiblity of being able to implement on the cpc, but more the improbability of somebody spending the time and effort to do so.
I would have done it, but I already have 3 projects lined up.
Quote from: Trebmint on 09:10, 21 July 10
Clearly the way forward for this is for somebody to make a game designer, able to do a monkey islandish game, and others similar. This is basically a way that allows the non programmer types to get involved in a way they just cant at the moment.
I was thinking about a similar idea for elvira.
The idea would simply be to write the core code, then provide the other team members with the build scripts and data.
They would then populate a spreadsheet with the required information and the tools would convert this into game data.
They could also add graphics and with some minimal editing to build scripts, add these to the code.
So here, other people who are not so strong with programming, or who wish to help with the other tasks can help to finish the game.
from my experience, if you are talking tools and tool chains, then most of the time you will find they evolve as you develop a game. You will find where you need to make changes to improve the flow.
Quote from: Trebmint on 09:10, 21 July 10
I think as a group we need to look at ways to actually work as a community to get projects designed, and built, not just talking about it. Orion Prime possibly shows that sales can actually be fairly high (around 200). This though not a commercially viable level its a higher amount than I would have expected, and actually given the modern tools and PC based development it might be expected that a 1984/1990 3 month amstrad project might take half that time.
Well I think already people are working in teams, but maybe it is not so obvious.
Devilmarkus and Mr.Lou helped me with Blue angel. I need to fix 2 remaining bugs and it will be released.
But for me the development time is long because real life takes over mostly.
Quote from: Trebmint on 09:10, 21 July 10
For instance is it possible that as a community we might develop and publish games? Some of the Revelo big box games are lovely and desirable in themselves.
The mojontwins do a good job as a team of developing and publishing games.
However, most of their games seem to use the same engine.
They use C for easier code development and use existing libraries for gfx and sprites
Quote from: Trebmint link=topic=1150.msg11460#msg11460 date=1279699808
And that development is shared out, and people add as much or as little as the want, including a full design doc.
That we as a community develop a number of standards formats for mapping, engine and characters so that all routines become freely available to anyone and are fully documented, and to a large part interchangable.
That existing coders should release interesting code to the community
A pool of graphics and sprites should be harvested from the thousands of existing software.
This is all a "perfect" situation.
The source code, build tools and all data for blue angel 69 will be released at the same time the game is released.
I found however, that the game evolved as it was being developed. Certain features had to be changed to fit into ram.
Your idea to develop games as a team is a good idea, but either you are being very optomistic or I am being very pesimistic (or realistic?) in terms of effort and time.
I would love to see other games released for cpc, both small and big, so really anything that is released that can help is excellent.
Quote from: Pentagon on 23:51, 20 July 10
Bdos could be mounted at any DOS / Windows PC too. Timo wrote a native support for that. FAT32 is not the advantage Format for a CPC. But thats an OT Discussion. Fact is, BDOS can handle it and its very stable and safe to use.
So BDOS can handle FAT32? Is that correct?
About FAT. I'm not it's biggest fan, but it has an advantage of MAJOR importance. And this is true if we like it or not! If you want to fill a FAT formatted hard-disc or SD card with CPC software, then you just plug your hd / SD to a PC and fill it up with data.
And sorry, I neither want to install a new OS (BDOS f.e.) on my Laptop (it was had enought to get Windoof 7 running), not do I see another way to fill my hard-disc if it is in a proprietary format. If I'm wrong please correct me. It's always time to learn something new.
However, I don't want fill my hard-disc by juggling 3" discs :'(
Quote from: MacDeath on 02:07, 21 July 10
Ok, then OS ROM means you need other hardware than disks and Basic Cartridge...so not the average 6128+ config...
Nope, there is no reason why an advanced OS couldn't be in the same cartridge. 512 KB ROM is enough (if not compress it ;)
Quote from: MacDeath on 02:07, 21 July 10
Yes, additionnal routines means a lot of cool stuff with no RAM wastes... but...well... while you're at it, why not simply a ROM+Disk game then ?
Well, that's just a DOS, it misses the other features. But right, it can be at least a step in the right direction.
Quote from: MacDeath on 02:07, 21 July 10
... but I have to organize my birthday party for saturday... :P
Massive hangover and left foot (the broken one) pain incoming... :o
Oh man! I wish you the very best to survive it!!! What did you do with your foot? (Kicking an c64 user? ;D )
Quote from: mr_lou on 05:15, 21 July 10
Anyway.... instead of all these threads about old games, that everyone has already played, being ported to CPC, why not focus on creating a new game for multiple platforms instead?
There are other threads talking about new games. And about multiplatform... If you do something for mutliplatform, the result is always ugly. Do it for one system, then you can do it right! And btw: Where do you find a multi-platform expert, I know one guy who has that knowledge, but he has no time for nothing.
Quote from: Trebmint on 09:10, 21 July 10
The problem with threads like this is not the impossiblity of being able to implement on the cpc, but more the improbability of somebody spending the time and effort to do so.
You talk out of my deepest heart! :) Only people who have developped a bigger project can understand this. For a a newcomer it's easy to mention wishes, but if you look how much time you have to invest even in a small project (... and by the way we all have regular jobs, except PDT, he has all time for the CPC) then you think twice about the size of a project. And things like multi-platform are overkill, not one of us is a "CPC company" with a dozen or more man power.
Quote from: TFM/FS on 16:51, 22 July 10
About FAT. I'm not it's biggest fan, but it has an advantage of MAJOR importance. And this is true if we like it or not! If you want to fill a FAT formatted hard-disc or SD card with CPC software, then you just plug your hd / SD to a PC and fill it up with data.
I agree here it isn't always important of the extact format of the storage system.
For me, I want to use these storage systems like amsdos. And in my programs I want to use firmware functions to open and read files.
Then my programs will work if I copy them to mass storage with no changes, and also I don't need to detect hardware and make special code.
I want to use the storage system so it is transparent. Use the functions I know to do the tasks I want.
Quote from: arnoldemu on 17:07, 22 July 10
I agree here it isn't always important of the extact format of the storage system.
For me, I want to use these storage systems like amsdos. And in my programs I want to use firmware functions to open and read files.
Then my programs will work if I copy them to mass storage with no changes, and also I don't need to detect hardware and make special code.
I want to use the storage system so it is transparent. Use the functions I know to do the tasks I want.
Yeah, this would be the ideal situation. You have it both. In this case you can use a device like usually and you can easily fill this device with data. So, we miss a DOS replacement that uses FAT hard-discs.