Community
SCI Programming => Mega Tokyo SCI Archive => Topic started by: Pikachu14 on September 20, 2002, 01:30:29 PM
-
This is cool... I played the Quest for Glory VGA remake, thought it was pretty cool, by the way, and noticed a gfx driver named "EGA640.DRV". So, naturally I tried it out.
Sweet furry funk biscuits! Never thought they'd try that! With a doubled resolution to allow dithering, they actually made one the coolest (IMNSHO) graphic drivers ever!
Then I tried it on Brian's VGA Slideshow Demo thingy, worked fine until the palette changed. And Larry 1 worked fine like that too (except the title screen wouldn't scroll! :D) But when it asked my age, it crashed...
Any other strange graphics drivers out there?
On a side note, can one make one's own graphics driver? The name "Ravi" is suddenly burned onto my eyes...
-
Every SCI11 game got shipped with that driver... Instead of SCI1, where games got shipped in two different versions (and their 16 color versions looked a lot worse)... It's interesting though, that the technique this driver uses, was used with games way before SCI1, like the GameArts games Sierra licensed... So the question is: why didn't they use it in SCI1?
-
Actually there is another pretty cool one, I have a black and white driver. ;D
-
Chris - Where did you get the black and white driver? Sounds cool :P
/me also makes a mental note to grab this EGA640 driver from his copy of QFG1...
-
You mean VGA320BW.DRV?
-
There were old CGA mono (2 colour) drivers released with early games like SCI0. There's also a hercules (2 colour) driver too that works on my XT. However, new computers don't emulate herc, only CGA.
The reason Sierra wouldn't have done the dither drivers in SCI1 was because they use a 640 EGA resolution while the EGA SCI1 games used 320. Most people who had EGA only wouldn't have had enough video memory for it.
For example, 320 VGA requires 64K, while 320 EGA only needs 32K. However, 640 EGA would require 64K too.
-
For example, 320 VGA requires 64K, while 320 EGA only needs 32K. However, 640 EGA would require 64K too.
Well thank you so much for telling me that! It all makes sense! :D
-
VGA320BW.DRV
Yes that is the one.
Where did you get the black and white driver?
Well mine came from "The Castle of Doctor Brain". But it is probably included in other games as well.
-
Well mine came from "The Castle of Doctor Brain". But it is probably included in other games as well.
You kiddin'? Nearly every single SCI game I have has that driver! :D
-
Well I havn't actually checked the other SCI1 games to see which do and don't... all I know is that mine came from The Castle of Doctor Brain. ::)
-
Would it be possible for someone to make a new interpreter that supports hi-res (1024x768)? I would, but I don't know any high level programming languages. (Maybe time to read 'Learn C++ in 21 days'?)
-
You mean "driver", right?
-
Why would a resolution of that be needed? If you want something that fancy use AGS or something... besides if someone where to write and interpreter with that res it wouldn't be "real" SCI would it? ::)
As for a driver... nope that wouldn't really work because the graphics where designed for a lower resolution so all the driver would be capable of doing is stretching the images/animations to fit that res... ultimately making it look like crap in my opinion.
I say leave SCI as is, no modifications... because then it is not really SCI as we remember it from the good old days.
-
Which brings us back to the question "is it possible at all?".
Ravi made a sound driver, so I guess yes.
Let's just keep it simple. Let's just think of a driver that does a 320-to-640 with a scanline effect, okay?
-
Is it possible?
ANYTHING is possible, but you have to make it. ;)
You can do just about anything if you put your mind to it and know what your doing. I am of course against making a higher res graphics driver... the sound drivers are fine since people have different speakers/audio drivers... and graphic drivers for other machines(mac, linux, etc) are ok in my opinion.
-
Maybe an SCI launcher? (list of games, options etc.) It would work for me, because my partition on the harddrive is like a big maze that confuses everyone.
-
But how?
Ravi, how did you make that driver?
-
He made it in a programming language. ::)
He disasembled the original drivers most likely then used what he learned from it to make his own driver. It only takes a basic knowledge or programming.
-
I knew that, but how do the drivers work?
-
I knew that, but how do the drivers work?
Well you have 2 choices, either disasemble a driver and see what it does, or read some docs on ravi's site about the structure of it.
Maybe an SCI launcher? (list of games, options etc.) It would work for me, because my partition on the harddrive is like a big maze that confuses everyone.
::) You could make something like that using a batch file for christs sake, it isn't that hard. ::)
-
Well you have 2 choices, either disasemble a driver and see what it does, or read some docs on ravi's site about the structure of it.
Going, going, gone...
-
The only possible option I see, is that the FreeSCI team adds new graphic modes in their interpreter... Like ScummVM, that interpreter uses all kinds of graphic modes to (somewhat) boost the quality (in a higher resolution)... This technique is also used in par example ZSNES...
-
Hmm...I can't find any info on Ravi's site, let alone FreeSCI's...
Edit: Nah, just looking in the wrong places. Ravi's NoSound Framework might work...if I can get a disassembled graphics driver to go with it...
-
Sorry for jumping into this thread so late. I haven't been ignoring you folks, I just tend to read sound stuff more often since that's my particular area of expertise with SCI.
Creating a new graphics driver is certainly possible, and as people pointed out, I did it by disassembling Sierra's sound drivers and creating a new one in assembly.
I haven't looked too closely at graphics drivers, but the general scheme for all of Sierra's drivers is a little something like this:
; The driver is in some file on disk. The interpreter
; loads it into memory at the start of a segment.
; Whenever it needs to use the driver, it does a far
; call to the start of that segment. The first instruction
; in the driver, at the start of a segment, is a jmp to a
; driver interface function.
jmp DriverInterface
; Next, some identifying information
db 0 ; unknown purpose, possibly here for alignment
dd 0x876543210 ; identifies this file as a Sierra driver
db 0 ; identifies this as a display driver
db 7, 'namedrv' ; pascal style string with the driver name
db 11, 'description' ; pascal style string with driver description
; This is traditionally the driver data space.
; Remember that driver data lives in the code segment,
; so if you have a variable foo, reference it with cs:foo
; and not ds:foo.
; Next, a jump table to driver subfunctions. You'll have to
; figure out what each subfunction does by disassembling
; a Sierra driver.
dw Func0
dw Func2
dw Func4
; etc
; The DriverInterface function saves registers and uses
; the jump table to call the correct function. Register bp
; contains the subfunction number.
DriverInterface:
pushf
; save registers except ax and cx, which return values
call near word [cs:ExportTable+bp]
; restore saved registers (don't touch ax and cx)
popf
retf
; Implementation comes down here.
Func0:
; implement Func0
retf
Func2:
; implement Func2
retf
Func4:
; implement Func4
retf
-
Wow, thanks! Too bad that code doesn't cover graphics. It'd be much more helpful if it were truely a graphics driver...
-
O...K...