Lasse : I've got some c64 bitmaps from MI, that look way better than the stuff JohnGreen posted.. It will only be better, not worse than this!
_________________

I don't think a C64 version of MI would use bitmaps. Scrolling bitmaps is quite hard + you need lotsa memory only for those bitmaps.

Yeah, if one wants to rebuild the graphics in completely different style (can't see char-mode displaying "curved" graphics like that very well, you run out of chars fast) + remove bigger moving+animating objects

This time it uses SEUCK character set mode. Its still not realistic, because I've used more than 256 characters - but if you redesigned the scene to be a little more c64 friendly, and by swapping characters in and out on the horizontal scrolling, you could easily recreate the scene.

The image should look a lot better, but at one stage I (accidentally) found myself using four primary colors LBLUE, DBLUE, YELLOW and CYAN - so I converted all the cyan to LBLUE. But I could go back and restore the CYAN in several places using the block color (eg the clockface, the path to the right of guybrush, and at the centre of stars that look like crosses.)

Other things I'm noticing as I look at it.
* the purple shadowed house to the left of the clock looks dodgey
* the scene could do with more purple framed windows - they look pretty!
* the small red and yellow windows to the left of the big red and yellow windows need not contain red, and would look alot better if i had black as the block color in that location.
* I was rushed for time - several places are very messy.
* the aspect ratio needs adjusting, since these pixels are square but c64 multicolor pixels are elongated sideways.

Was gonna go into how easy it was to do this in photoshop, but I'm already ranting. Maybe another day - time for bed!

spaceship788: what graphics mode would you use to get a multicolor resolution at 320x200, as your image effectively is in that link?

What I was posting was an approximation of how the screens could look at just the plain mulitcolor mode, 160x200 pixels. Still, in comparison to the original EGA PC version, I think they'd hold up with some touchups. Certianly not so bad to justify LucasArts not making a C=64 version in the first place.
_________________

C=64 pixels have a ratio of .82 instead of 1, so a multicolor pixel is 1.64 wide. In Photoshop you can almost see what this looks like by selecting under mode a pixel aspect ratio of PAL Widescreen, which is 1.42. On a C=64 it will be slightly wider than that.

In the images I'd posted, the ratio is 2:1, but viewing them in Photoshop with the pixel aspect ratio set to .9 makes them 1.8. Still slightly wider than on a C=64, but between looking at them at 1.42 and 1.8 you can get the idea.
_________________

Breaking up your sample image to 160x200 thirds, I see what you're doing. In comparison to the PC version, on the C=64 less of the background would be visible on screen at once so as not to lose too much resolution horizontally. Means more scrolling, but not having to squeeze the art as much.

Would the interface at the bottom be bitmap or multicolor? I imagine it will be purely text like the original EGA MI, not a graphic interface like that added to the enhanced 256 color releases.
_________________

Please note that not all sixteen colours are available as character colours either, only the first eight; Spaceship's attributes are impossible not only because of resolution, but because pink, orange and dark grey aren't valid character colours.
_________________

TMR - I'm not sure what you mean. Do you mean you can't display the colors pink, orange and dark grey with a custom character set? I haven't made a game for C=64 in over 10 years so I'm a littly rusty, but I've used those colors in bitmap charsets. Are they not available to multicolor?
_________________

edit: TMR was faster than light

you are right

http://img.villagephotos.com/p...4_wide.gif

I have added a third pic with some quick and dirty changes:
* added cyan ( went a little overboard )
* changed dgrey to black
* changed orange to purple
* corrected aspect ratio corrected
* forget to remove the pink

From here I guess you would go through and find patterns. And find places where you can reuse blocks to an get average block reuse to about 3. I imagine that would require some serious redesign of the scene!

I would even widen the side of the house in the middle, so there is amore downtime to swap character sets.

But the colors are nice, and you could probably create a similar scene which looked just as nice. Perhaps more places where the color combinations of (lblue+yellow+cyan) and (purple + yellow) and (red + yellow). Those colors work well together.

Same for the rest of screens involving that quaint little village...

Only a few issues now; the sprite objects are using too many colours (and it's possibly better off to map anything that doesn't move into the picture), the change in pixel widths shouldn't stretch the image like that (it needs to be redrawn so that the image ratio remains the same) and getting it to crunch down... umm, good luck. =-)

You'd be better off trying to crunch it into "zones" and the font gets split a couple of times down the screen.
_________________

That screen is 56 long blocks wide. So I could afford myself the free chars from the first sixteen cols, to construct the frames of the red windows. You could probably get a recognisable reproduction with a full char set ( the text down the bottom would have to use bank switch on raster interrupt or something).

Apologies to the people who liked the stars

( I did this using photoshop and an awesome program called tilestudio. Tile studio is great for c64 stuff - its available at sourceforge )

this topic is nice, but its nothing but just playing with the ideas. From the coders side of view the problem with creating this game is absolutely not how the graphics should be handled, or done technically, nor spritezooming.

Horizontal Hardware scroll is invented since ages, so it would be no problem to use multicolor bitmap mode as a char screen for the problem you're actually discussing.

(altho I'd prefer char screen for the sake of less memory usage)

The biggest problem of this game is the SCUMM scripting. If scumm would be reverse engineered, and the data extracted, the game could be done by any experienced c64 coder without serious problems.

oswald: playing with ideas is good I think.

Don't know about scumm scripting (or any scripting at all), but don't think it's of the most advanced code,
to make it work (leaving out the scroller and gfx issues).

A "mouse/pointer" routine that's gets xy, on button use checks "action" paramas and if they are right something will happend/ gamekey will be unlocked.
A bunch of gamevars and states is stored and if they are true or right, other game elements will unlock....
However I've never done anything like this so there probably are bunch of problems to solve, but thinking of this type of games in general, they're not much more advanced than an avarage textadventure, or even less advanced as there probably are more syntax in writing than those to be used in MI.
(I'm thinking scene pr scene not the game in total)
I cant assembling (yet), "basic" is too large/slow and gkgm dosn't have multiloads
_________________

SCUMM has been reverse-engineered (ScummVM project) so the game logic could in theory be ported directly. Meanwhile, I think the greatest problem is the porting of graphics & animations with reasonable quality / compromises. That nighttime town scene seems to map nicely with a few C64 colors, but there are many that won't..

MOG, yeah in theory the scripting logic of an adventure is simple. But to recreate the whole adventure without using the internal script & text data would take a hell of a lot of time: play the game over and over to map out all the possible situations, see where the different texts appear, take notes of all that, and then recreate with your own system so that everything works ok.