Closed kipraske closed 9 years ago
Okay - it has nothing to do with how "blocking" my I/O code is - if you look at "TravelMap" in Movement.c you will see that pauseBrogue is called on line 1465 which checks to see if there is any input for 500 ms and if it is then we stop traveliing.
Well web platform as it is currently defined always returns true for pauseBrogue because I was lazy.
So to fix this, we just need to create a polling/non-blocking IO - fake events just won't work for this reason.
Alright I have determined that my best bet is to stop developing this c code within windows so I can use the full posix c libraries.
It looks like the function I need to use is "select" which will block IO for a specified amount of time and then return -1 for error, 0 for timeout, and something bigger than 1 for if the buffer has something available.
In windows the select function only works on sockets. Because of node.js the "everything is a stream" philosophy seems to translate well into the POSIX "everything is a file". I think my best bet is to stop trying to get this c program to work in windows at all. Also the server will probably be linux eventually anyway so I need to plan for that.
Summary of what I tried in windows that didn't work
Moving to linux and using poll does the trick. See commit d36d41012bd7f3acd1e84f79b61fe9115af997cf. The best part was realizing that we could block on the main menu by always returning true but only when we are on NG_NOTHING state.
The web platform brogue code i/o is blocking now and waits for user input on each turn. The reason for this design is tp prevent a flood of cell updates over the socket as the cells dance. Also kipraske is new to c so he just did the easiest thing at the time. Here are my initoal thoughts for how to get around this.
Going back to curses is probably the best option of the three but it may require major changes to how i/o is handled