Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Bug with dating and saving (fixed)  (Read 2437 times)

SlatersQuest

  • Bay Watcher
    • View Profile
Bug with dating and saving (fixed)
« on: June 07, 2014, 09:05:28 am »

Heads up:

While working on the Terra Vitae mod, I discovered (and fixed) a bug in the LCS code. The bug is fixed in the latest TV release (which will go up today - watch for it), but in the mean time you might want to make note of it yourself if for programming (or, if you're a developer, for the next official release of LCS). Here's the bug:


When saving, the (vanilla) game does not save the city where dates are taking place. This means that when the game is reloaded, the city is an unitialized variable. This is bad, because the game checks to see if a Liberal has moved city relative to xer date, and, if xe has, the date is cancelled. This bug fixes the saveload.cpp code that saves (and loads) the city of the date, thereby allowing the date to continue.
Logged

Lasica

  • Escaped Lunatic
    • View Profile
Re: Bug with dating and saving (fixed)
« Reply #1 on: June 07, 2014, 10:14:19 am »

So it's not a dating bug, but multicity dating bug... This mode has many bugs and actually doesn't change too much in game for now... But anyway, thanks for posting!
Logged

SlatersQuest

  • Bay Watcher
    • View Profile
Re: Bug with dating and saving (fixed)
« Reply #2 on: June 07, 2014, 06:41:18 pm »

No, it's a general bug. In classic mode, the city id is -1, but the date's loaded city is still an uninitialized variable.
Logged

Lasica

  • Escaped Lunatic
    • View Profile
Re: Bug with dating and saving (fixed)
« Reply #3 on: June 08, 2014, 01:43:09 am »

But this id - city id - is used only in multicity mode.
Logged

SlatersQuest

  • Bay Watcher
    • View Profile
Re: Bug with dating and saving (fixed)
« Reply #4 on: June 08, 2014, 09:46:45 pm »

It was introduced in the version including multicity mode, but it still causes a bug even when running in classic mode. The player characters' city ID# in classic mode is -1, as is the ID# of any newly acquired date. However, if you quit and reload the game, the date will have an unitialized variable for its city number, which could be -1, 1, 19341826, or anything else, and if it's not -1, then your Liberal will lose his or her date.
Logged

Lasica

  • Escaped Lunatic
    • View Profile
Re: Bug with dating and saving (fixed)
« Reply #5 on: June 11, 2014, 08:04:17 am »

Oh, in that case  thanks, I'll add a new issue to the github to fix it. I thought that I commenting m-city mode option is enough to disable it's harm. Silly of me.
Logged

Liberal Elitist

  • Bay Watcher
  • I'm more liberal than you are!
    • View Profile
    • The Liberal Crime Squad wiki
Re: Bug with dating and saving (fixed)
« Reply #6 on: June 23, 2014, 05:37:21 am »

I will get to work on this bug on the vanilla game on SourceForge... also I like your use of xe and xer... very Elite Liberal language.
Logged
The Liberal Crime Squad wiki is your friend.

Quote from: Lielac
Edit: Figured it out via a little bit of trial and error and oH MY GOD WHAT IS THIS MUSIC WHAT IS THIS MUSIC WHAT THE HECK IS IT SPACEBALLS MUSIC? WHATEVER IT IS IT IS MAGICAL

Liberal Elitist

  • Bay Watcher
  • I'm more liberal than you are!
    • View Profile
    • The Liberal Crime Squad wiki
Re: Bug with dating and saving (fixed)
« Reply #7 on: July 01, 2014, 10:17:24 pm »

This bug has been fixed in the vanilla game on SourceForge as of revision 772... along with a bunch of other changes. If you look at that changelog there is some other stuff that might be interesting, or maybe you won't find any of it interesting, I'm not sure...

One major change in this revision is the complete elimination of the itoa() function, which is not a good function to use, there are a variety of better alternatives and the game uses those now instead. itoa() had several problems: using it made the code longer since it required defining a char array, calling itoa(), and after that you could use the result on a third line... almost all the better alternatives are so succinct they get that 3 lines of code down to 1 line of code. Secondly it's a platform-specific function that comes as part of the Win32 API and Liberal Crime Squad included a portable version enabled by debug defines on non-Windows systems, a rather messy situation. Third it used char arrays a.k.a. C-strings, rather than std::strings, which are safer, and itoa() had no way of making sure the char arrays had enough space to fit all the characters, making it possible there might be buffer overrun errors if one of the char arrays is too short, so to compensate for this pretty much all the calls to itoa() used char arrays that were a bit bigger than any possible output of that function, wasting memory... plus std::strings are just much easier to work with, you can concatenate them using the + sign and check if they are equal by using the == operator, and they are designed to be safe and not crash programs the way C-strings do if you have an array index out of bounds. A function like itoa() makes sense if you are using plain old C rather than C++ on the Windows platform, but it does not make sense to use in C++, especially not with an object-oriented approach and targeting multiple platforms. So I got rid of it and replaced all occurrences of it with better, safer, more object-oriented, more concise code that is totally platform-neutral and doesn't require any debug defines. Anyone using a non-Windows system like Linux, Mac OS X, etc. should be especially pleased about this removal of a Windows-specific function. The changelog details a bunch of different alternatives to itoa() that can be used and in fact are being used in the code now.
Logged
The Liberal Crime Squad wiki is your friend.

Quote from: Lielac
Edit: Figured it out via a little bit of trial and error and oH MY GOD WHAT IS THIS MUSIC WHAT IS THIS MUSIC WHAT THE HECK IS IT SPACEBALLS MUSIC? WHATEVER IT IS IT IS MAGICAL

SlatersQuest

  • Bay Watcher
    • View Profile
Re: Bug with dating and saving (fixed)
« Reply #8 on: July 13, 2014, 03:47:18 pm »

Something else bug-like that I just discovered:

According to creatures.xml in the Art folder, the description for CREATURE_COP contains the following comment:
            <!-- Heart and wisdom hardcoded for negotiator and officer resp. -->

I just looked through the code, and can't find this...
Logged

Darael

  • Escaped Lunatic
    • View Profile
Re: Bug with dating and saving (fixed)
« Reply #9 on: July 20, 2014, 10:57:44 am »

Lots of lovely fixes in the new revisions; it's just a shame that something's not being set right with the character-sets, such that I get weird combinations of the characters D, M, and - instead of line-drawing characters.  I don't mean when viewing the code, either.  I mean when playing the game.

Come to think of it, the same issue is probably behind seeing two-character strings starting with ~ instead of non-ASCII characters in some names.
Logged

Liberal Elitist

  • Bay Watcher
  • I'm more liberal than you are!
    • View Profile
    • The Liberal Crime Squad wiki
Re: Bug with dating and saving (fixed)
« Reply #10 on: July 26, 2014, 09:43:15 pm »

Lots of lovely fixes in the new revisions; it's just a shame that something's not being set right with the character-sets, such that I get weird combinations of the characters D, M, and - instead of line-drawing characters.  I don't mean when viewing the code, either.  I mean when playing the game.

Come to think of it, the same issue is probably behind seeing two-character strings starting with ~ instead of non-ASCII characters in some names.

Darael, what operating system is this happening on? UNIX-based right? I don't think there are any problems drawing line-drawing characters on Windows. If there's a bug on UNIX-based systems like that, well I don't have any computers running Linux or a recent enough Mac OS X... The code for drawing special characters has some differences depending on operating system.

Oh wait, those weird combinations, I think they are the ASCII hack, which also seems to be enabled if Unicode is enabled, for some reason, rather than using the proper Unicode characters. Every character in Code Page 437 is also in Unicode too so it ought to be fixable, the only problem is I use Windows and I can't test the UNIX-based operating system code. And if I can't test it, then if I code in changes to it to try and "fix" things that I don't even know whether they are wrong or not, all I'd be able to tell afterwards is whether or not it compiled correctly. Actually not even that, because the UNIX-based operating system code is disabled by debug defines when compiling on Windows... same as the Windows code is disabled by debug defines when compiling on UNIX-based operating systems.

I think maybe the folks working on the GitHub fork, both of whom use Linux, they might've fixed this. Probably the solution is to look at that fork and the changes they've made, see if they've fixed any bugs not fixed in the SourceForge project, then merge all the bugfixes they've made back into the main SourceForge project.

Ah, and the 2-character strings starting with ~ in some names... that sounds like UTF-8, probably. It sounds like the text in those strings was correctly converted to UTF-8, but then the curses library incorrectly thought that each byte was a separate character, not realizing that UTF-8 can have multi-byte characters. There is some stuff in curses for multi-byte characters but it's really complicated... I think probably the problem is incorrect usage of the curses library. Curses has a lot of quirks, getting stuff to work correctly on it is sometimes a matter of trial and error. If you look at the PDCurses project for instance they have several different variants available for download, but only one of the .DLLs they have produces correct output with Liberal Crime Squad on Windows, the others all display incorrect characters. Also UTF-8 is inconsistently multi-byte... traditional ASCII characters in the 32-126 range such as letters that don't have accents/umlauts, numerical digits, and common punctuation is all encoded as single byte characters in the exact same encoding as Code Page 437 and the vast majority of other character encodings. The characters that can have differences between code pages are characters 0-31 (originally considered control characters that couldn't be displayed, until IBM decided to make them also be display characters too), character 127 (also a control character, and typically implemented as this 5-sided symbol that looks like a house, quite an oddity), and characters 128-255 (the "Extended ASCII" range that every code page is allowed to define differently). But there are differences between operating systems (Windows console mode is in DOS code pages whereas UNIX-based operating systems typically have UTF-8 in console mode), differences between curses implementations (not just between PDcurses and ncurses, but there are multiple different implementations of both of those that do things differently), and differences between code pages (the 2 main ones we are concerned with being Code Page 437 and UTF-8). Basically, LCS on Windows uses PDCurses and Code Page 437, but on UNIX-based systems uses ncurses and UTF-8. But UTF-8 has all the characters in Code Page 437 and many, many, many more. So theoretically any Code Page 437 character ought to be able to display fine on both systems, WITHOUT using an ASCII-only hack to limit it to the standard display characters 32-126 that are the same in all character sets except for oddities like EBDIC... except this requires both implementations to, uhm, be fully implemented and work correctly. Implementing it for Code Page 437 on Windows is straightforward... simply output each character as is. It's already in the right encoding, and each character is 1 byte. Easy. Implementing it in UTF-8 on a UNIX-based system is harder... you need a multi-byte curses implementation that works with UTF-8, and for each Code Page 437 character, you replace it with the corresponding UTF-8 character before outputting it on the screen. From what I've seen of the code, what it ACTUALLY does on UNIX-based systems is replace extended characters with basic ASCII characters in the 32-126 range... and only if you use translateGraphicsChar(). This appears to be the WRONG thing to do... the correct thing would be to translate into the corresponding UTF-8 character. But then this would require a multi-byte curses implementation. And the multi-byte extensions to curses, I don't think they are standardized across different implementations. PDcurses and ncurses do some things differently.

The actual code to fix this probably wouldn't be that complicated, and probably would only require slight modifications to the existing code. The hard part is figuring out WHAT that code IS, through trial and error. Even if it's just a small amount of code, there are a large number of different possibilities of what it could be. And this can only be done by testing on the same type of system you want to get it to work correctly on... namely, UNIX-based. And since I'm operating on Windows it would be difficult for me to fix it, although I think there might be a way. Specifically I am thinking, Cygwin provides a UNIX-like environment on Windows, and perhaps I could try getting Liberal Crime Squad running in Cygwin on Windows and instead of having it detect the operating system as Windows and follow the WIN32 defines, it would have WIN32 not be defined and think of the operating system as UNIX-based, and have the POSIX API calls it needs all implemented by Cygwin or MinGW. And instead of linking it with PDCurses I'd link it with ncurses. I just need to make sure I use a UTF-8 based console for Cygwin and find a way to run Liberal Crime Squad in that, rather than in Windows's native console that uses DOS code pages such as Code Page 437.

Or I could actually install Linux on a computer and do things directly in Linux. That is the simplest and most logical solution, but I am very low in hard disk space and so partitioning isn't really an option. Maybe if I went out and bought a larger hard drive I could do that.

Well hopefully the developers of that fork on GitHub have fixed that problem with display of extended characters on UNIX-based systems and I can look thru the changes they made to find the fix and merge it into the code on SourceForge. But sifting through all the stuff they've done would probably be quite a time-consuming chore too...

Anyway, if you are having problems with display of incorrect characters on the WINDOWS operating system, with current revisions, that would be VERY surprising to me... but if it is on UNIX-based operating systems that is not at all surprising and exactly what I would expect based on what I've seen of Liberal Crime Squad's source code and how it currently deals with this... right now I don't quite have the capability to solve this yet. I will see what I can do... but for other people out there, yourself included, I encourage you to try and fix the problem if you're on a UNIX-based system and know how to code, since you can actually test whether or not your attempts to fix things work. I will hopefully also try to fix it. I am not sure whether I will be able to or not though.

Oh, we might need to use something called ICU to fix this. International Components for Unicode. C/C++ libraries for dealing with Unicode, code page conversion, and so on. Liberal Crime Squad has strings that are in Code Page 437. The ICU project has libraries that can convert that to and from Unicode strings in all the various Unicode encodings. But they also have a nice little chart here with the various codes. Maybe I can use that. Ah, and it seems they reserve character 127 to indicate an invalid character that couldn't be converted, rather than using it for the house symbol like in the original Code Page 437. So if I use the numbers from their chart that is the one I'd have to change... its proper Unicode value is 0x2302 (hexadecimal... in decimal it's 8962). Meh... maybe it's easier just to use their library. But not the whole thing, we only need the code page conversion part of the ICU library. And apparently the ICU library is an open source project by IBM. But its license is compatible with the GNU GPL, I looked at it, it's just like a BSD license, it doesn't have any terms that would go against the GNU GPL, it's a simple permissive license that allows it to be used in free open source software as well as proprietary closed source software with hardly any restrictions, as explained here. So that means we are free to use it, as long as we don't remove the copyright/license notices in its source code files. I think something like this is probably necessary since I don't think the curses library does any code page conversion, it just outputs (or inputs) text in whatever code page your console is set up to use, at least if it's in single-byte character set mode, and if you have a multi-byte version of curses that uses UTF-8, it will expect strings and characters to already be in UTF-8, which means we will have to do the conversion from Code Page 437 first.

Then again Liberal Crime Squad already has some code for code page conversion itself, maybe we could just enhance that and use it, since there's only 2 different code pages we're using and we're only converting in one direction, so including this whole ICU library might be overkill. All it is is a simple substitution using a lookup table (an array) with 256 entries. We simply look up the entry based on the Code Page 437 byte code (from 0-255) in the array, and it'll have the UTF-8 code to use (although the UTF-8 code could be 1, 2, or 3 bytes, depending on which Code Page 437 character we are using). Or maybe we can use UTF-16, since that's actually a bit simpler to use, and has all the characters we need (they're all in the 65,536 character Unicode B.M.P. or Basic Multilingual Plane used by UTF-16, and each character is exactly 2 bytes). In either case the data can be stored in a C++ int, which is at least 32 bits according to the C++98 standard, which equals at least 4 bytes, and the most that UTF-8 could use for a character in the B.M.P. is 3 bytes, and 3 is less than 4. On some systems a C++ int is 64 bits or 8 bytes but that is also fine since 3 is less than 8 also. Thus a simple array of 256 ints is all we need for the conversion. OK, on older 16-bit systems, ints were only 16-bit, but whatever... we can use long instead of int... on 32 and 64-bit systems long and int are usually the same, and on 16-bit systems long was usually 32 bit while int was 16 bit. So an array of 256 longs, used for the conversion. We already have an array like that in the program but it's used to convert things to plain 7-bit ASCII instead, for the ASCII hack. So we just need a 2nd array like that, for Unicode... and maybe some other stuff needs to be done too.
Logged
The Liberal Crime Squad wiki is your friend.

Quote from: Lielac
Edit: Figured it out via a little bit of trial and error and oH MY GOD WHAT IS THIS MUSIC WHAT IS THIS MUSIC WHAT THE HECK IS IT SPACEBALLS MUSIC? WHATEVER IT IS IT IS MAGICAL

SuicideJunkie

  • Bay Watcher
    • View Profile
Re: Bug with dating and saving (fixed)
« Reply #11 on: July 28, 2014, 12:47:54 am »

Quote
plus std::strings are just much easier to work with
Indeed.  One problem is that if you want to start with a string literal and append anything, it doesn't compile so well.
I've taken to defining a
Code: [Select]
string s = ""; and then prepending it to the constant, eg:
Code: [Select]
addstr(s+" liberates " +cr.name);Its been really convenient to do that, other than having to declare s, but if there's an even better way I'd like to know.


In regards to testing on linux?  I recommend grabbing a copy of virtualbox and a fresh ISO of any flavour linux you like.
I have a virtual linux box for LCS on my netbook which already runs linux.  The nice part of a vbox for dev work, is that you can shut down your host PC, and leave the virtual one up.  All the Undo buffers and open files are then still there when you come back to it.
Logged

Liberal Elitist

  • Bay Watcher
  • I'm more liberal than you are!
    • View Profile
    • The Liberal Crime Squad wiki
Re: Bug with dating and saving (fixed)
« Reply #12 on: August 03, 2014, 01:41:43 am »

Update: it appears Liberal Crime Squad already has code to convert Code Page 437 characters to Unicode's UTF-8 encoding, as part of the translateGraphicsChar() and related functions; however right now translateGraphicsChar() is only used on special characters in the Curses movies (i.e., new cable news anchor, failed partial birth abortion on TV, show about lifestyles of the rich and famous, video of black man getting beaten by LAPD just like Rodney King, etc.) as well as special characters in newspaper fonts and newspaper graphics (like the graphic about the wacky CEO who owns slaves in another country or doesn't know what his company does or whatever, or the graphic about people poisoned by genetically modified food, etc.). The code to output that in Unicode seems to already be fully implemented.

But code to output regular strings and characters in Unicode doesn't seem to be implemented that way. I guess the solution is, just as there is an addchar() function to replace addch() because of addch()'s mishandling of characters (which now that I think of it is probably because C++ usually uses signed characters from -128 to 127 instead of 0 to 255, and then addch() takes an int as input, so extended characters, instead of being in the 128-255 range they ought to be in, are mistakenly in the -128 to -1 range, so instead of the addchar() function we COULD have just typecast the chars as "unsigned char"), well just like we have the addchar() wrapper function to replace addch() and mvaddchar() to replace mvaddch(), we need ones to replace addstr() and mvaddstr(). They would loop thru each character in a string and output it, using translateGraphicsChar(). And addchar() could be changed to also use translateGraphicsChar(). So then ALL text output in the entire program would be consistently filtered thru translateGraphicsChar().

The other thing to do would be to finish implementing the conversion tables, that have a lot of characters commented out... the UTF-8 conversion table actually has all the characters listed but many are commented out. And it seems translateGraphicsChar() currently, for characters 0-31, outputs UTF-8 characters corresponding to those characters interpreted as control characters rather than interpreted as display characters, which is wrong... it should output everything as a display character. The comments say that the conversion tables ought to include corresponding standard ASCII characters for the ASCII hack too, for every character I uncomment and enable. So, I'll need to enable all 256 characters in both conversion tables... the UTF-8 one has proper info already there for all of them, but the ASCII hack one needs to have someone come up with corresponding characters for each one. That's pretty simple for a lot of extended characters. The standard ASCII equivalent of a letter with an accute accent/grave accent/umlaut/circumflex over it is simply that letter WITHOUT any accent/umlaut/etc. over it. There's other characters like various symbols, block characters, line-drawing characters, etc. that don't really have corresponding ASCII characters... the standard ASCII hack way to do line-drawing characters is "-" for a horizontal line, "|" for a vertical line, and "+" for anything else. And most Greek letters have regular letters they look like... and the German double S looks similar to a capital B, and the Japanese yen currency looks similar to a Y, etc... those are all in Code Page 437... I plan on implementing entire conversion tables for it, for both standard ASCII and for UTF-8, and then getting translateGraphicsChar() used on all outputted characters and strings, since it is the function that takes care of this in the current code, it just isn't used widely enough.

But obviously this analysis here is slightly simplistic and there might be some bumps along the way to fully implementing this, but I'm sure it's doable... someone else recently did a fix to improve extended character display that involves translateGraphicsChar() on Linux... that fix actually deals with how ncurses and PDcurses display colors differently... basically PDcurses and ncurses have the colors red and blue swapped... and then colors that have red but not blue or blue but not red get swapped too... like yellow (red+green) is swapped with cyan (blue+green). This is because one of them is RGB (red bit, green bit, blue bit) and the other is BGR (blue bit, green bit, red bit)... basically the same problem as the difference between big-endian and little-endian CPU architectures for accessing bits. But that has been fixed now, which is very nice, I forget who fixed it, probably either nickdumas or blomkvist, I could check the changelogs to see but it's not that important, both of them have made plenty of good contributions lately, regardless.

So right now addchar() is a wrapper that replaces addch() calls with addstr() calls... once I finish making translateGraphicsChar() get called on all characters including ones in strings, things will be the other way around, and everything will use addch() (addch() takes ints for each character, thus supporting multibyte character encodings like UTF-8, whereas addstr() takes chars for each character, with each 8-bit char assumed to represent a single character). So instead of replacing addch() calls with addstr() calls we'll replace addstr() calls with addch() calls, since it seems addch() is what supports Unicode best... I was just having some trouble with addch() due to the typecasting thing, because if you call it on a char it'll think of extended characters as being in the -128 to -1 range instead of the 128 to 255 range, since you need to typecast it to an unsigned type FIRST before calling addch()... this is not any problem with addch(), I just misunderestimated (to use a word George W. Bush coined) that function and thought something was wrong with it, when actually the only thing that was wrong was my failure to properly typecast the input to it as unsigned. Ah and a SPECIAL oddity of C++ is, a regular char without the signed or unsigned word before it is typically a two's-complement signed integer between -128 and 127, but a signed char declared as a signed char is typically a one's complement signed integer between -127 and 127... one's complement signed numbers are terrible, I don't know why they exist, signed numbers should always be two's complement, whoever thought up in the specification that they should be one's complement was either some wacko with terrible ideas, or was forced to do this to maintain C++'s backwards compatibility with the original vanilla C language from the 1970s back in the Dark Ages of computing. I am thinking the reason for this absurdity is backwards compatibility with code from the 1970s so it would still compile correctly in C++ without modifications. Apparently this absurdity is finally fixed, not in C++11, but in C++14... in C++14 finally signed char's are two's complement instead of one's complement, according to the fancy chart at this URL: http://en.cppreference.com/w/cpp/language/types. They should've had it been that way in the original C++98 standard, I dunno what those dudes were smoking when they came up with that one's complement nonsense. One's complement is an epic fail compared to two's complement... more complicated to implement, you have one less number, and you have TWO zeroes (positive zero and negative zero) which are distinct, separate numbers. Utterly ridiculous. There can be only one zero, to think otherwise is madness... although apparently the ISO standard implementation of floating-point numbers also has both positive and negative zero... how did THAT get approved? And then, how does the == operator work... does the expression (+0 == -0) return true or false when positive and negative zero are implemented as different numbers? It seems like that would vary depending on implementation... in other words a recipe for disaster. And then stuff like "int c = some number; if(c) {do this} else {do that}" might not work correctly... conversion from integer to boolean types should return true for nonzero numbers and false for zero, but if there's more than one zero, than does it return false for BOTH zeroes or just ONE of them? Again, something that would vary depending on implementation and another recipe for disaster. That's why one's complement is the most terrible thing ever, and the fact that the C++ standard type "unsigned char" uses it up until the C++14 specification is also terrible. Now in C/C++, C-strings are "null"-terminated (actually terminated with a zero). But if the unsigned char type has both positive and negative zero, there would be TWO possible "nulls" to terminate with... but maybe one of them might work and the other might not... and if you use the wrong one you might get a string that goes on longer than the space you allocated for it and leads to an array index out of bounds and crashes the program or causes undefined behavior. So things go from terrible to super-ultra-mega-terrible. The good news, if you can call it that, is that a char array or char* pointer without "unsigned" before it is implemented (usually) as a two's complement signed number, and occasionally some compilers implement it as an unsigned number, since the language standard doesn't specify which to use for the standard "char" type and leaves it up to the compiler implementation to decide (another epic failure in the original C++98 language standard). So no wonder so many programs written in C/C++ might work with one compiler on one platform but not another compiler on another platform, with such shoddiness in the standards themselves. That kinda stuff is why C++03 was necessary (it didn't change the actual language for programmers, just specified standards for compiler behavior to be more uniform). At least they finally fixed it this year with the C++14 standard, although it'll be years before most C++ software uses that, most C++ software still uses C++98/03 rather than C++11, including Liberal Crime Squad... there isn't a single compiler out there that implements C++14 even remotely fully, although at least with C++11, GNU's GCC compiler has implemented all of the core features of it, and Microsoft Visual C++ has implemented more than half of the core features in the latest version (kinda slow given that standard is from 3 years ago, you'd think Microsoft with its billions of dollars and thousands of talented genius programmers from top universities would be able to get the full C++11 specification implemented faster in their compiler, but the reverse is true). Maybe Microsoft has some legitimate reason for it (I guess they like to keep their compiler very optimized and don't want bugs in it, and while they could probably easily implement the entire C++11 specification in a shoddy way, maybe they are taking the time to do it as well as possible, or something like that... just kidding, I think they are just too lazy to implement it at a reasonable speed since they have other priorities, like fixing the things people don't like about Windows so that everyone will want to use Windows again, even on tablets, rather than iOS or Android, as well as diversifying what they make money on so they're less dependent on Windows).

But getting back on topic, curses functions that deal with single characters use signed integers rather than chars, which allows for storing multiple bytes inside that integer, and allows support for Unicode in which characters often take up more than 1 byte, and this is the solution which will allow for extended characters to work on Linux and Mac OS X, combined with finishing the conversion tables used by translateGraphicsChar(). So I oughta be able to get this whole thing fixed up just fine just by having translateGraphicsChar() do conversions on all 256 characters and having it used on every character output to the screen by the entire program, thru the use of wrapper functions. Those wrapper functions also will benefit the program by making it less curses-specific and easier to integrate with other APIs such as libtcod, etc. The single functions enter_name() and setcolor() are already excellent wrapper functions that would be easy to add support for other non-curses APIs like libtcod to. Then debug defines and such could switch between compiling for curses and compiling for libtcod, and it would support both. The libtcod version would look a bit nicer, while the curses version would continue to retain compatibility with traditional consoles (including DOS, which can run Win32 versions of Liberal Crime Squad or other Win32 Console Applications using the HX DOS Extender... and this DOS compatibility extends to DOS emulators like DOSBox, allowing the game to easily run on any platform DOSBox can run on... this includes DOSBox Turbo for Android, and allows you to play the Win32 version of Liberal Crime Squad, unmodified, on Android thru DOSBox Turbo + HX DOS Extender.) There's also a native Android version of Liberal Crime Squad too, which is a port written in Java, which has a different user interface, but retaining curses console support allows the Windows version to work on DOS or DOSBox and be emulated on anything. Or it can be emulated using Wine on other platforms. Or directly compiled for other platforms... it's good for people to have as many options as possible how to compile/build/run/port this game... on Linux or Mac OS X you could have the native-compiled POSIX-compliant version, the Win32 version running in Wine, and Win32 version running in DOSBox with help from HX DOS Extender all running side-by-side, and see whether there are differences or bugs that appear in one but not the other, as one example of how this is actually useful for programming/debugging the game. This would, for example, be useful in debugging problems with display of extended characters. And if a libtcod version is ever made, it could run side-by-side with the curses version to make sure they both work the same (other than a few minor libtcod-specific enhancements that would probably be implemented to make the game look nicer, which you wouldn't see in the curses version). It'd be sorta like how NetHack has multiple interfaces, both text and graphical (although obviously we can't use any NetHack code since the NetHack GPL and GNU GPL are incompatible in both directions).

But yeah, we can do this... already halfway there, with it implemented for curses movies, newspaper headlines, and newspaper graphics.
Logged
The Liberal Crime Squad wiki is your friend.

Quote from: Lielac
Edit: Figured it out via a little bit of trial and error and oH MY GOD WHAT IS THIS MUSIC WHAT IS THIS MUSIC WHAT THE HECK IS IT SPACEBALLS MUSIC? WHATEVER IT IS IT IS MAGICAL

Jonathan S. Fox

  • Bay Watcher
    • View Profile
    • http://www.jonathansfox.com/
Re: Bug with dating and saving (fixed)
« Reply #13 on: August 03, 2014, 05:03:46 am »

[snip]

Sounds like it's mostly research at this point, if I understood correctly -- is this something you're going to try to get working, or would you need to be on linux/osx to do any serious work with it?

Also, I don't want to be rude, but you do tend to ramble on Liberal Elitist, and people often skim or skip lengthy comments like those you write. I don't always mind spending five or ten minutes hearing about your research and thought process, but sometimes I just want to hear your conclusions and get the important parts.

Will you be extra sure that the important points of your longer comments are included in the first or last paragraph when you write long posts, similar to what you do with commit messages? That way, if I or others don't feel we have the time to read the whole thing, we can still skim the summary. I don't want you to be excluded from a discussion because you've written too much for people to follow!
Logged

Liberal Elitist

  • Bay Watcher
  • I'm more liberal than you are!
    • View Profile
    • The Liberal Crime Squad wiki
Re: Bug with dating and saving (fixed)
« Reply #14 on: August 04, 2014, 02:55:02 am »

Sorry, I have a bad habit of writing stuff too long. But I have good news, everyone! Everything I talked about in long posts in this thread is now done, implemented, finished, committed in revision 823! It's not just theoretical, I'm not just researching it, I spent plenty of time and energy on it and got it done! Yeah, it's done, implemented, working fine... check out the source code and changes here.

And this message is nice and short!
« Last Edit: August 04, 2014, 05:18:03 am by Liberal Elitist »
Logged
The Liberal Crime Squad wiki is your friend.

Quote from: Lielac
Edit: Figured it out via a little bit of trial and error and oH MY GOD WHAT IS THIS MUSIC WHAT IS THIS MUSIC WHAT THE HECK IS IT SPACEBALLS MUSIC? WHATEVER IT IS IT IS MAGICAL