[00:54:05] --- Dark-Star|afk is now known as Dark-Star
[00:54:14] <-- Dark-Star has left #exult ()
[03:13:34] <-- Fingolfin has left IRC ("42")
[07:00:32] --> Darke has joined #exult
[07:00:32] --- ChanServ gives channel operator status to Darke
[08:10:10] --> ShadwChsr has joined #Exult
[08:10:11] <ShadwChsr> hi :)
[08:12:22] <ShadwChsr> help!
[08:12:22] <ShadwChsr> :)
[08:15:22] <Darke> Hi! Err... help?
[08:17:12] <ShadwChsr> :)
[08:17:23] <ShadwChsr> FStreams.. evil... arggg
[08:17:26] <ShadwChsr> ;)
[08:18:01] <ShadwChsr> trying to read unicode data from an fstream.. and its not reading the data, instead it fills the array with the exact same value :P
[08:18:11] <ShadwChsr> and i cant find any usefull tutorials
[08:18:29] <ShadwChsr> char *temp2 = new char;
[08:18:37] <Darke> Eh? What are you using to read the data?
[08:18:44] <ShadwChsr> dataStream->get(temp2,32);
[08:19:04] <ShadwChsr> first off my compiler wont even show the contents of "temp2" (i assume because its a pointer?)
[08:19:36] <Darke> Hmm... that 'looks' correct. I'll just grab my reference and find a lightswitch. *grin*
[08:19:40] <ShadwChsr> does that look right? or should I declare it as a wchar_t instead, and typecast it to a char? :)
[08:20:24] <Darke> Hmm... wchat_t might make it 'work'.
[08:21:19] <ShadwChsr> Here's my problem - my resource editor is written in C# - and C# "only"(sorta) supports unicode
[08:21:41] <ShadwChsr> so it made more sense to save it that way, also for other languages later
[08:22:05] <ShadwChsr> so I want to read that data into C++.... and convert it to a standard "string"
[08:23:02] <ShadwChsr> now, if I learned this right:
[08:23:18] <ShadwChsr> sometype *somename; declares a pointer of type "sometype"
[08:23:43] <ShadwChsr> somename = &someothervar; makes somename point to someothervar
[08:23:54] <Darke> Might also want to use a wfstream too. If reading, a wifstream in specific. *grin*
[08:24:06] <ShadwChsr> someothervar2 = *somename; puts the value pointed at by somename into someothervar2
[08:24:09] <ShadwChsr> is that right? :)
[08:24:24] <Darke> Yep. *grin*
[08:24:28] <ShadwChsr> woohoo
[08:24:29] <ShadwChsr> ;)
[08:24:39] <ShadwChsr> ok what confuses me is when arrays are thrown into it
[08:24:43] <ShadwChsr> lemme see if this is right...
[08:25:01] <ShadwChsr> char *whatever - array of 10 pointers to 1 char each
[08:25:21] <ShadwChsr> char *whatever = new char - pointer to an array of 10 chars
[08:25:23] <ShadwChsr> is that right? :)
[08:27:55] <Darke> Umm... yeah. I think. *grin* I'm the weirdo that uses std::strings rather then variable arrays of characters though, so I can't remember the last time I used one. *grin*
[08:28:12] <ShadwChsr> I like std::strings too :)
[08:28:34] <ShadwChsr> however, fstream forces me to use char arrays - so I need to do the conversion with those, then toss it into a std::string :)
[08:28:53] <ShadwChsr> any idea how I can convert from unicode to ascii?
[08:29:14] <ShadwChsr> without using windows api? :)
[08:33:11] * Darke suggests using `getline` instead. The global getline function accepts a std::string.
[08:33:22] <Darke> Not a clue. *grin*
[08:33:45] <ShadwChsr> getline assumes a terminator though, when my file format uses fixed length strings :(
[08:34:15] <Darke> Are you ever expecting a '\0' or something in the string?
[08:34:21] <ShadwChsr> yes
[08:34:30] <ShadwChsr> in at least one case
[08:34:43] <ShadwChsr> and the strings arent \0 terminated
[08:35:32] <Darke> Do they have \n's in the middle of them? Or is this just a string of technically any binary data?
[08:36:14] <ShadwChsr> well, in most cases (except for one) it would be a normal string of characters, which /may/ have a line break
[08:36:52] * Darke ahhs and ponders.
[08:37:34] <ShadwChsr> what I want to do is take a fixed length unicode string and toss it into a normal std:;string
[08:38:13] <ShadwChsr> I assume the unicode string is padded with \0 for the values that don't exist, ie/ a 1 character string stored in a file which has a 10 character fixed length size
[08:39:13] * Darke ahhs.
[08:39:34] <Darke> A bit of hack, but maybe something like:
[08:39:57] <Darke> getline(input, str, 32, '\0');
[08:40:18] <Darke> unsigned int i=str.size();
[08:40:35] <Darke> while(size-->0) input.pop();
[08:40:43] <Darke> s/int i/int size/
[08:41:01] <ShadwChsr> wouldn't getline expect a single byte char string?
[08:41:31] <Darke> Not if you're using wifstreams.
[08:41:51] <ShadwChsr> for some reason, "get" returns 0 for the first array index, then -51 for all the others
[08:42:45] <Darke> getline just uses the external interface to access istreams, so if you're using wifstreams it should Just Work(tm).
[08:42:57] * Darke blinks. That's just weird.
[08:44:44] <ShadwChsr> hmm lemme hex edit the actual file
[08:46:00] <ShadwChsr> 6D 2E 43 68 61 72 ...
[08:46:42] <ShadwChsr> hmmmm
[08:46:44] <ShadwChsr> shows up as
[08:47:05] <ShadwChsr> '\0' 'G' 'R' 'F' '\0'
[08:47:24] <ShadwChsr> thats the file header, 5 characters. However, C# documentation says a char is 2 byte.. so shouldn't that be 10 chars? Hmmmmm
[08:47:48] <ShadwChsr> I guess my C# write routine is saving single byte after all, because my string data is showing up as ASCII, not unicode :P
[08:48:44] * Darke nods. Looks like it.
[08:49:02] <ShadwChsr> In C# i call BW.Write(FileIdent);
[08:49:17] <ShadwChsr> FileIdent is an array (0..4) of type char
[08:49:28] <ShadwChsr> C# documentation of "char" says it is a single unicode character
[08:49:38] <ShadwChsr> so wouldn't the binary writer store the actual data - two bytes?
[08:49:50] <ShadwChsr> Weird, must be a .NET bug.. or perhaps in the documentation ;)
[08:50:02] <Darke> Don't know. Don't do .NET. *grin*
[08:50:29] <ShadwChsr> The char keyword is used to declare a Unicode character in the range indicated in the following table. Unicode characters are 16-bit characters used to represent most of the known written languages throughout the world.
[08:51:12] <ShadwChsr> Writes a Unicode character to the current stream and advances the current position of the stream in accordance with the Encoding used and the specific characters being written to the stream.
[08:51:18] <ShadwChsr> [C#] public virtual void Write(char);
[08:51:25] <ShadwChsr> ahhhhhh encoding used ahhhhhhhhhhhhhhhhhhhh
[08:51:56] <ShadwChsr> [C#] public BinaryWriter(Stream, Encoding);
[08:52:06] <ShadwChsr> System.Text.Encoding
[08:52:06] <ShadwChsr> System.Text.ASCIIEncoding
[08:52:06] <ShadwChsr> System.Text.UnicodeEncoding
[08:52:06] <ShadwChsr> System.Text.UTF7Encoding
[08:52:06] <ShadwChsr> System.Text.UTF8Encoding
[08:52:36] <ShadwChsr> bingo... public BinaryWriter(); (which i'm using) must default to "ASCIIEncoding"
[08:52:58] <ShadwChsr> hehehehehe.. I guess that means no japaneese ports of my game, but at least it makes my C++ code alot simpler ;-)
[08:54:18] <Darke> More then likely, yes. *grin*
[08:54:22] <ShadwChsr> Though, still doesnt explain why I'm getting -51 :P
[08:54:56] <ShadwChsr> char temp* = new char;
[08:54:57] <Darke> Who knows. Try it with 'good' data to see if it fixes itself. *grin*
[08:55:12] <ShadwChsr> dataStream->get(temp,5);
[08:55:28] <ShadwChsr> char temp2 = temp;
[08:55:41] <ShadwChsr> Shouldn't "temp2" equal the second character?
[08:55:53] <Darke> Yes it should.
[08:55:54] <ShadwChsr> It *must* be a "stupid pointer bug" thanks to me ;P
[08:56:14] <ShadwChsr> i betcha it's returning the first 8 bytes of the memory address or something
[08:56:19] <ShadwChsr> err 8 bits
[09:23:28] <ShadwChsr> ooooohhhh wait
[09:23:32] <ShadwChsr> dataStream = new fstream(srcFilePath.data(),ios::in | ios::binary);
[09:23:37] <ShadwChsr> should that be || or | ?
[09:23:51] <ShadwChsr> if ios::binary wasn't going through right, it could cause mega trouble
[09:24:07] <ShadwChsr> and does "in" mean writing or reading?
[09:24:11] <ShadwChsr> I think I have that backwards...
[09:30:31] <-- Darke has left IRC (Remote closed the connection)
[09:37:39] --> Darke has joined #exult
[09:37:59] --- ChanServ gives channel operator status to Darke
[09:46:22] --> slacked has joined #exult
[10:06:01] --> Klown has joined #exult
[10:24:23] --> wjp has joined #exult
[10:24:24] --- ChanServ gives channel operator status to wjp
[10:24:39] <wjp> ShadwChsr: char *whatever = new char <-- won't compile
[10:24:49] <wjp> (or shouldn't, anyway)
[10:25:13] <ShadwChsr> char *whatever = new char;
[10:25:14] <wjp> char* whatever; <-- same
[10:25:16] <wjp> right
[10:25:55] <ShadwChsr> char* is the same? I always get compiler errors passing it into a parameter that expects "char*"
[10:26:19] <wjp> char* gives a parse error I think
[10:26:36] <wjp> if anything it would be a pointer pointing to a pointer pointing to 10 chars
[10:26:57] <ShadwChsr> yeah
[10:27:06] <ShadwChsr> any idea why my fstream wont work?
[10:27:30] <ShadwChsr> everything im doing looks correct (even checked a few tutorials and sample code), but the data in the char array seems wacky
[10:27:43] <ShadwChsr> maybe its just the way i'm trying to get the data out of the array
[10:27:45] <ShadwChsr> dont know
[10:27:55] <wjp> how do you get the data out of the array, then? :-)
[10:28:17] <ShadwChsr> well, tried using the debugger locals window, that just gave me nothing
[10:28:42] <ShadwChsr> then I tried char test = charpointerarray;
[10:28:59] <ShadwChsr> but test ALWAYS equals the same weird number, -47 or something like that
[10:29:14] <wjp> hm, weird
[10:31:00] <ShadwChsr> yeah :P
[10:31:12] <ShadwChsr> that code should work, right?
[10:31:24] <ShadwChsr> char *test = new char;
[10:31:29] <ShadwChsr> char test2 = test;
[10:31:44] <ShadwChsr> that should return the first character stored in test, not something wacky like a memory address? :)
[10:31:47] <wjp> yes
[10:31:58] <ShadwChsr> dataStream = new fstream(srcFilePath.data(),ios::in | ios::binary);
[10:32:01] <ShadwChsr> does that look right?
[10:32:57] * wjp nods
[10:33:47] <wjp> are you sure srcFilePath.data() is valid?
[10:33:57] <wjp> and are you sure it opened the file properly?
[10:34:19] <ShadwChsr> hmmm not sure it opened the file properly, now that you mentioned it
[10:34:25] <ShadwChsr> wouldn't it throw an error though?
[10:34:31] <ShadwChsr> srcFilePath.data() is valid
[10:34:44] <ShadwChsr> ResourceFile::ResourceFile(string srcFilePath)
[10:34:58] <wjp> you should probably check dataStream->good()
[10:35:08] <ShadwChsr> Good call ;)
[10:37:07] <ShadwChsr> nope, not good ;)
[10:43:16] <wjp> the fstream wasn't good or the suggestion wasn't good? :-)
[10:43:39] <ShadwChsr> fstream->good() == false
[10:43:52] <ShadwChsr> the filename is a relative path, just "buildings.grf"
[10:44:13] <wjp> are you sure it's zero-terminated? and you're starting the program in the right directory?
[10:44:16] <ShadwChsr> this is win32 - do I use a complete path (C:\buildings.grf), or something weird like "./buildings.grf"?
[10:44:32] <ShadwChsr> GO
[10:44:33] * Darke also suggests wfstream if you're dealing with wide chars. *grin*
[10:44:34] <ShadwChsr> good point
[10:44:49] <ShadwChsr> no more widechars, remember? C# is saving it as ASCII :-)
[10:44:52] <ShadwChsr> <hits forhead>
[10:45:03] <ShadwChsr> I'm such a stupid, stupid person
[10:45:19] <ShadwChsr> Ugh I got all boggled with C++ when it was an easy non coding problem
[10:45:27] <ShadwChsr> I'm passing it the filename instead of the path
[10:45:29] <ShadwChsr> <sigh> :)
[10:45:41] * Darke ahhs, yes that's right. *grin*
[10:45:57] <wjp> ?
[10:46:53] <Darke> No more wide char stuff. *grin*
[10:47:28] <wjp> passing it a plain file name should work assuming you're in the right directory
[10:47:52] <ShadwChsr> Yeah, but my game resource files are in a subdir :)
[10:49:34] <wjp> ah, that would do it :-)
[11:27:51] <wjp> gtg
[11:27:52] <-- Klown has left IRC (Read error: 104 (Connection reset by peer))
[11:27:53] <-- wjp has left IRC ("gtg")
[11:32:43] <-- slacked has left IRC ("Client Exiting")
[11:34:04] <-- ShadwChsr has left IRC ()
[19:09:17] --> exultbot has joined #exult
[19:09:17] --- Topic for #exult is: Exult: An open-source engine for Ultima 7: The Black Gate and The Serpent Isle; Exult 1.0 has been released! http://exult.sf.net/
[19:09:17] --- Topic for #exult set by wjp at Sun Dec 1 13:38:03 2002
[19:16:37] <Fingolfin> hehe
[19:16:44] <Fingolfin> he cam back to tell you that
[19:19:39] <wjp> :-)
[19:19:58] <wjp> maybe I should have xchat tell me exultbot is missing on entering #exult
[21:49:39] --> rixa_ has joined #exult
[21:53:29] <rixa_> I have a SoundBlaster Live!, and I use the ALSA driver on Linux. I don't know much about MIDI, but I know that timidity consumes a healthy chunk of my cpu power. SB Live! has some kind of midi support, and pmidi plays midi songs with neglible cpu overhead. Is this usable in exult?
[21:55:30] <wjp> hi
[21:56:59] <wjp> hm, it should be
[21:57:11] <wjp> we have a midi driver that uses playmide
[21:58:29] <wjp> s/playmide/playmidi/
[21:58:58] <wjp> I don't know pmidi, but it should be easy to convert the playmidi driver to use pmidi if it's a commandline tool
[21:59:38] <rixa_> It's a commandline tool yes. I think playmidi works as well, through OSS emulation (pmidi is an ALSA app)
[22:00:55] <rixa_> yes, it works.
[22:02:11] <wjp> I think if you disable timidity support it should automatically use playmidi
[22:02:11] <rixa_> what is involved in getting exult to use either? I glanced through the documentation searching for MIDI, but it was mostly for Windows.
[22:02:47] <wjp> disabling timidity should be ./configure --disable-timidity
[22:03:21] <rixa_> oh, ok. I can try that. Though, at the moment I'm using binaries from Debian unstable. Is there a runtime switch?
[22:04:27] <wjp> strangely, no
[22:05:02] <rixa_> Oh. Well, thanks for information.
[22:06:18] * wjp browses some code to double-check
[22:06:33] <wjp> no, I'm afraid this is compile-time only
[22:07:38] <rixa_> No worries, I'll compile from source and we'll see how it goes.
[22:08:20] * wjp wonders why there isn't a runtime switch for this
[22:49:50] <wjp> I should be going; g'night
[22:50:01] <-- wjp has left IRC ("Zzzz...")
[22:52:14] --> Kirben has joined #exult
[22:52:14] --- ChanServ gives channel operator status to Kirben
[22:57:32] <rixa_> Well, it works. Exult is suspiciously silent though, only playing a little song every once in a while. Is that normal?