The big open question is the implementation of the Poll functionality. Currently, the code still uses the POSIX implementation of the Win32 API. As a first version (and since the code is not being used in the vectorwar example) I think it's better to have this than nothing (or nothing that compiles).
For the case that you want to implement a more POSIX-style API before merging this, I looked into how to implement such an API. I think using file descriptors for signaling of events could be the most appropriate way to handle these (if I understood this API correctly). Then we could use either select(3P) (available on both MacOSX and Linux) or epoll (Linux) and kqueue (MacOSX, though I have read online that this function can be buggy) to check which event has fired (i. e. which file descriptor is readable).
MIfeanyi
commented
3 years ago
After two months of inactivity on https://github.com/pond3r/ggpo/pull/37 I took the liberty to apply most of the requested changes.
The big open question is the implementation of the
Pollfunctionality. Currently, the code still uses the POSIX implementation of the Win32 API. As a first version (and since the code is not being used in the vectorwar example) I think it's better to have this than nothing (or nothing that compiles).For the case that you want to implement a more POSIX-style API before merging this, I looked into how to implement such an API. I think using file descriptors for signaling of events could be the most appropriate way to handle these (if I understood this API correctly). Then we could use either
select(3P)(available on both MacOSX and Linux) orepoll(Linux) andkqueue(MacOSX, though I have read online that this function can be buggy) to check which event has fired (i. e. which file descriptor is readable).What do you think?