-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Port] WinRT / UWP - Xbox One and Windows 10 #6
Conversation
if (d != INVALID_HANDLE_VALUE) { | ||
BOOL found = TRUE; | ||
while(FindNextFileA(d, &de) != 0) { | ||
if (de.cFileName[0] == '.') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't quite sure of the intention with this check (Initially I had assume this was to filter "." and ".." on some platform; but I think it's for dot-files).
On Windows it might make more sense to check for hidden files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With your previous variant, (while (1) if dot: continue) it never called FindNextFile so it was stalled in an endless loop. Hence, FindNextFile is the while condition now. And yea, the filtering for dotfiles (and prev-dir absolutely makes sense).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the future: please let me know about such bugs on my repository - I was unaware of this.
I usually send PRs to myself so other people can leave feedback like this for a specific branch (without opening an issue). So leaving feedback is simple - just add a comment in that PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your code has added a new bug: the first file (from FindFirstFileA
) won't be listed?
char filePath[_MAX_PATH]; | ||
WIN32_FIND_DATAA de; | ||
snprintf(filePath, sizeof(filePath), "%s\\*", dir); | ||
HANDLE d = FindFirstFileA(filePath, &de); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a note: I forced ASCII variants here because our Xbox toolchain does not support unicode (yet; and even then we'll likely be stuck with UCS-2).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea thats fine here too I think - personally I never reached the unicode era and still prefer ASCII ^^
Hi, As you may know, I'm not the author of the hode engine, @cyxx is. My repo can be considered as a cloned one, only dedicated for the ports I'm working on (PS Vita + Nintendo Switch). I don't want to centralize all possible ports here, I prefer to stay focus on my own work. So sorry, I will not push this PR on my repo. I suggest you to maintain your own port in your cloned repo, such as @gameblabla does for his opendingux port |
No idea |
I think it would be nice if someone could volunteer for a centralized GitHub repository. Ideally @cyxx, but if they don't want to allow ports (for platforms as small as they might be), then I'd like to see someone else take care of this. I feel like there are things which could be improved in the original HODE already, but also things that would be especially useful as base for console ports (which might not be suitable for upstream HODE in general, as it would potentially complicate the codebase). It would be annoying to have a complicated network for these ports with each one doing individual fixes to make the game more suitable for consoles (which typically don't have CLI arguments, need a dedicated save path, need more initialization, ..). |
This PR adds a WinRT Visual studio solution to build the engine for WinRT/UWP/Windows 10.
Notes:
For compatibility a few changes to the codebase had to be made:
https://github.com/usineur/hode/compare/master...tuxuser:winrt?expand=1#diff-ea59994a2cddd255d29c5595797c8b30L25-R52
https://github.com/usineur/hode/compare/master...tuxuser:winrt?expand=1#diff-118fcbaaba162ba17933c7893247df3aR140
To deploy a ready-to-use container, the gamedata files are referenced in the project and expected to be available at build-time.
The caveat is that UWP restricts filesystem access for files outside of the built container.
It might be worked around with full filesystem capability set in the Package.appxmanifest, that would break support for Xbox One however.
Maybe its fine to require gamedata at build-time in this case?