Sounds to me like you haven't got AHI setup properly on your Amiga, did you have a look at the readme?

You should enable the Audio Requestor as show in this video http://www.youtube.com/watch?v=D2IdDdDPcbU to ensure you're using the correct AHI device (basic stereo 8bit without any +).

You can also use a Video requestor and select NTSC if you like.

Peformance is always going to be an issue with the ECS version as this is obviously doing a lot of color conversion work in realtime and pushing the little 600 hard.

With v1.2.1.009 you should be seeing performance similar to what is shown in the video above when you have 'PALETTE_UPDATE_THRESHOLD' set to 256, if you reduce 'PALETTE_UPDATE_THRESHOLD' to 0 it will look exactly the same as the orginal VGA game (show all cut scenes etc) but it will be very very slow on a real machine.

My video Mellow Yellow was taken with 'PALETTE_UPDATE_THRESHOLD' set to 0 and you can see it works pefectly under WINUAE.

Looking good :D

This looks very cool NovaCoder. My hat is off to you for your superior skills. I have a weird question for you though. Are you planning on adding graffiti support if you can get the instructions on how to implement it? I know that it wouldn't be much faster, but it could run in 256 colors without having to downsample or what not (sorry I don't know the actual term used for scaling the colors from 256 to 64.) which might increase performance a little. What I'm curious about is why does it not run faster? I benched my old 486DX2-66 and it runs fine there reading from a 4x CD-ROM drive, that 600KB/s on transfer, and my hardrive is a whole whopping PIO Mode 2 which isn't very fast either. I don't want to sound like I'm griping, I'm just honestly curious as to what causes the overhead to require super fast hard drive access?

Hiya,

The main performance issue with the ECS version is the realtime color mapping from 8 bit to 6 bit, not the hard disk transfer rate.

Also consider that the 030's are pushing out less than 8 MIPS, apparently a 486DX2-66 did over 50 MIPS :spin

Yep I'll try and add graffiti support for the AGA version, no point with the ECS version though as graffiti is too slow with ECS. I can't add support for the new IndivisionECS chunky mode myself as I don't have the hardware to test it on but of course anyone else could do it if they wanted to.

@NovaCoder

I have no idea about how ScummVM works internally, but have you considered the possibility of caching some or all of the colour conversion results? It could be done either in RAM, so at least the same scene would load up quicker the second time, or even on disk, so the benefits would be there always after the first run. Again I have no idea if this is at all feasible to implement in the existing code, but it might make a big difference in performance if done well.

ScummVM ECS v1.2.1.010 in the Zone for testing.

Novacoder,
The games doesn't complain anymore about the resolution, but it crash before I can get any pics.

Does ScummECS use the Indivision ECS or not yet ?

Tested this version and the "flickering" issue is gone now :D. With disabled sound DOTT is now playable for me. With enabled sound the game is still dead slow and hangs somewhen.

What also seems to be fixed now is the "first start, second fail" issue and the workbench screen corruption after quitting. But found one new issue: It is not possible to enter capital letters when creating a savegame.

Regarding the sound settings I am testing exactly with the expected AHI settings from you.

Concerning Indivision ECS chunky pixel mode support you could contact Oliver Achten from Individual Computers. He implemented the ADoom version with IndyECS support and planned to do a ScummVM port as well AFAIK.

Ok, I'll PM you about getting LOOM VGA (ModeX) working.

Note, ScummVM ECS does not use the Indivision ECS, it uses the standard EHB ECS mode.

Yep I've spoken to Oliver before about adding ECS direct chunky support, I guess he'll get around to it when he has the time. I could do it myself but without hardware to develop on, it would take up too much of my time.

Hmm, i have now tested the new version.
Hardware A600/ACA630/25 2MB Chip/32MBFast

I have tested short MI1,MI2,IJ4,DOTT and S&M.
At first, all games worked like the should. Sometimes i have become a black screen and see nothing (especialy IJ4 when he starts in New York (thats reproduceable and S&M the Intro when the Dr. speaks to his victim)) This bug i can fix when i push the F5 button for the Menu and resume. After that i see everything.

The speed is in all games good. The older games are working better, but also the newer games like IJ4 are okay. DOTT is one of the fastest games. S&M is unfortunately the slowest and not really good playable i think.

The greatest problem,all games have is the scrolling. Everytime the screen scrolls, the frames brake down. The its really choopy/jerky. I think than are onl 0,5 frames per second or so. This is really a prpblem with all games.
I dont think thats a problem with the drive Speed, because the Problem is with my slow CD-Rom drive and also with the much faster CF drive.

One time i have the "first start, second fail" bug, but after restart this bug wasnt even there. A second try, quit and restart was without any problems.

An other little bug i had one time, when i would add an other game i scrolled down to my drawer, but when i tryed to click on this drawer, the selection jumps to an other drawer. After a few minutes (with return and new choose) this bug wasnt even there.

Fox

hiya
you need to look at the readme about the palette update threshold if you want to get rid of the black cut scenes, it's not a bug

thanks for testing this, at least most games are playable now

games that do lots of full screen scrolling will always be very slow i'm afraid

How sad. The Amiga chipsets (that had sufficient Chip RAM) could always do hardware scrolling instead of blitter scrolling when written in native code. I suppose the Chip RAM limitation is rearing its ugly head again. :(

Quote:

Originally Posted by Samurai_Crow (Post 754079) How sad. The Amiga chipsets (that had sufficient Chip RAM) could always do hardware scrolling instead of blitter scrolling when written in native code. I suppose the Chip RAM limitation is rearing its ugly head again.

Hiya,

I'm not really using the custom chipset, only the copper is being used to flip the screens, it basically does everything on the CPU side in fastram and then blits the result straight to the screen (which is the same as all recent demos). I did look at using the blitter but found it to be very slow.

If you really want to know why full screen updates (eg scrolling) is slow it because the code has to do the following each frame:

· Write 64,000 8 bit palette index values into a hidden back chunky buffer
· Convert 64,000 8 bit palette index values to their 6 bit equivalents
· Convert 64,000 chunky pixels to their planar equivalents
· Flip the screen to show what we have done.

If the palette has also been updated, it has to perform the additional step of generating a new optimized 64 color palette from the original palette in real-time!

Considering all the little 030 is doing, I think it's doing an amazing job :)

It might be possible to make it faster with a half blitter/half CPU C2P conversion but that might cause other issues (eg audio contention due to CHIPRAM bandwidth limitations) and in any case the main performance bottleneck is the 8 bit to 6 bit conversion (which is already using hand coded assembler BTW) and not the C2P conversion.

Another possibility is to create a C2P routine that does the palette index conversion and the planar conversion at the same time but this is apparently not very practical (the speed of the planar conversion would be severely compromised as it does 32 bit writes).

Of course if we used the Indivision ECS’s directly chunky mode we could skip both the palette conversion and the C2P conversion so that’s probably the way to go as I can’t really do anything else with it. :guru

How about the caching? Or would it need too much memory/hd access?

caching what?

It already caches as much as possible but some things (eg full screen scrolling, palette changes) will obviously be impossible to cache because they are dynamic (ie. they are user driven).

Hey Novacoder,

you are fast as the wind. :shocked
Yesterday i´ve tested the 1.2.1.010 with AGA and ECS and now, you have published the new version in a span of 3-4 days.

Finally i want to say, the AGA version i´ve tested yesterday (.010) was nearly bug free. All games running fine on my 1260 (also S&M). The only problem is IJ4, where i have no speech. But that may also a problem by myself :blased

The graphical different between ECS Amiga Adventures and ScummVM AGA is phenomenal, so i hope you keep the ball rolling :)


I look forward to the new version :great

@NovaCoder

What I asked about in post #44 - basically it could go all the way and cache 64 colour versions of all graphics to the hard drive as you go along, or if that is unfeasible, to RAM so that at least the recently visited scenes would be available without having to process the conversions again. But based on your answer I assume that you have already done so where possible. Large, scrollable backgrounds with a colour range are of course problematic, it would need to cache several bitmaps in small increments.

Novacoder, FOTAQ on A600

http://www.youtube.com/watch?v=5ItQSHGS6Sg

Hey looking good gibs, thanks for the video. Nice speed, better than I thought it would be on ECS and the GUI also looks pretty quick on your setup.

What's going on with the funny colors at the end of your video, does it always do that?

At the end the game has crashed. I'm going to try again because yesterday my A600 was unstable...

I have also tried "Secret of monkey island" which run pretty good, but with no music.

Some good news about that, just pausing and unpausing the game with the space bar produces the same result in a second!

Yes, I can confirm that, a quick battery of tests with FOTAQ in both ECS and AGA:

-ECS:

-Floppy version: Intro video speech works, there is no in-game speech (I mean, there wasn't in the original floppy version). Colours are a mess and performance is poor, probably due to palette conversion, which produces a result waaaay uglier than in Lucas Scummvm games. I guess it requires another approach.

-CD talkie version: Same about images, speech (which should be there in both intro and in-game scenes) doesn´t work at all and somehow screws subtitles, which dissapear way to fast to be read. Disabling speech in launcher options make them readable again.

-AGA

-Floppy version: images and colours are clean and crisp, performance is close to 100% optimal in both intro video and in-game scenes, probably due to not having a conversion process to be done. Intro speech works OK.

-CD talkie version: As before, no way to make speech work, but images and colours work as they should. Disabling speech make the game work like a charm!

(I forgot how damn fun FOTAQ was, I still have the CU Amiga demo disk with a demo that wasn´t actually a snippet of the game, but an interview with the characters in form of graphic adventure, I loved that! :laughing )

--