refactoring: Separate Bullfrog Library from the rest of the code

[mefistotelis]

The Bullfrog Library could be changed into a static library, and kept in separate folder. This way it would be much easier to share patches with other Bullfrog games, ie. keeperfx or genewars.

Example of a project where bflibrary is already a separate static lib: https://github.com/mefistotelis/genewars

[PieterVdc]

would you eventually move the bflib to 1 repo shared between the games? or just make sure it's similar enough to easily use the other ones as reference? if seperate repo I guess for keeperFx it would be ideal to first wait till there's no more dll dependency but that one would also be the best one to use as a base, as it's the only fully rewritten one then

[mefistotelis]

separate repo - I am considering this, but it's probably not the best idea - it means any changes would have to be coordinated between multiple projects, and there isn't enough community to make this work.

best base - keeperfx diverged from the original bullfrog library in some aspects; it's the most complete code base, but not the best source for re-creating original API. I want bflibrary to stay backward compatible for any more games (creations, hi-octane, magic carpet). But I will expand the API to some of KeeperFX changes, ie. defining new video modes to allow custom resolutions.

wait for full rewrite - there is no real need for that. But moving to this library will probably not be a priority - KeeperFX works well enough as is. On the other hand, the API might drift away even further over time. But first, KeeperFX would have to be switched to autotools.

The library will have some benefits for KeeperFX though:

• ability to choose between SDL1 and SDL2 (not done yet)
• windows/linux/mac support (already done)

I was also thinking about a switch between hardware/software renderer. That's not easy to achieve while keeping backward compatibility, but still, seem possible. Maybe the HUD could be rendered in a separate layer, and then composited with main screen buffer - like cellphones do.

[PieterVdc]

for magic carpet specifically I see a couple of branches of remc2, this one seems like the most active, https://github.com/thobbsinteractive/magic-carpet-2-hd guess a ticket could be made there as well to see if he's interested in aligning as well

[mefistotelis]

Yeah, that wouldn't hurt.

[mefistotelis]

Progress: Most of the original bflibrary API is now remade and used; missing: Fading - gpalette.c: LbPaletteFade,LbPaletteStopOpenFade (exists in KeeperFX, though modified; we probably want original) Sprite font: gtext.c: LbTextStringWidth, LbTextStringHeight, LbTextDraw (exists in KeeperFX; modified, but those are good modifications) Polygon rendering: poly.c (whole) Other: rom.c:int prop_text, make_fade_table, qaz

Other needed stuff: Support of custom resolutions - to be copied from KeeperFX Support of SDL2 - not started Unified parsing of INI files - to be developed base on KeeperFX Support of scaled fonts - to be copied from KeeperFX

[mefistotelis]

Progress: Fading is now remade Sprite fonts are remade, though not well tested Polygon rendering - there are 3 functions: trig(), poly_line() and draw_gpoly() -- trig() is remade, and the C version works exactly as original. It is also compatible with KeeperFX - tested that today -- poly_line() is not remade -- draw_gpoly() - I see considerable differences in this function between Dungeon Keeper and Syndicate Wars. I didn't decided yet how to approach this (whether I should rewrite DK version or SW version). Other: rom.c:int prop_text, make_fade_table - remade, qaz - removed, as it is unnecessary in C implementation.

[PieterVdc]

ah nice, keeperFx is getting close getting rid of dll, good to know some of the asm can be taken from here

[IntelOrca]

@mefistotelis I can provide the source code to gpoly.asm if you like. It has a set of macros which controls the assembled output - so that might be why the implementations are different.

[PieterVdc]

keeperfx started on rewriting some of the asm here, atm still draft https://github.com/dkfans/keeperfx/pull/3129

[mefistotelis]

That's great. Though it's unlikely to help with Syndicate Wars. I stopped working on draw_gpoly rewrite mostly because I was unable to consolidate DK and SW versions - they are too different.

Maybe like @IntelOrca suggested, it is driven by macros too much.

[AbyssalDrifter]

@mefistotelis @IntelOrca Can you maybe expand on what macros you are referring to?

[IntelOrca]

I can't remember exactly, but I would assume that Bullfrog did not have several versions of this raw assembly file, but rather a number of macros which used together form the assembly code based on the given parameters.

Now days you'd do it in C++ using template parameters. But it is just a way to generate multiple different implementations from the same source code, slightly tweaked in different ways.

[AbyssalDrifter]

I've had a look at the gpoly.asm file and there is indeed MASM macros that generate mostly duplicate code with different points etc. The data packing is already different for DK from what is in the asm file, but I think the file is from Pop 3 maybe. I think this can be turned into smaller helper functions (maybe inline) that just uses pointers, not sure yet.