Does the Residualvm core support fixed-camera games only?
Will it ever support games with floating camera (such as the "Silent Hill" series or the ancient "Fade To Black")?
The Junkyard (or: what might Residual someday support?)
Moderator: ScummVM Team
Well, technically, we could fit both Doom and Quake 3 into ResidualVM, as there are no real limitations (the engines have full access to OpenGL/TinyGL, no wrapper is used to hide any functionality).
But, then again as Longcat says, Doom isn't really inside our scope. (And, since it's open-source, there are already quite a few implementations).
Still, as an example of what can be done with the backend... sure.
But, then again as Longcat says, Doom isn't really inside our scope. (And, since it's open-source, there are already quite a few implementations).
Still, as an example of what can be done with the backend... sure.
I used to think residualvm was some kind of a layer between the OS and the game engine, which provides services in a portable way (you know, you write an engine, you call residualvm methods when you want do to things like reading a file or playing a sound or moving an object on the screen).somaen wrote:...(the engines have full access to OpenGL/TinyGL, no wrapper is used to hide any functionality).
So, is this idea far from reality? Is this partially true? Am I thinking totally wrong?
-
Raziel
- ScummVM Porter
- Posts: 1541
- Joined: Tue Oct 25, 2005 8:27 am
- Location: a dying planet
- Contact:
I'm thinking more of it as a software cartridge reader.
You plug in a cartridge (data of a game) and, if supported, residualvm will run it 100%.
Infact ScummVM and ResidualVM would have made a killer product back in the eighties as hardware
(Anonyone remeber the movie "Big" with Tom Hanks and his idea of a switchable cartridge reader? -> There you go) 
You plug in a cartridge (data of a game) and, if supported, residualvm will run it 100%.
Infact ScummVM and ResidualVM would have made a killer product back in the eighties as hardware
(Anonyone remeber the movie "Big" with Tom Hanks and his idea of a switchable cartridge reader? -> There you go) File-accesses, and 2D-drawing is done in a portable way yes, the specifics of the platforms are handled by the backends (In our case that basically means SDL with some variation for Amiga/Mac/Linux/Windows, in ScummVM's case there's a bunch more, for stuff like iPhone/Android/Samsung TV etc).
The backends also handle the specifics of controls (which you can imagine varies a bit between a Nintendo 64, an iPhone and a PC), movie-playback (a lot of codecs are implemented in ScummVM, we have Bink (EMI/Myst3) and SMUSH (Grim Fandango)-support).
The engines are then written so that they don't access the normal APIs of the operating system, but instead access the APIs provided by ResidualVM/ScummVM, which in turn access the backends for their needs.
In theory you could write any 2D game to run in ScummVM (To pick one at random, I guess Master of Orion 2 or Command & Conquer would be doable, but far outside the scope of the project of course), in the same manner, you could write a game like Skyrim to work inside ResidualVM (although that is also WAY outside our scope).
That being said, there are a few limitations for us, that ScummVM doesn't have, we need our backend platforms to either have 3D Acceleration available, or enough CPU power to do the same with TinyGL in software. TinyGL itself puts additional limitations on things though, as it doesn't give access to new and fancy stuff like shaders (or anything above OpenGL 1.3 IIRC).
BUT, ResidualVM itself doesn't put any limitations on what parts of the OpenGL that is available to the engines, which means that you CAN write against OpenGL 4.0 in it, but that would ONLY work on platforms that support OpenGL 4.0. (Which is why we don't do that, currently we aim somewhere around 1.5 with our code IIRC).
Now some devices don't have OpenGL available, and might have slow CPUs, for those we'll need OpenGL ES, in that matter, any engine that wants to work on those will have to do a third rendering engine (in addition to TinyGL and OpenGL), for GLES.
In summary; Yes, they are a layer for engines, but OpenGL is accessed directly in ResidualVM, which makes anything possible (but limits the direct portability a bit, as the engines will have to do some extra legwork for GL/GLES/TinyGL, that wouldn't be necessary for 2D-stuff).
The backends also handle the specifics of controls (which you can imagine varies a bit between a Nintendo 64, an iPhone and a PC), movie-playback (a lot of codecs are implemented in ScummVM, we have Bink (EMI/Myst3) and SMUSH (Grim Fandango)-support).
The engines are then written so that they don't access the normal APIs of the operating system, but instead access the APIs provided by ResidualVM/ScummVM, which in turn access the backends for their needs.
In theory you could write any 2D game to run in ScummVM (To pick one at random, I guess Master of Orion 2 or Command & Conquer would be doable, but far outside the scope of the project of course), in the same manner, you could write a game like Skyrim to work inside ResidualVM (although that is also WAY outside our scope).
That being said, there are a few limitations for us, that ScummVM doesn't have, we need our backend platforms to either have 3D Acceleration available, or enough CPU power to do the same with TinyGL in software. TinyGL itself puts additional limitations on things though, as it doesn't give access to new and fancy stuff like shaders (or anything above OpenGL 1.3 IIRC).
BUT, ResidualVM itself doesn't put any limitations on what parts of the OpenGL that is available to the engines, which means that you CAN write against OpenGL 4.0 in it, but that would ONLY work on platforms that support OpenGL 4.0. (Which is why we don't do that, currently we aim somewhere around 1.5 with our code IIRC).
Now some devices don't have OpenGL available, and might have slow CPUs, for those we'll need OpenGL ES, in that matter, any engine that wants to work on those will have to do a third rendering engine (in addition to TinyGL and OpenGL), for GLES.
In summary; Yes, they are a layer for engines, but OpenGL is accessed directly in ResidualVM, which makes anything possible (but limits the direct portability a bit, as the engines will have to do some extra legwork for GL/GLES/TinyGL, that wouldn't be necessary for 2D-stuff).
Thank you, Somaen, for your technical answer, which is what I was after since I'm not that much into 3D programming and openGL stuff. Now I know when we talk about graphics in residualvm, the engines directly access the hardware, and this is the new part.
But another further question raises. You say residualvm itself doesn't put any limitations to opengl support but for compatibility reasons the engines have to take care in avoiding some extensions. Now, when building an engine which offers support for an ultimate high-end game (which probably requires the latest opengl instructions) is it possible to limit the instruction set to opengl 1.3 while still making it playable? I think this would assure for maximum portability while affecting image quality only, right? After all, a vertex is a vertex, a texture is a texture and motion is motion, and even older opengl versions had those. Perhaps some reflection or bump effect may be missing but... may the thing be working?
Sorry for my newbie questions.
But another further question raises. You say residualvm itself doesn't put any limitations to opengl support but for compatibility reasons the engines have to take care in avoiding some extensions. Now, when building an engine which offers support for an ultimate high-end game (which probably requires the latest opengl instructions) is it possible to limit the instruction set to opengl 1.3 while still making it playable? I think this would assure for maximum portability while affecting image quality only, right? After all, a vertex is a vertex, a texture is a texture and motion is motion, and even older opengl versions had those. Perhaps some reflection or bump effect may be missing but... may the thing be working?
Sorry for my newbie questions.
Fischkopf: Well, the PS2-version has the exact same 3D-models, and the differences in the backgrounds were negligible (possibly even worse, I don't remember right now, but I think that the PS2-version did 16-bit backgrounds, while the PC-versions did 24-bit.[/u]
Topolinik: Possible yes, but you would miss out from a lot of things, that might be done by shaders etc in higher GL-versions, so there would be visual differencies indeed, but you should atleast see something playable.
OpenGL does allow for querying the version available, and using extensions accordingly, which would allow for such version-scaling, as long as you have fallbacks for 1.3. Not that this is in any way applicable to the current ResidualVM development though.
Topolinik: Possible yes, but you would miss out from a lot of things, that might be done by shaders etc in higher GL-versions, so there would be visual differencies indeed, but you should atleast see something playable.
OpenGL does allow for querying the version available, and using extensions accordingly, which would allow for such version-scaling, as long as you have fallbacks for 1.3. Not that this is in any way applicable to the current ResidualVM development though.
No, that's not entirely true -- see "Television display accommodations" here.somaen wrote:Fischkopf: Well, the PS2-version has the exact same 3D-models, and the differences in the backgrounds were negligible (possibly even worse, I don't remember right now, but I think that the PS2-version did 16-bit backgrounds, while the PC-versions did 24-bit.
-
Harrypoppins
- Posts: 124
- Joined: Sat Apr 25, 2009 1:23 pm
