Create timer and timerGroup struct

[blmarket]

Motivation

To make the conversion easier, need to have a better understanding of undefined structs in the C code where it's hard to understand when the code has lots of pointer offset access. I found those 2 structs have a minimal external dependency (only need to use platform ticks) so created this change.

Changes

Made assumption of structs from the C code.

To avoid any possible regression, only the function parameter type has been updated. Some go unit tests were introduced to demonstrate the fields are working as expected.

Required sign-off

• I confirm that my PR does not contain any commercial or protected assets and/or source code.
• I agree in advance that my codes will be licensed automatically under the Apache License or similar BSD/MIT-like
  open source licenses in case if OpenNox Project will adopt such a non-GPL license in the future.

[dennwc]

Great work! And you have my respect for adding the tests for the C code! 🙇‍♂️

[dennwc]

Thank you for being careful and doing it one step at a time!

I should really give you an intro to the tooling I have in cxgo branch. It will make this process a lot faster.

The main idea is that you can discover C types there, and once you do that, it can automatically rewrite code based on the new field offsets.

Since it already has all the code translated from C syntax to Go, you look directly at that Go code in legacy there and compare to C only if in doubt. The way I usually work there is find a function of interest (let's say the one you have here sub_4862E0), follow the code looking for clues about the struct size (as you already did here). If you can discover struct layout immediately - that's awesome! If not, you make a temp Go struct in that code base:

type timer struct {
   field_0 uint32 // 0, 0
   field_4 uint32 // 1, 4
   field_8 uint32 // 2, 8
   field_12 uint32 // 3, 12
   field_16 uint32 // 4, 16
   field_20 uint32 // 5, 20
   field_24 uint32 // 6, 24
   field_28 uint32 // 7, 28
}

I have a tiny tool that generates these temp structs given a size. Can push it as well if you want.

So having either this, or your guessed struct layout, you change that Go function signature and run fixlegacy:

cd src
go run ./internal/fixlegacy

This tools doesn't have any dependencies and it will read all Go in legacy, will notice that you added a specific type to the function argument and it will automatically rewrite pointer offsets in that function to direct field accesses.

Notice that in my temp struct I didn't guess the type of last two fields, which should be uint64_t. This is fine. Tool is careful enough to not convert an offset access if it notices that access is done with a larger type than the current field size is. So you just guess and convert. If you see that some offsets remain - you adjust the struct field types and run the tool again.

With that iterative approach, you can quickly propagate your new types around, validating your struct layout. Once you're done, you will likely have clean Go code in this cxgo branch than can directly replace old C code.

Next steps are up to you. The safer path is to take only structs first, as you did in this PR, and than slowly bring these clean new functions from cxgo to dev. But I'm not always patient enough, so I could move all code related to certain struct in one go (if I'm more or less certain that code makes sense).

[blmarket]

Wow, yeah that would help a lot! Surely the next step will be moving the existing C code to Go version, and I agree with the approach you mentioned. Let me try the tool to see it works with new structs.