Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[IsaacG]

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.

That's probably overkill.
The only functionality of strings that LCS uses are reassignment and concatenation.  The functionality of char* it uses (that are incompatible with std::string) are fixed length null termination and pass by reference reassignment.  Fixed length is fine, but the pass by reference reassignment is undesirable.  It overcomplicates the code and makes debugging a chore.

Creating a wrapper class would have its merits, but I'd rather isolate and ultimately remove the instances where LCS uses functionality of strings that are not already universally supported.

[Reelya]

It's not overkill. You only implement a minimum feature set, but you make the interface compatible with String as it exists in both C# and Java. There's no need to implement stuff that's never used.

But it needs to be done for portability, otherwise you'd need to go through and change each and every line of code that uses strings whenever it's ported.

Well planned refactoring doesn't need to happen all at once however, so a good start would just be to wrap a "char*" inside a thing called String then use that to pass char* around. By using String to mean char* you can probably make it so you never have to explicitly mention char* anywhere else except inside the String class. Then after that, you gradually move needed functionality inside the String class, keeping in mind that you want it to end up having the same interface as String in C#/Java. So, for a while you'd have your program using both the custom String and std::string, but you then phase out the latter, too, once the String class is functional enough.

[IsaacG]

It's not overkill. You only implement a minimum feature set, but you make the interface compatible with String as it exists in both C# and Java. There's no need to implement stuff that's never used.

But it needs to be done for portability, otherwise you'd need to go through and change each and every line of code that uses strings whenever it's ported.

Well planned refactoring doesn't need to happen all at once however, so a good start would just be to wrap a "char*" inside a thing called String then use that to pass char* around. By using String to mean char* you can probably make it so you never have to explicitly mention char* anywhere else except inside the String class. Then after that, you gradually move needed functionality inside the String class, keeping in mind that you want it to end up having the same interface as String in C#/Java. So, for a while you'd have your program using both the custom String and std::string, but you then phase out the latter, too, once the String class is functional enough.

That's a good point.  I just looked over some of the char*, and several explicitly cannot be replaced with strings because they interact with external libraries.  A string wrapper would solve most of those.

[Reelya]

Another thing I'll mention is that char isn't portable anymore. C# and Java have 16-bit chars.

The 8-bit value in both languages is called "byte". For small numeric values it thus might be better to replace char with byte and use a typedef.

It'll also be less ambiguous. "char" for things that aren't chars is in fact a problematic programmer short-cut. Just like it's good practice to name variables meaningful things, you can typedef inbuilt types and use enums as types everywhere possible, so that your typenames convey the semantic purpose.

EDIT: I also noticed the use of "short" type. This isn't a good type to use since it's ambiguous and implementation-specific.

EDIT2: Another thing is that we could use is to wrap all the curses calls up in our own class so that we don't have to have those crappy calls everywhere. A custom interface would be a lot cleaner.

[Starver]

PTWing, although will also say that I have the (apparently disappeared from Play) LCS install on an older tablet, which I might be able to get the..pkg of out of if I specifically do a bit of digging up of the necessary old hardware, then digging into its file system.

Seems like you're already doing it properly, though.

[Reelya]

The current code is so far different from what's in the pkg though and we'd need the source code anyway. But sure if some people want to play around with that version then it's cool that someone kept it, you could put it on mediafire or something.

[IsaacG]

Another thing I'll mention is that char isn't portable anymore. C# and Java have 16-bit chars.

The 8-bit value in both languages is called "byte". For small numeric values it thus might be better to replace char with byte and use a typedef.

My plan is to replace just about every single usage of char, short, and byte with int.  If it is meant to represent a character, it will use a Character.  If it is meant to represent a number, it will use an Integer.  The way LCS interchanges char and short is a nightmare of ambiguity.  There was a safehouse bug that used ">= char" that broke when converted to a short or an int, because certain characters have a negative value when interpreted as a short.  Any number with an absolute value smaller than 1 Billion can be represented with a 32 bit integer, and it is unnecessary to use a special data type just because its value allows for more compact storage.  Modern compilers are optimized for usage of 32 bit integers and 64 bit floating points.  That brief moment of confusion a programmer feels when trying to remember if a function returns its value as a char, byte, short, or int is too high a price for the possible benefits of using an 8 or 16 bit value.  The only reason we even have shorts and bytes as standard datatypes are because C++ was first used 33 years ago, because back then it made a difference.  95% of the filesize for LCS is located in its music files.  We don't need to use shorts, bytes, or chars.  And as long as I have a say, we won't.
o.o;
Sorry, got a little carried away there.

Another thing is that we could use is to wrap all the curses calls up in our own class so that we don't have to have those crappy calls everywhere. A custom interface would be a lot cleaner.

That's what that header file I kept going on about was.
Nowhere in the LCS source code, except cursesAlternative.cpp, is usage of the curses library.
Heck, most instances of

Code: [Select]

move(x,y);
addstr(...);
have been replaced with

Code: [Select]

mvaddstr(x,y, ...);
Just to avoid having to implement move(x,y);
If move(x,y) and addstr(...) can be replaced with mvaddstr(...) entirely, it will make mvaddstr(...) easier to implement, as it will no longer need to store current position.  It's one of the reasons I've been replacing char* with string.

PTWing, although will also say that I have the (apparently disappeared from Play) LCS install on an older tablet, which I might be able to get the..pkg of out of if I specifically do a bit of digging up of the necessary old hardware, then digging into its file system.

Seems like you're already doing it properly, though.

The current code is so far different from what's in the pkg though and we'd need the source code anyway. But sure if some people want to play around with that version then it's cool that someone kept it, you could put it on mediafire or something.

http://www.mediafire.com/file/7zykkvii3cd19su/lcsagame%20Android.zip
Includes source.

[Reelya]

Any number with an absolute value smaller than 1 Billion can be represented with a 32 bit integer

+- 2 billion actually, or 0 ~ 4 billion for unsigned int

Another choice is to declare things as enum types, when it makes sense. Then, the C++ compiler gets to make the optimization choice for you.

Though, I wouldn't do this for current enums of things that are data which could change often. For example, i'd avoid using creaturetype enums in this way, since it would be a good idea to move all creaturetype-specific code into the data files. It's really bad to have the game hardcoded to know what an Acrobat or a Dancer are.

But for something like an entity's gender, you can use an enum as the data type.

bools should be used more often too, whenever a value can only be true/false. enums for anything with a small range of allowed values, then rather than using numeric codes, the values can be compared to the allowed enum choices, which makes code much easier to read.

[IsaacG]

Any number with an absolute value smaller than 1 Billion can be represented with a 32 bit integer

+- 2 billion actually, or 0 ~ 4 billion for unsigned int

-2_147_483_648 ~ 2_147_483_647
0 ~ 4_294_967_295
Same difference.  Different precision.  The first statement lists a subset of numbers capable of being represented by a 32 bit integer, the second statement increases the size of the subset.  The third statement lists the exact subset.
In LCS most numbers never exceed 65_535, (or even 255, for that matter) that's why it has so many shorts and chars. 

Another choice is to declare things as enum types, when it makes sense. Then, the C++ compiler gets to make the optimization choice for you.

Though, I wouldn't do this for current enums of things that are data which could change often. For example, i'd avoid using creaturetype enums in this way, since it would be a good idea to move all creaturetype-specific code into the data files. It's really bad to have the game hardcoded to know what an Acrobat or a Dancer are.

Yeah, that's a long-term concern.  There's a line where an NPC has a death message "what about my children", unless that NPC is a mutant or a dog, where it changes to "what about my offspring".  There are a ton of fringe cases that delay the migration to data-driven development.

But for something like an entity's gender, you can use an enum as the data type.

bools should be used more often too, whenever a value can only be true/false. enums for anything with a small range of allowed values, then rather than using numeric codes, the values can be compared to the allowed enum choices, which makes code much easier to read.

There are a frightening number of times that chars/shorts are used in place of bools.  It's just those blasted cases where some have >= conditionals.  Three or four if statements, each one adds a value to the char, then at the end of it, it's treated as a bool anyway.  It was not designed with porting in mind.

[Starver]

(You people with your Short Billions. A billion meant something when I was young, unlike today when it's just trivially bigge than a million....  )

[misterTwister]

How long would you estimate that the c++ code can be adequately fixed before porting it to c#? Is there anyway I can currently help?

[IsaacG]

How long would you estimate that the c++ code can be adequately fixed before porting it to c#? Is there anyway I can currently help?

The trick is that I'm doing this in my free time.  It's difficult to estimate accurately, but months at least.

Helping is fairly straightforward at this time.
https://github.com/King-Drake/Liberal-Crime-Squad/blob/master/src/cursesAlternative.h

This is the cursesAlternative interface.  One of the main obstacles to porting LCS is its reliance on PDCurses.  cursesAlternative encapsulates all interactions with the PDCurses library.  Constructing an implementation of cursesAlternative in C# and/or Unity would help in the long term.

There are several instances of "char*" in cursesAlternative, but they can be treated as strings.

In theory, cursesAlternative is the only completely new code that needs to be written.  It shouldn't be hard, but it is likely to be time consuming.