LBA 1 & 2 engines

[Cade]

Hello chaps,

After a long time and a colourful few years, I think I'd like to try LBA again. I have two questions,

1) I didn't find this, so excuse me if it's obvious, is there any engine remake for LBA 1 that lets me play from start to finish?

2) Same for the previous question, but with LBA 2? If not, does anyone know what rendering API LBA 2 uses? I think DirectX 3, but I'm not sure. If I have some free time, I might try to make a proxy DLL + wrapper around DirectX 9, so I can atleast have bilinear texture filtering (3D outdoors) , maybe replace the dithered fog table with something nicer and take a crack at the resolution. No luck if it's purely a software renderer though.

[Cade]

A little update, looks like LBA 2 is fixed to use software rendering internally. I'm continuing on with a directdraw proxy DLL because LBA 2 uses it to copy its rendering to the screen, maybe I can work a hi-res patch by upscaling + filtering.

So far so good:

DirectDrawCreate(00000000,000CFA0C,00000000)
<<intercept>>
DDraw[inst 0] ctor -> 000cfa0c
DDraw[inst 0]::QueryInterface(IID_IDirectDraw2,004d11a8)
DDraw[inst 1] ctor
DDraw[inst 0]::Release
DDraw[inst 0] dtor
DDraw[inst 1]::SetCooperativeLevel(000e029a, 19)
DDraw[inst 1]::EnumDisplayModes
DDraw[inst 1]::SetDisplayMode(640, 480, 8, 0, 0)
DDraw[inst 1]::CreateSurface({108, 0x1, 0, 0, 0, 0, 512}, 004d11a0, 00000000)

Forcing 1024x768 lets me still control normally but the surface pitch is out of alignment when it's written to screen. Time to experiment more.

[TommyGun]

Good guys ... keep it up ... I also hope we can have a polished engine with a bit nice graphics to play on.

[Darkflame]

Nice idea with the upscaling. It is a shame though that LBA2 didnt use DirectX....the things we could have done (would even have been able to play it in 3d :P)

I dont think any of the LBA1 mods/engine reimplementation let you play all the way though though. yet.

[Cade]

Some screenshots showing the difference. The wide ones are stretched (badly) to my monitor, one is point-filtering, the other is bilinear filtering (bottom two). There are two other (not filled to screen) that compare original with upsampled with Scale2x (middle pair), you can see the improvement on the text but ingame (top pair) looks about the same.

[TommyGun]

Yes im aware its hard to get any astonishing graphics out on an old product. Maybe its better if you recreate the whole game with a newer technology. Ofc this would take too much effort hehe. :-D

[Cade]

I had a lot better luck with Deus Ex, enough for even "fake" bump-mapping from lights. Here, the only information I have is a lot less.

The only commands I modify are:
DDraw::SetDisplayMode to force a different resolution
DDrawPalette::SetEntries to get the 256-colour palette
DDrawSurface::Lock to trick the game into rendering to a 640x480 8-bit buffer instead of the real one because the real one is at a different resolution. FunnyFrog's patch does something here that makes it crash with this custom ddraw.dll, I think that it probably fixes pitch with the real primary surface, ignoring my forced attempt to send it a pitch of 640 and getting the real patch.
DDrawSurface::Unlock If the primary buffer is unlocked here, LBA2's rendered into that fake buffer I set up, so I upsample to 1280x720 and convert the colour palette to 32-bit colour here. This converted buffer gets written to the real primary buffer.

[Darkflame]

shouldn't you convert the colour before upsampleing? (so theres more inbetween colours for the scaling algorithm to use).

[Cade]

Yes and no.

Bilinear filtering won't work with palettes at all, so it gets converted before upscaling.

Scale2x is a binary operation, it just checks if colours exactly match, so I upscale then convert. Converting before Scale2x looks exactly the same, just the logic is 3 times longer to run. Because it's perfect for binary images, Scale2x is used in emulators much more often, looks like this:

Versus

[Dead1nside]

Is the only LBA2 engine reimplementation the lba2engine project, which is early stage on Sourceforge by alexfont?

[Cade]

I modified ddwrapper (from ddhack, http://sol.gfxile.net/ddhack/ ) to support D3D10 enough to render LBA 2 without dependency on directdraw. I don't have much free time, so I won't try to reverse-engineer LBA2 enough to figure out more. For now, graphics quality is about the same (no improvement) between the original and ddwrapper + fancy scaling + D3D10 (images in the previous post).

[Lupin]

Nice investigations here. I don't think DirectX allowed what they did with the 256-color dithering algorithms at the time the game was made...
Yeah, LBA2 would require a full reimplementation to benefit from quality graphics improvements.
I don't think alexfont is still active on the lba2engine project, it's really too much work.

[Cade]

I'm done with what I wanted for now, I can play LBA2 in a window without changing display mode, and its ddraw calls are fully emulated in D3D10 now.




If other people also want it, I'll continue testing, then I'll upload my custom ddraw.dll here. It's a heavily modified version of ddhack which doesn't originally support LBA2. The black bars on the sides are because I have a widescreen desktop.

[Darkflame]

LBA2 without a display mode change is already very usefull imho!

[Cade]

True, but it irritates me because my layout of other windows gets changed when it switches resolution, and the default upscaling of my monitor isn't as good as filtering it in a shader.

[Cade]

Let's see if I can reverse engineer LBA 2 into running at a higher resolution... it's a mess in assembly.

800x600, first run without a crash

[Darkflame]

Nice start!

[Bot13]

Just wanted to say, keep doing what you're doing

[Cade]

Thanks guys, but the assembly behind the renderer appears to be extremely convoluted, too messy to reverse engineer. This would be difficult even with the original source, here I have to guess what everything is.

In the meantime, I messily deciphered the decompression routine that handles a bunch of different files (including saved games ) to C.

void DecompressBuffer(int len, BYTE* src, BYTE* dest)
{
	BYTE v_eight = 8;
	UINT8 byte_buf1 = *(BYTE*)src++;

	UINT32 v8;
	INT32 v9;
	INT32 v10;
	UINT32 v13;
	INT16 v15;
	UINT8 v16;

	while (true)
	{
		while (true)
		{
			while (byte_buf1 & 1)
			{
				byte_buf1 >>= 1;
				*(BYTE*)dest++ = *(BYTE*)src++;

				if (--len == 0) { return; }

				if (--v_eight == 0)
				{
					v_eight = 8;
					byte_buf1 = *(BYTE*)src++;
				}
			}
			byte_buf1 >>= 1;

			v10 = (INT32)~*(WORD*)src >> 4;
			v8 = (INT32)(*(WORD*)src & 0xF) + 2;
			src += 2;
			
			v9 = v10 + (INT32)dest;
			
			len -= v8;
			if (v10 == -1) { break; }

			if (v8 & 1) { *(BYTE*)dest++ = *(BYTE*)v9++; }
			
			v13 = v8 >> 1;
			while (v13--)
			{
				*(WORD*)dest = *(WORD *)v9;
				v9 += 2;
				dest += 2;
			}

			if ( !len ) { return; }

			--v_eight;

			if (!v_eight)
			{
				v_eight = 8;
				byte_buf1 = *(BYTE *)src++;
			}
		}
	
		v15 = ((*(BYTE*)v9) << 8) | *(BYTE*)v9;

		if ((size_t)dest & 1)
		{
			*(BYTE*)dest = v15;
			--v8;
			++dest;
		}
		
		v16 = v8 & 1;
		for (int i = v8 >> 1; i; --i)
		{
			*(WORD*)dest = v15;
			dest += 2;
		}
		if (v16) { *(BYTE*)dest++ = v15; }
		if (!len) { break; }
		--v_eight;
		if (!v_eight)
		{
			v_eight = 8;
			byte_buf1 = *(BYTE *)src++;
		}
	}
}

[Cade]

This is what happens when you're bored of working and have nothing better to do than to modify the camera follow random characters instead of Twinsen.




A single byte in the save-game file format lets you choose which character the camera will follow. Perhaps this is intended for cut-scenes.

[Darkflame]

Curious thats stored in the save game file however.

[Cade]

It's +0x277 bytes after the end of the image data. The default value of 0 means that the camera will follow Twinsen. Set it to the index of the character in the current map chunk to make the camera follow that character.

[Trolle]

It's really exciting to read about your progress Cade. I have been thinking about doing something similar but I have zero reverse engineering skills so I never knew where to start. How exactly do you "hook in" to the original game files and how do you know where to find the right spot in the tons of assembly? I really hope you spend more time on this! LBA2's 3D part has looks pretty bad of today standarts but a reimplementation of the rendering engine maybe together with some high res textures would be very nice

[Cade]

Thanks. I usually use OllyDbg and IDA to take things apart. I set breakpoints on OS calls, like open file and such, which are called by LBA's internal read file functions, then I work backwards from there. Modifying the rendering code is much more difficult, it's a mess. I have identified where LBA2 locks the ddraw buffer and unlocks it, so anything and everything in between is fair game. I haven't managed to make any progress on the rendering code because I'm unable to figure out what does what. It's probably not going to work without the original source code.

Reverse engineering file formats is something else. I used to use a generic hex editor to play with files, but I have written an interactive file disassembler since then.
http://i.imgur.com/LGqor.png
http://i.imgur.com/eZuhB.png
http://i.imgur.com/hhbae.png (normal hex editor view)

[Zink]

I think one of us (yaz0r) may be in possession of LBA2 source code, but as far as I know, he must not share it publicly. He is not visiting this forum any more, but you could ask Alexfont to contact you with him, and maybe he would share the interesting code pieces with you.

I very much like the work you're doing here. Good luck with it .