ResidualVM Implementation Discussion (TwinEngine)

[xesf]

ResidualVM team as started a completely new implementation of both LBA1 and LBA2 engines. This thread has the propose of discuss that implementation.

Project goals resume for the new comers:
- Started from scratch using ResidualVM/ScummVM base;
- Support both LBA1 and LBA2 engines;
- Using TwinEngine source and LBA Tools source as documentation;
- OO programming using C++;
- OpenGL for 3D graphics;
- Implementation not tied to original code;
- Targeting for multi-platform;
- Large dev community base;
- Everyone can help;

Note: this thread isn't to discuss the reason why we are starting a new engine system. If the goals above aren't enough to understand it, please start a new thread.

[xesf]

I will start by asking if isn't it better to have separate workflow for LBA1 and LBA2? For example to avoid mixed intro sequences and main loop, instead of keep using the if game type.

[klusark]

For anyone interested, the development is currently at https://github.com/klusark/twin

I have not done enough looking into how the two engines differ from each other for that, but to me it seems like the main loops should be mostly kept the same, and any differing parts should be abstracted out. The main differences seem to be the menu system. All the rendering code should be applicable to both, as long as the formats are read separately for compatibility.

Speaking of formats, so far I've implemented Grid functionality, along with all the things needed to implement that. Some discussion that needs to happen is how to implement a proper resource manager for this engine. The thing that makes it the most complicated is the lack of file names, but I'm sure we will be able to come up with something.

For LBA2 the next format I need to load is the model format. I have not been able to find any tools which open the format, and have not been able to figure it out from reading the file either. Does anyone know the internals of the LBA2 model format?

For the Island format, I found and read the height maps, but I'm not sure which data I should be looking at in order to connect them together. There must also be some texture coordinate data and model data. Has this information been explored before? Or, should I work on understanding how the Island format work?

For scripting, I think Zink has been doing work on this. The part we need to go over first is how the scripting will be laid out. Does LBA2 use a lot of the same opcodes that LBA uses? If that is the case than it would make sense to subclass the LBA2 scripting engine from the LBA scripting engine. Overall, it seems that the scripting format is fairly simple, but the hard part will be making it all match how the original engine works. One goal I have with it is to provide some good scripting utility functions in order to reduce the amount of PC pointer modifications by the individual opcodes, and it it should be possible to read all the data in an endian safe way, just in case we ever want to port to a big endian platform.

[klusark]

Another small point.

It would be great to get any code contributions from anyone, but please try to follow these style guidelines http://wiki.scummvm.org/index.php/Co...ng_Conventions

[Zink]

As an introduction it should be said that we (Alexfont and I) have been planning writing a new engine for some time already, and we had some consents done, that need to be revised now.

The thing that I would like to do is one engine (not two for LBA1 and 2). The engine's main goal would be LBA2 with 'added' support for LBA1. I think that's reasonable, because most things in LBA1 are a subset of those in LBA2. For example, recently I was working on the script de/compiler, and it turned out that I don't have to write a separate compiler and decompiler for LBA2, because when I did that, I could delete the LBA1 version and use the new one to process both games! It only needed a small abstraction layer to handle differences in some command indexes. So my point is we should make it for LBA2 and LBA1 as a subclass (or maybe not subclass at all).

For the LBA2 height maps, I think Battler has got some knowledge about that. He might also be interested in joining us.

Also I think I should paste something here. It's the e-mail I have sent to Alex when we were starting talking about the new engine (it was targeted at LBA1 at the beginning, that's why some of the ideas are for the first game).

I'm thinking about this idea for some time now. I don't know if you have seen or played Descent-XL. If you did, you could have some idea of what I am talking about. I am thinking about extending the basic LBA engine with many useful features that will make the gaming experience far better. Here is a quick list of features that I am thinking of (of course not all of them at the same time):

(all of them switchable, when that makes sense)
- make the engine work in any screen resolution (that could require rewriting the grid drawing procedure),
- make the camera to follow Twinsen in real time,
- use better light and graphics effects for display (like semi-transparent disappearing fragments),
- ablity to display the full island at the same time (in LBA1) (not only single area), and walk between the areas without fading (scenes would work like in LBA 2, where the characters disappear when you leave an area),
- on-screen indicators of life, magic and most of the other things,
- better gameplay (like LBA2, where you can for example cancel an 'item found' indicator with escape key, and the controls behaviour seems more fluent),
- ability to use custom/better quality music and sounds (ability to replace midi and voc with mp3 or ogg),
- ability to use better quality character models (fan-made),

Better modification capabilities:
- modification helpers (create a way for modders to disable or change the built-in sequences, like the three intro images for a new game),
- script debugging features,
- new script comands that will allow more advanced scripts

The most important of it now is the LBA abstraction. My idea to handle the menu and other differences between LBA versions is to create one or more additional HQR files that will hold the data and will be modifiable by anyone. Perhaps two HQR files (one for each LBA) that the engine will select depending on the LBA version it is run for, and also additional HQR file(s) for LBA1 grid merging data, and other things that are hardcoded in the original engines, but should not.

[xesf]

I will quick answer about some questions only. Will get back later.

Some useful links:

LBA2 islands code from Lupin: http://trac.assembla.com/live_on_twi...andLoaderDraft
You can see the output here: http://forum.magicball.net/showthread.php?t=13485

Also good resource for both games: Project LbaNet with online LBA world.
https://code.google.com/p/lbanet/sou...trunk%2Fcommon
The download section also has some tools that may help.

Link for My LBA1 Animation Studio source code based on yaz0rs code
http://xesf.net/mbn/LBAnimatorStudio_Src.rar

LBA file formats should be updated in this wiki website: http://lbafileinfo.kazekr.net

[xesf]

LBAnet link is outdated. Here's the correct one: https://code.google.com/p/neolbanet

[Battler]

While I like what this project is striving for, I would like to suggest an alternative proposal: why not finish implementing the LBA 2 engine as it originally was, in Watcom C/C++, and then add a simple parameter in LBA2.CFG that if set, makes the engine work in LBA 1 mode, or something like that. Of course also add improvements, such as eg. .MP3/.OGG support, possibly even .FLAC and .MPC, and implement the FunnyFrog patch, but in the end the main engine is still the same.
That way you can fix compatibility with new hardware (eg. a switch that puts it into modern DirectX mode as opposed to the legacy DirectX 3 mode which would be default, FunnyFrog's patch which should again be switchable) while at the same time still maintaining compatibility with legacy hardware and operating system, which is especially important if we want an audience in markets such as Japan where most of the gaming is done on consoles and thus most people have much older hardware than is common here in the EU or in the US.

BTW, if anyone needs it, I can contribute some compression code to this project. Either the original Adeline algorithms, which I can only provide as a compiled .DLL (since I am not allowed to distribute the source for obvious reasons), or Haruhiko Okumura's implementation modified by me for LBA purposes which I can distribute in the full source form (but produces slightly bigger files for compression type 2 than the original algorithm because it ignores matches on the edge of the 4096-byte buffer).

[klusark]

Originally Posted by Battler

While I like what this project is striving for, I would like to suggest an alternative proposal: why not finish implementing the LBA 2 engine as it originally was, in Watcom C/C++, and then add a simple parameter in LBA2.CFG that if set, makes the engine work in LBA 1 mode, or something like that. Of course also add improvements, such as eg. .MP3/.OGG support, possibly even .FLAC and .MPC, and implement the FunnyFrog patch, but in the end the main engine is still the same.
That way you can fix compatibility with new hardware (eg. a switch that puts it into modern DirectX mode as opposed to the legacy DirectX 3 mode which would be default, FunnyFrog's patch which should again be switchable) while at the same time still maintaining compatibility with legacy hardware and operating system, which is especially important if we want an audience in markets such as Japan where most of the gaming is done on consoles and thus most people have much older hardware than is common here in the EU or in the US.

BTW, if anyone needs it, I can contribute some compression code to this project. Either the original Adeline algorithms, which I can only provide as a compiled .DLL (since I am not allowed to distribute the source for obvious reasons), or Haruhiko Okumura's implementation modified by me for LBA purposes which I can distribute in the full source form (but produces slightly bigger files for compression type 2 than the original algorithm because it ignores matches on the edge of the 4096-byte buffer).

Personally, that just does not seem like good progress to me, but to me the purity of the engine doesn't really matter so much. All I want is to be able to play it on modern hardware with various improvements and an overall well written engine that's not tied at all to the original implementation of the engine.

I don't want it to just be tied to Windows or tied to the desktop, and just writing a new engine using modern methods will allow us to easily port to other platforms with ease.

In regards to the compression code. The algorithm is old enough now that it is not encumbered in anyway and there are enough versions under the GPL. This is the code I'm using right now. The problem with a DLL is it would only be for Windows, which would not work at all for me.

[Battler]

- klusark: The algorithm you're using is for decompression, while I'm talking about the compression, which is especially needed for LBA 2 saved game support.

Also again, while I can understand your desire to play the game on modern hardware, being compatible with modern hardware ONLY, would alienate first of all developing countries where 10-year-old machines with Windows XP or even older are still the norm, and it would also alienate markets like Japan where gaming is predominantly on console and as such people do not have a tendency to upgrade PC's often.

So while I agree with compatibility with modern hardware, it shouldn't be an exclusive. And you certainly need graphically intensive stuff like OpenGL to have compatibility with modern hardware. I've seen Japanese PC games made in like, 2011, with graphics better than LBA 2, that worked fine on an old Intel Celeron 2400 MHz with Windows 2000 and a SiS 651 Real256 integrated graphics card, so I know it can be done.

As for it being tied to Windows or to the desktop, again, by using a purely software renderer (which is more than enough for LBA 2), it's actually easier to port as you're only dealing with your own code as opposed to having to deal with all the various variants of OpenGL, etc. - not to mention, is OpenGL even supported on eg. ARM? Remember, ARM is not a platform designed for graphically intensive stuff, which is another reason why hardware-accelerated OpenGL rendering is not a good idea.

[klusark]

Battler: Nothing we are planning to do will make it not work on a ten year old xp machine. OpenGL has been around since the early 90s and it's very hard to find a machine that OpenGL 1.1 (which we are probably going to target) will not work on. Additionally, it won't be hard to add a software renderer like we already have for the Grim Fandango engine.

Your point about ARM makes no sense at all. You are saying that we shouldn't use OpenGL and instead just use the slow ARM processor? OpenGL ES was created just for this as you can then take the rendering off the processor. Again, for Grim Fandango we have a OpenGL ES backend that one developer has created which greatly sped up rendering on Android vs. the software renderer.

Also, I know OpenGL a lot better than I know how to create my own software, and I don't know OpenGL very well at all.

For compression. I didn't realize that it was needed for save games. We are still very far away from implementing those so I think we can decide on that when we are closer.

[klusark]

Quick Status update:

I've got models rendering mostly correct, but not textured yet. As you can see there are still some problems, but it's getting there. Code in this commit
https://github.com/klusark/twin/comm...7afccb7d1ed85f

[Battler]

- klusark: Let me explain what kind of machines I'm talking about. In Japan it's common to find PC's which are for example a NEC PC-9801 (but also regular PC's of the same era up to ~ 3 years later) with a Celeron 433 MHz and 64 MB RAM, running Windows 2000 Professional, with a late 1990's graphics card, simply because they have zero reason to upgrade their PC, as a high-end gaming is done on consoles there and PC games produced today in jpana still work on those old machines. And this is Japan.
In South America, for example, there are old Pentiums or Celerons with Windows XP, 2000 or even 98 SE on them, with old entry-level GPU's at best.
In both cases, I doubt hardware OpenGL is available.

Now, I'm not saying drop OpenGL completely, mind you, instead, please do give the option to use OpenGL when someone plays the game on hardware up to ~9 years old, especially if it's eg. OpenGL 1.1 which doesn't require a high-end GPU and if OpenGL ES exists for ARM. I'm just saying add a "legacy mode" for those with older machines (older PC's, NEC PC-9801 series, Fujitsu FM-Towns series, etc.) so that they can still use this engine.

As regards ARM, you misunderstood me. Since I quite honestly know nothing about ARM, I just assumed hardware-accelerated graphics rendering didn't exist on that architecture. Seems I was wrong though, actually, I'm glad I was wrong in that regard.

Also, a software renderer also makes more sense for the background, such as for the isometric scenes present in both games, as well as the LBA 2 3D exteriors, which are height map-based, and thus not particularly adapt to a hardware-accelerated vortex format.

BTW, as for the models - the models of LBA 1 don't use textures, but just a single color per polygon. Most of the LBA 2 models are like that too, though some LBA 2 models however do use textures.

Also, if you need help regarding text - I know you guys know everything about the standard LBA character set and font formats, but I can help you with Japanese support, since I know the Shift-JIS format used by Japanese LBA 1 for PC (of which I have a copy) and I also know how its font system works.

[klusark]

Another quick post. I have a Grid renderer that can do around 100fps on my computer and render at and resolution you want.

[Zink]

Originally Posted by klusark

For compression. I didn't realize that it was needed for save games. We are still very far away from implementing those so I think we can decide on that when we are closer.

We don't have to worry about compression. There are some open algorithms (including my own) that we can use, even if they are not super-fast or most effective.

I am working on the LBA2 script compilation. First 30 scenes now compile identically to the originals, but then I stumbled upon another script quirk that I will have to handle by making the code more complicated. Hmpf.

[xesf]

There is not point about doing software rendering and we should stick with OpenGL for portability.
Soft rendering never helps the twin-e project and it has a lot of bugs difficult to solve.

As for the old machines, if they want to stick with old PC than, just play the original LBA version. Period!!
ScummVM are successfully in those questions and we should stick with that. It worked in the past so it will work right now.

LBA2 saves have small size, so we don't have to implement the compression side. We can read compression and save uncompressed. I don't see any problem on that.

[somaen]

Originally Posted by alexfont

There is not point about doing software rendering and we should stick with OpenGL for portability.
Soft rendering never helps the twin-e project and it has a lot of bugs difficult to solve.

As for the old machines, if they want to stick with old PC than, just play the original LBA version. Period!!
ScummVM are successfully in those questions and we should stick with that. It worked in the past so it will work right now.

WELL, OpenGL isn't really a portability "end-all-be-all"-solution, as the bug tracker for the Grim-engine in ResidualVM shows at times, some drivers implement things differently, some flat out lie about what they can do, the list goes on... Then there's mobile-devices where you need GLES (Which would be nice, if it wasn't for the fact that you then have to choose between semi-cross-portable 1.1 (with no shaders, and thus no flexibility for stuff like depth), or ES2, which then is only truly compatible with version 3, which not everyone has at all). This all boils down to the reason why we have done what we did with the Grim-engine, and probably should do the same for LBA:

Avoid, at all costs any direct usage of OpenGL directly in code, use it ONLY via a wrapped interface that allows for implementing various graphics backends behind it.

This means, that from the get go you implement using OpenGL, fair and square, but you isolate the actual OpenGL-code behind the renderer-interface (see the grim-engine for a bigger example), then you implement soft-rendering or GLES-implementations behind that, without having to touch any of the game-logic. This gives you the best of both worlds, with the added benefit that we already have TinyGL in ResidualVM, which is a software implementation of most of GL 1.4 (with some limitations, such as lighting and VAOs), thus making it possible to render 3D-objects without GL (separate approaches are done for 2D-components to avoid the costly 3D-computations.)

Now, TinyGL isn't FAST, but it works on most platforms, the AmigaOS 4-port of ResidualVM doesn't have OpenGL enabled (the platform lacks 3D-support in it's graphics-drivers), and thus relies on this solution alone, letting us build for platforms where no hardware-accelerated 3D is available. It doesn't however scale that well down in CPU-speed, but with the 2D-components offloaded it can get appreciably fast.

As for the reference to ScummVM, ResidualVM and ScummVM are different in one major component, namely that we don't use the same graphics-system. Where ScummVM has a system aimed at purely 2D-solutions, without any hardware-acceleration involved at all (an OpenGL-backend is available in their dailies, but it does not do much in the way of hardware accelerated surface operations), while ResidualVM currently exposes the OpenGL-API completely (and is thus quite a bit less portable when not using TinyGL).

TLDR; There is software-rendering GL available in ResidualVM, which you can implement when stuff works, for now it's a better idea to "get stuff to work first, and make it fast later". Also, remember to keep all GL-stuff contained in the renderer-class to make life easier if/when software-rendering is approached.

[Battler]

Originally Posted by Zink

We don't have to worry about compression. There are some open algorithms (including my own) that we can use, even if they are not super-fast or most effective.

Haruhiko Okumura's algorithm is faster than yours and open... he clearly states in the header that you can do whatever you want with it. And it's in C, so it's very portable.
Edit: I have nothing against your algorithm, I'm simply stating we have an alternative which is just as open, but faster.

Originally Posted by alexfont

There is not point about doing software rendering and we should stick with OpenGL for portability.
Soft rendering never helps the twin-e project and it has a lot of bugs difficult to solve.

As for the old machines, if they want to stick with old PC than, just play the original LBA version. Period!!
ScummVM are successfully in those questions and we should stick with that. It worked in the past so it will work right now.

Please read my posts again. I never said OpenGL shouldn't be used, in fact, you'll notice I openly welcomed that. I just proposed to add an alternative legacy software renderer so those with machines that don't support OpenGL. If needed, I can work on the alternative legacy renderer myself even, so I don't see what's the big problem.

As for your remark that those with older machines can just play the original LBA version - that doesn't quite work when you're talking about implementing changes for modding purposes. Which means any mod that relies on those changes, will be effectively unplayable for those people.
This means you're alienating an entire base of not only players, but even possible modders, from quite a lot of markets. Do you really want to restrict the final audience and modder base to Western Europe, North America, and Australia/Oceania? Remember, we have a considerable number of South Americans even on this very forum.

LBA2 saves have small size, so we don't have to implement the compression side. We can read compression and save uncompressed. I don't see any problem on that.

The problem is, we end up with saved games twice the size. About 64 kB or more per saved game, instead of 32 kB at most.

[Battler]

Originally Posted by somaen

TLDR; There is software-rendering GL available in ResidualVM, which you can implement when stuff works, for now it's a better idea to "get stuff to work first, and make it fast later". Also, remember to keep all GL-stuff contained in the renderer-class to make life easier if/when software-rendering is approached.

Is there any place where I can get some test thing implemented on the ResidualVM software renderer so I can test it in some old machine emulators (talking ~ 1999-2003 here) and see how well it works there.

[xesf]

Thanks somaen for your clarification.

As for software rendering I thought the talk was about the original soft rendering LBA2 use. Using TinyGL as the rendering system should make things a bit easier than coding the entire soft rendering from LBA2.

[Battler]

- alexfont: The original software rendering engine from LBA 1 and LBA 2 would be completely useless for this project as it's based on ages old code and it has bad compatibility problems.

So far it seems TinyGL is the best way to go for software rendering, in addition of course to standard OpenGL for hardware rendering. I will proceed to test TinyGL in some emulators as soon as I find a link to something made with it that I can use as a test.

[somaen]

You can grab the Grim Fandango demo from the downloads-page of ResidualVM, and enable software-rendering in options prior to launch. (Don't attempt the Escape from Monkey Island-demo, it is a more modern game with quite large amounts of vertices, and is more or less guaranteed to be slow in software on older CPUs)

It will probably be rather slow on that old a computer, there is room for more optimization (dirty rects for one), and if push comes to shove, if the renderer-interface is kept strict as I stated in my previous post (i.e. isolating the GL-code), then simpler special-cased code could be put in place for the LBA-engine if someone wants.

The point is, that there isn't any need to worry too much about it at this point, a fast enough software-rendering solution can be put in place when everything else works, as long as the code isn't hard-wired towards GL (thus the renderer-interface).

[Streg]

I've been waiting for ResidualVM for years. It's great to see some progress being discussed by developers here on the mbn. Keep up the good work guys.

[xesf]

Thanks for there initiative, otherwise we would have waited more

[Lupin]

This is great news! Is there anything we can contribute?
Any help needed deciphering what remains unknown of the LBA2 island format?