Other Projects > Curses
LCS Android Port?
Reelya:
Well that header would be the easy part, the hard part would be that C# is fairly restrictive of a lot of things than C++. Syntax is similar but plenty of little tricks possible in C++ plain won't work.
For example, there's no multiple inheritance in C#, so any multiple inheritance in C++ would probably be best to just refactor away before the port.
Another thing is global variables. You just don't get to have them in C#, you'd need a class with static variables in it. The C++ can be refactored to have that.
Also, C# doesn't have C++ style pointers and references, it has a single reference type that can be null, similar to C++ pointers.
C# also has several more Java-like requirements that almost everything needs to be inside a class in C#, and that could impact some things too.
Those kinds of changes can lead to ripple-on effects throughout the codebase, so I'd think that trying a tentative C# port of some subsystems might indicate potential problems.
Rather than doing a super-hacky one-off C#/Unity port, it would be far better to do the needed fixes on the C++ side of things. The entire point of the C#/Unity exercise would be to end up with a truly cross-platform version that can in fact be maintained.
misterTwister:
Interesting. Reelya, do you have a github so I can give you collaborator access? This is the first time I'm actually participating in a collaborative project, so pardon my amateur-ness.
Basically, the beginning choices would be entirely UI elements on the canvas. We should keep in mind that options should be linked to a button press, but also a mouseclick for when we switch to an android platform. Would it be easier to do certain text and the infiltrations, like the beginning founder backstory, as separate scenes rather than the whole game being one scene? That way you don't have to keep destroying or hiding gameObjects when you don't want to display them. Instead, each screen will load the next scene as soon as you choose an option. It might simplify things a bit.
I am not well versed on the C++ code, not sure how much I can contribute to that.
Try to keep the project file hierarchy organized if you are gonna work on it. Some of the folders were not included in the github for some reason, but you can see their meta files.
Reelya:
Don't go for separate Unity scenes, that way lies madness and unmaintainabilty. The thing is, C++ has no concept of "scenes" with different code in them, so trying to add that to the existing, working game would be months worth of screwing around for really no benefit.
But trust me, there's a ton of work that would need to be done on the C++ before it's even viable to think about porting it.
For example there are a ton of functions that take pointers or references to things like creatures, when they should in fact take an int which is the index of the creature in the global table of creatures. That would fix a lot of things and be more portable (since C# only has references, and they don't work like C++ references, whereas passing an int is totally portable without needing to rewrite every single function header).
Also, remember, virtually everything in LCS is separate global functions and plenty of global variables. None of which is even allowed in C#. Every single header file in LCS would need to be replaced by an object that includes the functions as static functions. Luckily, that'll work in both C++ and C#, so it should just be done on the C++ side to start with. All the "extern" shit needs to go as well then.
and there is the use of "char *" raw strings everywhere. That would need to be changed so that they use a string class consistently, preferably one with a compatible interface to C# native strings. That's do-able, but should definitely just be refactored into the C++ to start with.
IsaacG:
--- Quote from: Reelya on June 05, 2018, 10:34:35 pm ---Well that header would be the easy part, the hard part would be that C# is fairly restrictive of a lot of things than C++.
--- End quote ---
True enough. That said, the header file is a list of most of the new code that needs writing, as opposed to old code that needs to be rewritten. By that I mean it's the work that can be done without requiring specific experience with the LCS codebase. Any progress people make on implementation of those functions can be made without fear of stepping on my toes.
--- Quote from: Reelya on June 05, 2018, 10:34:35 pm ---For example, there's no multiple inheritance in C#, so any multiple inheritance in C++ would probably be best to just refactor away before the port.
--- End quote ---
Not to worry, there's no multiple inheritance in LCS. Barely any inheritance at all, since LCS uses so little object oriented programming, which is a problem in the other direction.
--- Quote from: Reelya on June 05, 2018, 10:34:35 pm ---Also, C# doesn't have C++ style pointers and references, it has a single reference type that can be null, similar to C++ pointers.
--- End quote ---
That... that is going to be a pain. Not going to lie.
--- Quote from: Reelya on June 05, 2018, 10:34:35 pm ---C# also has several more Java-like requirements that almost everything needs to be inside a class in C#, and that could impact some things too.
--- End quote ---
Certainly. Most of the refactorings I've done over the past year have been to help porting to Java. It will be a lot easier to port 4.12 than 4.10. There was this duplicate line of code that an object's pointer was subtracted from another pointer in order to get its index for a global array. It made me cry. It's gone now, and it won't hurt anyone ever again.
--- Quote from: Reelya on June 05, 2018, 10:34:35 pm ---Those kinds of changes can lead to ripple-on effects throughout the codebase, so I'd think that trying a tentative C# port of some subsystems might indicate potential problems.
Rather than doing a super-hacky one-off C#/Unity port, it would be far better to do the needed fixes on the C++ side of things. The entire point of the C#/Unity exercise would be to end up with a truly cross-platform version that can in fact be maintained.
--- End quote ---
Glad to see someone else thinking ahead.
--- Quote from: misterTwister on June 05, 2018, 10:56:55 pm ---Basically, the beginning choices would be entirely UI elements on the canvas. We should keep in mind that options should be linked to a button press, but also a mouseclick for when we switch to an android platform. Would it be easier to do certain text and the infiltrations, like the beginning founder backstory, as separate scenes rather than the whole game being one scene? That way you don't have to keep destroying or hiding gameObjects when you don't want to display them. Instead, each screen will load the next scene as soon as you choose an option. It might simplify things a bit.
--- End quote ---
In theory a multiple scene setup could work, but LCS as written in C++ only has one 'scene'. KISSOM, Keep It Simple, Sir Or Madam.
--- Quote from: Reelya on June 05, 2018, 11:16:44 pm ---But trust me, there's a ton of work that would need to be done on the C++ before it's even viable to think about porting it.
--- End quote ---
ABSOLUTELY TRUE.
--- Quote from: Reelya on June 05, 2018, 10:34:35 pm ---Another thing is global variables. You just don't get to have them in C#, you'd need a class with static variables in it. The C++ can be refactored to have that.
--- End quote ---
--- Quote from: Reelya on June 05, 2018, 11:16:44 pm ---All the "extern" shit needs to go as well then.
and there is the use of "char *" raw strings everywhere.
--- End quote ---
I've done a fair amount of refactoring to reduce the scope of global variables. Each variable is declared exclusively in the file it is used, and the only usage of the externs keyword is within individual functions. It was an enormous pain. I have dreams about "extern". No matter how many I kill, they keep coming.
And char*. My C++ book says not to use char*, and that's all it has to say about that.
Throughout the LCS codebase there are instances of:
--- Code: ---string str = ...;
someFunction(str.data(), ...);
someOtherFunction(str.c_str(), ...);
--- End code ---
.data() and .c_str() are functions that convert a string to a char*. (.data() and .c_str() are the same function, but they used to be different, so there's controversy in the C++ community about which one to use, but they are mostly interchangeable with modern compilers)
LCS is so tightly connected with char* that many strings have to be converted to char* in order to be used. Much work to be done.
Reelya:
What might be a good idea for the strings is to add a home-brew string class to LCS in C++, but replicate the needed functionality of the C# String in it.
Internally, the LCS-String could then use std::string, but by hiding it inside a wrapper it will be more portable.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version