the Magicball Network Forums

the Magicball Network Forums (https://forum.magicball.net/index.php)
-   General (https://forum.magicball.net/forumdisplay.php?f=6)
-   -   LBA engine questions for programmers (https://forum.magicball.net/showthread.php?t=18313)

Renesans 2019-01-05 19:38

LBA engine questions for programmers
 
Over the recent years, many attempts were made to create an open-source reimplementation of the LBA engine, like TwinEngine, Prequengine (later merged with TwinEngine), and most recently, the JavaScript LBA2 engine.

As a programmer myself, recently I started taking interest in these projects. However, I do not necessarily have the required knowledge (yet) to contribute to them, but I have some questions/impressions:
  • If I’m correct, TwinEngine was started by yaz0r by reverse-engineering the binaries of LBA1. Which tools did he use? How could he make such advanced progress? I looked into to the binaries using some tools (mainly IDA), but even a decompiled (pseudo)code seems very complex. I was able to deduce some things, like that they used the Watcom compiler for LBA1 with a DOS extender (DOS4G/W), but I am not familiar enough with the old DOS architecture, nor do I possess adequate reverse-engineering skills.
  • What is missing for the current TwinEngine implementation? What prevents us from writing the missing parts? Did yaz0r have the original source code for any components when working on TwinEngine? If so, was it the full source code or just some parts?
  • I can see that the current TwinEngine code uses software rendering. I presume this is because the original game also used this. If so, the missing parts of the renderer could also be reverse-engineered or we could use the original source code if we could get it. Is there any hope some old Adeline members are willing to share the code (privately)?
  • I like the new approach of the JavaScript engine where the target is not reverse-engineering but reimplementing everything from scratch. Still, I think, some parts can only be made exactly like the original if we do some reverse-engineering work first (if only to get the basic idea how should we implement some parts). TwinEngine code is almost complete, which is helpful if we would like to make progress with the JavaScript engine, but I think the missing parts (especially in the renderer) should be reversed (even if only "partially") for it to be entirely usable.
  • LbaWin was made by Sebastien Viannay. Am I right when I presume he was only able to create that because he had the original source code? Do we have any information about that which parts had to be reimplemented for LbaWin to work? Does it also use software rendering? Does it use DirectX for drawing the screen (even if the rendering is done in software)? I looked at the LbaWin binary and it shows that it was made into a Win32 application and compiled with Visual C/C++. It should mean that the original code was not so platform-dependent that it was too hard to port it to Windows. Do we have any estimation about the scale of that project, the time Sebastien spent working on it? It even had some bugfixes/improvements over the original, these were also done by tweaking the source, am I right? Could we by any means obtain the LbaWin source code?

Angelus 2019-01-06 02:36

Hi, from what I know about TwinEngine there is TO-DO in source code
https://github.com/xesf/twin-e/blob/master/TODO.md

Sadly it missing support to LBA2 as far as I know. This would be biggest thing to do probably :)

About software rendering I don't know why it was chosen but I suspect: portability. Thanks to it you don't need good graphics card to play the game. Another advantage is that you don't need to worry that it will have some rendering problems on different graphics cards. SDL giving you nice abstraction layer for 2D rendering.

I don't know answers for other questions but I would check forum I remember there was a lot of discussions about this topics.

Lupin 2019-01-09 20:38

Regarding LbaWin, I suspect 95% of the code was kept unaltered, and he probably just adapted the windowing part. I suppose it uses DirectX to display the frame buffers indeed, but yeah, it's most certainly the same software rendering code otherwise.

As for using software rendering, the type of rendering used in the original game engine is not easily adaptable to standard graphic libraries calls like DirectX or OpenGL, well, at least it wasn't at the time the TwinEngine project was started (I think shaders were in their infancy at the time), so that might be a good reason. Even nowadays, there's no easy way to make a pixel-perfect replica of the original engine without some code-contortionism.


All times are GMT +2. The time now is 09:44.

Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2019, the Magicball Network