On Saturday, 11 July 2020 at 16:18:52 UTC, Remi wrote:
> I'm now trying to find docs on the "bit" type.

it is really the same as bool

On Saturday, 11 July 2020 at 16:23:21 UTC, Adam D. Ruppe wrote:
> On Saturday, 11 July 2020 at 16:18:52 UTC, Remi wrote:
>> I'm now trying to find docs on the "bit" type.
>
> it is really the same as bool

Thanks! It seems it was in an old SDL binding (1.x) and I replaced it with SDL_bool, seems to have done the trick. It seems to have been useful in the past to make bitfields for example.

On 7/11/2020 10:52 AM, Remi wrote:
> On Saturday, 11 July 2020 at 16:23:21 UTC, Adam D. Ruppe wrote:
>> On Saturday, 11 July 2020 at 16:18:52 UTC, Remi wrote:
>>> I'm now trying to find docs on the "bit" type.
>>
>> it is really the same as bool
> 
> Thanks! It seems it was in an old SDL binding (1.x) and I replaced it with SDL_bool, seems to have done the trick. It seems to have been useful in the past to make bitfields for example.

BTW, your work updating it would make for a nice D Blog article. If accepted, you'll even get paid!

Also, if the license of the game permits it, please make it available on github.

On Saturday, 11 July 2020 at 20:17:40 UTC, Walter Bright wrote:
> On 7/11/2020 10:52 AM, Remi wrote:
>> On Saturday, 11 July 2020 at 16:23:21 UTC, Adam D. Ruppe wrote:
>>> On Saturday, 11 July 2020 at 16:18:52 UTC, Remi wrote:
>>>> I'm now trying to find docs on the "bit" type.
>>>
>>> it is really the same as bool
>> 
>> Thanks! It seems it was in an old SDL binding (1.x) and I replaced it with SDL_bool, seems to have done the trick. It seems to have been useful in the past to make bitfields for example.
>
> BTW, your work updating it would make for a nice D Blog article. If accepted, you'll even get paid!
>
> Also, if the license of the game permits it, please make it available on github.

I'll keep that in mind, it's not my game unfortunately and it's pretty obscure but I'll try to get approval from the original author once I got it to work.

Finally got everything to compile but having linking issues. The game came with .lib files but I have no idea what format they are, I assumed a Windows MSVC format but the VC tools don't seem to be able to read them.

On Saturday, 11 July 2020 at 22:44:08 UTC, Remi wrote:
> Finally got everything to compile but having linking issues. The game came with .lib files but I have no idea what format they are, I assumed a Windows MSVC format but the VC tools don't seem to be able to read them.

That would be the OMF format that D on Windows supports. It is old, think Windows 95, but dmd and the optlink program that comes with it on 32 bit windows still has the support code in there.

idk if dub allows it, but if you just compile+link with dmd itself using `-m32` it should use it.

On Saturday, 11 July 2020 at 23:00:29 UTC, Adam D. Ruppe wrote:
> On Saturday, 11 July 2020 at 22:44:08 UTC, Remi wrote:
>> Finally got everything to compile but having linking issues. The game came with .lib files but I have no idea what format they are, I assumed a Windows MSVC format but the VC tools don't seem to be able to read them.
>
> That would be the OMF format that D on Windows supports. It is old, think Windows 95, but dmd and the optlink program that comes with it on 32 bit windows still has the support code in there.
>
> idk if dub allows it, but if you just compile+link with dmd itself using `-m32` it should use it.

I got it work thanks! The problem was the way the extern(Windows) was selected as it was inside a version(Win32) which didn't seem to work. I just forced it to always use extern(Windows) for now until I need to make it work across platforms.

Good news! Finally got a .exe and it seems to start running, but it has now detected a cyclic dependency between constructors/destructors. Time to dive more into the code itself!

On Saturday, 11 July 2020 at 23:00:29 UTC, Adam D. Ruppe wrote:
> On Saturday, 11 July 2020 at 22:44:08 UTC, Remi wrote:
>> Finally got everything to compile but having linking issues. The game came with .lib files but I have no idea what format they are, I assumed a Windows MSVC format but the VC tools don't seem to be able to read them.
>
> That would be the OMF format that D on Windows supports. It is old, think Windows 95,

OMF is a bit older than windows or even Microsoft DOS. It goes back to 8080 times in the 70s
https://www.os2museum.com/wp/how-old-is-omf/

but dmd and the optlink program that
> comes with it on 32 bit windows still has the support code in there.
>
> idk if dub allows it, but if you just compile+link with dmd itself using `-m32` it should use it.

On Sunday, 12 July 2020 at 08:18:00 UTC, Remi wrote:

>
> I got it work thanks! The problem was the way the extern(Windows) was selected as it was inside a version(Win32) which didn't seem to work. I just forced it to always use extern(Windows) for now until I need to make it work across platforms.

version(Win32) is version(Windows) these days.

https://dlang.org/spec/version.html#predefined-versions

On Sunday, 12 July 2020 at 08:18:00 UTC, Remi wrote:
> I just forced it to always use extern(Windows) for now until I need to make it work across platforms.

Use `extern(System)` in that case - it will be extern(Windows) and windows and extern(C) elsewhere. Common enough case to be built into D.

> Good news! Finally got a .exe and it seems to start running, but it has now detected a cyclic dependency between constructors/destructors. Time to dive more into the code itself!

You can disable that cycle check by just adding this global declaration somewhere to the file with the main function:

```
// enable cycles in static ctors
extern(C) __gshared string[] rt_options = ["oncycle=ignore"];
```

Then you can probably get it actually going!

On 7/12/20 10:19 AM, Adam D. Ruppe wrote:
> On Sunday, 12 July 2020 at 08:18:00 UTC, Remi wrote:
>> I just forced it to always use extern(Windows) for now until I need to make it work across platforms.
> 
> Use `extern(System)` in that case - it will be extern(Windows) and windows and extern(C) elsewhere. Common enough case to be built into D.
> 
>> Good news! Finally got a .exe and it seems to start running, but it has now detected a cyclic dependency between constructors/destructors. Time to dive more into the code itself!
> 
> You can disable that cycle check by just adding this global declaration somewhere to the file with the main function:
> 
> ```
> // enable cycles in static ctors
> extern(C) __gshared string[] rt_options = ["oncycle=ignore"];
> ```
> 
> Then you can probably get it actually going!

It's probably not going to be bad, but it can be. If it finds a cycle, it can't actually sort the ctors. This means that things could be run out of order, and if one static value depends on another, then you could have bad things happen.

However, most static ctors don't really depend on other static data, so in that case, it would be fine.

Another option to try is "oncycle=deprecate", which uses the old algorithm that was flawed.

I should say though that the old algorithm, even though "old" may not be as old as the game, which means it still might not work right.

Also, the old flawed algorithm changes the order of construction sometimes based on the order modules are passed to the compiler (hence the "flawed" part of it).

Good luck!

-Steve