Hello great community, I just want to know, simple and specificly if posible, what is needed to do to finally support Gabriel Knight: Sins Of The Fathers. It's really a pity that is almost complete but relegated.
I hope someone had the time and knowdledge to finish it.
Well anyway, this is a good project and here are many good people who have done enormous work, I thank you all for your great contribution to the world
Gabriel Knight: what is needed to be supported
Moderator: ScummVM Team
- Strangerke
- ScummVM Developer
- Posts: 335
- Joined: Wed Sep 06, 2006 8:39 am
- Location: Belgium
Sadly, we never announce support date for the simple reason we ignore them: when it's ready and everybody agrees, we announce support.
Currently, the engine needs some more work in order to fully support GK. It may come fast or not, I can tell. But we just released v1.6.0, so most likely you'll have to wait 6-9 months in order to see if it's available in the next stable release...
Currently, the engine needs some more work in order to fully support GK. It may come fast or not, I can tell. But we just released v1.6.0, so most likely you'll have to wait 6-9 months in order to see if it's available in the next stable release...
Thank you very much for your kind response but I did not mean when... but WHAT work
Hope I'm not bothering much, and thank you again for your patience and work
Example: the scaling bug, general work on SCI engine, etc.?Strangerke wrote: Currently, the engine needs some more work in order to fully support GK.
Hope I'm not bothering much, and thank you again for your patience and work
Loads of work, really
We need to rewrite parts the SCI32 graphics code to be closer to the original. Right now, large parts of it are based on guesswork, which causes some of the graphical glitches you're experiencing.
This includes the following kernel functions (at least for GK1, PQ4 and QFG4):
- kFrameOut, as well as the rest of the Plane and ScreenItem manipulation kernel functions in frameout.cpp
- the scaling code
- kCantBeHere (for pathfinding)
- kSetShowStyle (for scene transitions)
- kEditText (for the original save/load dialogs)
- kRemapColors subops 3, 4 and 5 (used mainly in PQ4 and QFG4)
- kPalCycle (used rarely, e.g. for the asynchronous palette animations, e.g. in the Bayou in GK1)
- kPalVary, subops 7 and 8 (used rarely, e.g. when showing the exterior of Schloss Ritter in GK1)
These are the main ones I can think of. There might be others, too
We need to rewrite parts the SCI32 graphics code to be closer to the original. Right now, large parts of it are based on guesswork, which causes some of the graphical glitches you're experiencing.
This includes the following kernel functions (at least for GK1, PQ4 and QFG4):
- kFrameOut, as well as the rest of the Plane and ScreenItem manipulation kernel functions in frameout.cpp
- the scaling code
- kCantBeHere (for pathfinding)
- kSetShowStyle (for scene transitions)
- kEditText (for the original save/load dialogs)
- kRemapColors subops 3, 4 and 5 (used mainly in PQ4 and QFG4)
- kPalCycle (used rarely, e.g. for the asynchronous palette animations, e.g. in the Bayou in GK1)
- kPalVary, subops 7 and 8 (used rarely, e.g. when showing the exterior of Schloss Ritter in GK1)
These are the main ones I can think of. There might be others, too
- CaptainJei
- Posts: 200
- Joined: Wed Jun 15, 2011 3:57 am