trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

Are anyone working on getting DROD working on linux ? I've been away from the drod forums for a while, so apologies if this has been discussed. Couldn't find anything, tho.

Anyway, i took a look at the source, and didn't know where to begin (is there an overview somewhere ?), so i just started with BackEndLib. A few small changes in Files.h, IniFile.cpp, Ports.h/cpp and SysTimer.cpp made it compile. I'd send a patch, but my e-mail-server (at icculus..) is down. Should i post it here in stead ?

Also, i've a few questions and observations:

* I used the makefile already there to compile it, but at the end it tries to link to ../lib/belib.a, which isn't there. What's that ? (edit: um, yeah, that was just me being stupid. belib is of course the lib that's being built, but as there's no ../lib dir on my box it failed. Made it, and it works now )

* When compiling with warnings, i get a whole bunch of "warning: statement with no effect". This is because you're using a custom assert.. Any reason why ?

* There's also some other warnings about unused variables. Should those be fixed, or are they there for later use ?

* Another warning is about comparision between signed and unsigned integers, in Inifile.cpp..

* Ports.* define a function named towlower. This function already exists in linux (according to the manpage it's ISO/ANSI C, actually). It uses wint_t in place of wchar_t, but it seems to be the same as just commenting out the new definition and using the built-in one works without (additional) warnings (i've no experience at all with wide characters, so please smack me down if i'm being stupid here).

* To get the system ticks in milliseconds in linux, i used the gettimeofday function, which returns two fields: seconds and microseconds since the epoch. To get this into millisecods i multiply the seconds by 1000, divide the microseconds by 1000, and add together, but this may have potential overflow problems since the return value is only a DWORD. Is there a better way ?

Just getting started at this..


[Edited by trick on 06-14-2003 at 03:42 PM GMT: figured out belib..]

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

Got FrontEndLib to compile now as well. It just needed a few minor changes. There's heaps of warnings, though (even without the -W and -Wall warning switches), mostly assignment conversions and 'no newline at end of file' warnings.

One important thing i found was that two of the files included from ../DRODLib, namely DbProps.h and PathMap.h, have the wrong case (they're called DBProps.h and Pathmap.h in stead). Since Linux is case sensitive, that means they're not found. This requires a delete+recheckin in CVS to fix..

ross
Level: Delver
Rank Points: 30
Registered: 05-17-2003
IP: Logged

trick wrote:
A few small changes in Files.h, IniFile.cpp, Ports.h/cpp and SysTimer.cpp made it compile. I'd send a patch, but my e-mail-server (at icculus..) is down.

A quick grep for __APPLE__ or __sgi will help you find all of the places you might need to change something ( unless it looks endian ). Given that you have probably got wchar.h there should be minimal changes.

trick wrote:
* I used the makefile already there to compile it, but at the end it tries to link to ../lib/belib.a, which isn't there. What's that ? (edit: um, yeah, that was just me being stupid. belib is of course the lib that's being built, but as there's no ../lib dir on my box it failed. Made it, and it works now )

Sorry that was my fault. I was working from Schiks original sgi makefile but it didn't support the recent change to the file structure (I sorta guessed what to do). You may want to make the backend and frontend lib shared objects instead of static libs. Also you won't need anything in the Makefile that looks like -framework XYZ (that's just Mac nasyness).

trick wrote:
* Ports.* define a function named towlower. This function already exists in linux (according to the manpage it's ISO/ANSI C, actually).

Guilty. There is no wchar.h on MacOS X (or SGI) and therefore I think Schiks original intent was for Ports.h/cpp to have the wcs*() for those that don't have them. If you have wchar.h then you probably don't need Ports.h.

mrimer
Level: Legendary Smitemaster

Rank Points: 5058
Registered: 02-04-2003
IP: Logged

trick wrote:
Are anyone working on getting DROD working on linux?

It's great to have you working on that! It should be pretty close to portable, and your help is appreciated.

trick wrote:
...so i just started with BackEndLib....Should i post it here in stead?

Yeah, BackEndLib is the place to start, and then DRODLib, then FrontEndLib, then DROD. Posting your changes here would be fine, but emailing your diffs to me would be best! I'll put them in right away as soon as I get them. You could add some #ifdef LINUX blocks or whatever around the linux only stuff.

trick wrote:
* When compiling with warnings, i get a whole bunch of "warning: statement with no effect". This is because you're using a custom assert.. Any reason why?

When we get an assert, it gets saved to the drod.err log file.

trick wrote:
* There's also some other warnings about unused variables. Should those be fixed, or are they there for later use?

Sure, send those my way.

trick wrote:
...To get this into milliseconds i multiply the seconds by 1000, divide the microseconds by 1000, and add together...

Yes, a DWORD could wrap around (after about a month or so?), but I think GetTicks() is only used in a couple specific places where it's considering in-game real time deltas, so it's not an issue of getting actual dates.

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

mrimer wrote:

trick wrote:
...so i just started with BackEndLib....Should i post it here in stead?

Yeah, BackEndLib is the place to start, and then DRODLib, then FrontEndLib, then DROD. Posting your changes here would be fine, but emailing your diffs to me would be best! I'll put them in right away as soon as I get them. You could add some #ifdef LINUX blocks or whatever around the linux only stuff.

Mike, I'm worried about telling Trick to just go for it. I was hoping to get the legal stuff straightened out for accepting contributions that go into our closed source projects. As usual, there isn't enough time, and I always feel unready. Damn these people that show up out of nowhere to help me!

The gist of it, for Trick, Schik, and Ross: FrontEndLib and BackEndLib are planned for reuse on other Caravel Software projects that aren't open source. Any contributions would still get licensed under Mozilla for DROD, but we need to get written permission from the authors for our intended not-compliant-with-Mozilla use. The alternatives are to either (wince) fork FrontEndLib and BackendLib or (WINCE!) replace some of the contributed code. I had planned to talk to Schik and Ross personally about it. The good fortune of Trick's arrival prompts me to bring it up in a hurry, before anyone writes another line of code with the wrong expectations.

Also, I would like to set up some kind of standard agreement that we can make with anyone who wants to contribute to the Caravel Distribution. But there's no time to work that out right now. I feel everyone at least deserves a warning about Caravel goals which may conflict, before they set out to collaborate with us.

-Erik


____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

No worries, Erik. I hereby declare my Grant of Permission to You to do Whatever You Want with Any Code Submitted by Me to Caravel DROD. Let me know if you want it more formally

I managed to fix the assert problem, by the way (see the patch). Shouldn't introduce any problems, i think. I also fixed some other small warnings: an unused variable and some signed/unsigned comparisions (about that, the CGameStream::Read and CGameStream::Write functions should have size_t as their second argument in place of int, but i didn't change that - didn't want to intrude too much..).

All this (well, it wasn't that much work, really) means that you can now compile BackEndLib in linux with all warnings turned on, and get only one warning (from Ports.cpp, line 43, which tells about an unused parameter named 'radix'), as opposed to some screenfuls before. Whee.

By the way, Ross, in Ports.*, i just commented out the towlower part inside a #ifndef __linux__ (that's the standard linux define). There's some other functions in there that is needed.

Oh, and about making BackEndLib and FrontEndLib shared libs, i don't know if that's really necesarry.. They're only used in this one game for now, and Erik would probably change them for his other games anyway.

And now, the patch. I don't think i introduced any new serious bugs, but i'd have a look at it to be sure . I first thought to just include the patch here, but the code blocks seems to insert extra newlines between every line, and outside code blocks the syntax is lost, so i put it up on my linux box' local webserver, here. It's on a wireless connection behind a gazillion walls, so if it doesn't work, just try again later.

I had a working FrontEndLib too, but i managed to destroy its dir (yay me), so i'll have to do that one again. But, first i'll have some sleep.

mrimer
Level: Legendary Smitemaster

Rank Points: 5058
Registered: 02-04-2003
IP: Logged

Sorry, Erik. I agree. I get too enthusiastic sometimes!

I got the diff and put Trick's changes into my code. If Trick's consent is satisfactory, I'll commit them.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

Hehe, i'm known to get enthusiastic at times too

I've started working on DrodLIB, and have had little problems so far (i'll hold off FrontEndLib until we hear from Erik again). I've mostly eliminated warnings and such - even though most are harmless i don't like having them around, as they can potentially be hiding real warnings and bugs. This warning-elimination involves commenting out names of unused parameters and unused variables. If you don't like me doing that, let me know.

But, i've hit a few potential real problems in the process.

* As mentioned above, DbProps.h and PathMap.h need their filename case fixed.

* The delete[]ion of void* pointers in DbPackedVars.cpp (line 88 and 255), which, according to g++, is undefined (it's been a while since the last time i did c++ coding, so i don't remember how to deal with this..). IIRC it only means destructors and such don't get called, but i'm a bit worried about the whole "undefined" thing.

* In DbPlayers.cpp, CDbPlayer::Load, last couple of lines, a c4_BytesRef is assigned to a CDbPackedVars&, for which there's no assign operator, so g++ stops with an error. There's "c4_BytesRef = c4_BytesRef" and "CDbPackedVars = CDbPackedVars" available, but no "CDbPackedVars = c4_BytesRed".. Should i just cast it ?

- Gerry (<- my real name )


[Edited by trick on 06-15-2003 at 06:12 PM]

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

trick wrote:
I've started working on DrodLIB, and have had little problems so far (i'll hold off FrontEndLib until we hear from Erik again).

Go ahead, Gerry. And thanks!

At some point, I might mail you something to sign that says we can use your changes, but based on what you've said I don't think any problems will come up.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

ross
Level: Delver
Rank Points: 30
Registered: 05-17-2003
IP: Logged

By the way, Ross, in Ports.*, i just commented out the towlower part inside a #ifndef __linux__ (that's the standard linux define). There's some other functions in there that is needed.

You shouldn't actually needs WCSlen() from Ports as you should already have wcslen() on Linux in wchar.h. In fact try not using Ports at all you might find that it still compiles

Oh and Erik if I need to sign anything I don't have a problem with that .. although getting the whole thing running properly would make sense first for me I guess

[Edited by ross on 06-15-2003 at 09:04 PM]

[Edited by ross on 06-16-2003 at 07:52 AM]

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Replying to the rest of your message...

trick wrote:
But, i've hit a few potential real problems in the process.

* As mentioned above, DbProps.h and PathMap.h need their filename case fixed.

Just change the #includes to be correct.

* The delete[]ion of void* pointers in DbPackedVars.cpp (line 88 and 255), which, according to g++, is undefined (it's been a while since the last time i did c++ coding, so i don't remember how to deal with this..). IIRC it only means destructors and such don't get called, but i'm a bit worried about the whole "undefined" thing.

Hmm. I'm not worried about destructors getting called, because there are none in these cases. I don't understand why the compiler should worry about it. The address is enough information to free the memory. If it's just a warning, you might try casting to an "char *".

* In DbPlayers.cpp, CDbPlayer::Load, last couple of lines, a c4_BytesRef is assigned to a CDbPackedVars&, for which there's no assign operator, so g++ stops with an error. There's "c4_BytesRef = c4_BytesRef" and "CDbPackedVars = CDbPackedVars" available, but no "CDbPackedVars = c4_BytesRed".. Should i just cast it ?

I don't know without getting deeper into it. I'm wondering what Ross did.

- Gerry (<- my real name )

Are you Gerry Quinn, by chance?

-Erik


____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

ross
Level: Delver
Rank Points: 30
Registered: 05-17-2003
IP: Logged

In DbPlayers.cpp, CDbPlayer::Load, last couple of lines, a c4_BytesRef is assigned to a CDbPackedVars&, for which there's no assign operator, so g++ stops with an error. There's "c4_BytesRef = c4_BytesRef" and "CDbPackedVars = CDbPackedVars" available, but no "CDbPackedVars = c4_BytesRed".. Should i just cast it ?

Ooops sorry I missed this question. Yup just cast is I think it needs to be a const c4_BytesRef reference but you'll get away with (c4_BytesRead) - I never could remember the new style casts.

The things that MSVC ignores

[Edited by ross on 06-16-2003 at 10:10 PM]

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

I've got DRODLib compiling now. In my quest for eliminating as many compiler warnings as humanly possible, i also found and fixed some potential bugs ("always true" comparisions, for scope errors, etc). See, it helps

Eh, this is somewhat long, so i'll make neat captions for your viewing pleasure.

The current state

I've still got some warnings left, the most bothersome is some in DbDemos.cpp saying: "warning: choosing `CAttachableWrapper<T>::operator T&() [with T = UINT]' over `CAttachableWrapper<T>::operator T() const [with T = UINT]' for conversion from `CAttachableWrapper<UINT>' to `unsigned int' because conversion sequence for the argument is better" (and the same with bool), but i took a look at it, and it's harmless. I don't know how to make it go away, tho. Then there's some "always true" warnings for some ASSERTs (with _DEBUG only), which should be so. And then.. nothing else.

Changes and comments

I fixed the CDbPackedVars = c4_BytesRef problem (and a similar one) by creating a new constructor in CDbPackedVars and CDbCommands, as i was unsure how to cast that properly (this was before the reply from you, ross). I'm pretty sure it works as intended, but, as always, you might want to take a look to be sure.

I made the parameters to bIsArrowObstacle in DbRooms.cpp UINTs, by the way, to get rid of some 20 signed/unsigned warnings. I checked around, and it seems that was intended to be UINTs all along, so it shouldn't hurt anything. I saw a few other places that could benefit from UINTing, but, again, i didn't want to intrude too much..

I also fixed some more stuff i missed the last time in BackEndLib, as i forgot to define _DEBUG before. Cleaned up Assert.h a bit, commented out some more in Ports.* (it couldn't be eliminated entirely, tho). In addition to that i made Wchar.* make use of the native linux wcs* functions (thanks, ross!).

Some replies

ross wrote:
You shouldn't actually needs WCSlen() from Ports as you should already have wcslen() on Linux in wchar.h. In fact try not using Ports at all you might find that it still compiles

Thanks! I replaced all the WCS*-functions with linux ones.

The things that MSVC ignores

Yah.. It's amazing.

ErikH2000 wrote:

DbProps.h and PathMap.h need their filename case fixed.

Just change the #includes to be correct.

That was my first thought too, but that would make those files break the naming convention of the other files. Every time someone wants to include DbProps.h, they have to remember it's a special case, and write DBProps.h instead. Same with Pathmap.h, as its class is named CPathMap. I did change the #includes for now, tho. The alternative is putting version information in the attic.. (why oh why doesn't cvs have a rename function ?)

(..) void* pointers (..)

Hmm. I'm not worried about destructors getting called, because there are none in these cases. I don't understand why the compiler should worry about it. The address is enough information to free the memory. If it's just a warning, you might try casting to an "char *".

It's an array being deleted, so i think it is because delete[] doesn't know what size it is. I checked the code, and it seems to assign char size arrays to it, so casting to char* should be safe enough.

- Gerry (<- my real name )

Are you Gerry Quinn, by chance?

Nope, i'm just Gerry Jo Jellestad..

The patches!

Both are diffed against latest CVS. Btw, my text editor wants to delete all whitespace at end of lines, so there might be some extra lines changed..

By the way, i noticed mrimer wrote "(comitted on behalf of trick)" in the logs. That might be a bit misleading, as the sourceforge username 'trick' belongs to someone else.. Just write Gerry JJ or something

EDIT: While fixing FrontEndLib i found out that using the native linux wcs* routines is a bad idea, as they use a different definition of wchar than drod.. Also moved the patches to a real server. See the next post.

Rename the Makefiles to Makefile.linux (or something else fitting) and put them to their right dir

*yawn*

Let me know if there's any problems.

- Gerry


[Edited by trick on 06-18-2003 at 02:50 PM GMT: Oops]

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

Oops. The native linux wcs* routines seems to use a different definition of wchar than DROD does. First time i dabble with unicode.. Anyway, updated the BackEndLib patch to fix this. The DRODLib patch is as before.

I moved the patches to a real server, so there shouldn't be any problems with connection now. I put everything here. As before, move the makefiles to their right dir and rename to Makefile.linux.

The FrontEndLib patch should be done soon, by the way.

EDIT: Oh, and the email server is back up.. Should i send the patches by email in stead ? What's the address ?

[Edited by trick on 06-18-2003 at 03:09 PM]

ross
Level: Delver
Rank Points: 30
Registered: 05-17-2003
IP: Logged

trick wrote:
Oops. The native linux wcs* routines seems to use a different definition of wchar than DROD does. First time i dabble with unicode..

Oops you might find that wchar_t are 32 bit on Linux, I can't remember. It should really be unsigned short but there you go ..

I'm likely to revert my laptop from BeOS back to Linux some time soon so if you'd like some testing
Once the Linux version is done and 1.6 is released I'll probably move my broken version in line with the Linux one ..

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

trick wrote:
Oops. The native linux wcs* routines seems to use a different definition of wchar than DROD does. First time i dabble with unicode..

The main thing to keep in mind is that the stored format *MUST* stay the same. We want to be able to read the same data on different O/Ss. It isn't strictly necessary to use the same format for internal-only operations, but it might be inconvenient not to.

I think that Schik ended up writing duplicate versions of common wide char functions because his versions operated on 2-byte wide char strings (storage format) and the SGI versions operted on 4-byte strings. wchar_t is different things on different platforms, unfortunately.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

Schik
Level: Legendary Smitemaster

Rank Points: 5383
Registered: 02-04-2003
IP: Logged

ErikH2000 wrote:
I think that Schik ended up writing duplicate versions of common wide char functions because his versions operated on 2-byte wide char strings (storage format) and the SGI versions operted on 4-byte strings. wchar_t is different things on different platforms, unfortunately.

Bingo. We don't use wchar_t, we use our own WCHAR. So I made portable functions WCScmp, WCSlen, etc. that we should use on ALL platforms. Of course I made them plenty buggy (thanks for fixing them, Mike ).

But anyways - the point was that we should stay away from the built-in-on-some-platforms wcs* functions, and use the WCS* versions instead. If you need another one that hasn't been rewritten, just write it. Or tell one of us, they're not very complex.


____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

Yep. I already fixed that in the 2b version of the BackEndLib patch (both that and DRODLib is against latest CVS, btw), so there shouldn't be any problems.

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

By the way, do you have any guidelines for what i'm allowed and not allowed to do while patching and eliminating warnings ?

I won't add, remove or modify the behaviour of any features, of course. I expect fixing of bugs is always welcome (as long as the fix is right), but i'm thinking about the kind of thing i did with bIsArrowObstacle in the DRODLib patch: changed the parameters from int to UINT to eliminate some warnings in an efficient way. I felt that was okay since the source indicated that it was meant to be UINT all along, but i don't want to "intrude", if you know what i mean.

So, to put it short: What can i do ?

mrimer
Level: Legendary Smitemaster

Rank Points: 5058
Registered: 02-04-2003
IP: Logged

trick wrote:
By the way, do you have any guidelines for what i'm allowed and not allowed to do while patching and eliminating warnings ?
...

I just downloaded your patches and will enter them in now. I'm pretty sure that everything you did is fine. I never have a problem with someone fixing something up. Especially if it eliminates potential bugs. And if Erik or I don't like it, we can always change it later, so don't worry about sending us things that help make DROD better!

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

mrimer
Level: Legendary Smitemaster

Rank Points: 5058
Registered: 02-04-2003
IP: Logged

Okay, it's all entered in and committed.

ross
Level: Delver
Rank Points: 30
Registered: 05-17-2003
IP: Logged

Schik wrote:
Bingo. We don't use wchar_t, we use our own WCHAR. So I made portable functions WCScmp, WCSlen, etc. that we should use on ALL platforms.

I agree. If WCHAR is defined to be unsigned short in Drod then it's non portable if that is being treated as wchar_t. What I mean is if you typedef WCHAR then use it in Windows wcslen() you're surely breaking portability, it's only fluke that the wchar_t is the same size.

If ALL wide character handling was done inside DROD then it would be a lot more portable. Given that it's text handling I doubt it's going to slow down the game very much.

I'm expecting to get shouted at now

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

Two problems after the update:

In BackEndLib/GameStream.cpp, CGameStream::CGameStream, g++ bombs out with an error because you changed type and name of the second parameter and didn't update the #else of the #ifdef HAS_UNICODE. Is the second parameter ASCII now ? Why is CFiles:pen inside a HAS_UNICODE ifdef anyway ? It seems to handle the non-unicode case as well.. (by the way, you might want to move the if (!pFile) in Files.cpp line 157 inside the #ifdef (and just leace the brackets).. The optimizer would probably catch it, but it doesn't hurt.)

In FrontEndLib/Monster.h, line 109, the init of pNext must come before pPrevious to avoid some warnings about initialization reordering in all files that include Monster.h.

Oh, and you can remove the #ifdef __linux__ in BackEndLib/Wchar.h that #includes <wchar.h>. Forgot to remove that.

Still haven't finished the FrontEndLib patch yet (was out in the sun instead ), but it's right around the corner.

I'd create a patch to fix the above problems to save you some time , but i'm having major problems getting cvs to cooperate with me. Before i could get it to work after some retries, but not today. I'll create another thread for that.

ross wrote:
If ALL wide character handling was done inside DROD then it would be a lot more portable. Given that it's text handling I doubt it's going to slow down the game very much.

That's how it's done already . It was me that created a problem when i tried to use the native linux wcs* calls. That is gone now, so all is well.

- Gerry

ross
Level: Delver
Rank Points: 30
Registered: 05-17-2003
IP: Logged

ross wrote:
If ALL wide character handling was done inside DROD then it would be a lot more portable. Given that it's text handling I doubt it's going to slow down the game very much.

That's how it's done already . It was me that created a problem when i tried to use the native linux wcs* calls. That is gone now, so all is well.

I meant for Windows too ...

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

ross wrote:

ross wrote:
If ALL wide character handling was done inside DROD then it would be a lot more portable. Given that it's text handling I doubt it's going to slow down the game very much.

That's how it's done already . It was me that created a problem when i tried to use the native linux wcs* calls. That is gone now, so all is well.

I meant for Windows too ...

So you're saying we're still using native calls someplace for Windows? I thought we converted it all to use WCS*().

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

Schik
Level: Legendary Smitemaster

Rank Points: 5383
Registered: 02-04-2003
IP: Logged

ErikH2000 wrote:
So you're saying we're still using native calls someplace for Windows? I thought we converted it all to use WCS*().

Unless some more have snuck in there since I ported it to the SGI, they're all WCS*(). Otherwise they wouldn't have compiled for me.

____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

ross
Level: Delver
Rank Points: 30
Registered: 05-17-2003
IP: Logged

Maybe old age is making me loose my memory. I've just looked and you're right no calls to wcs*. Can't think why I thought there were .. probably my day job getting on top of me

Sorry for the small panic

mrimer
Level: Legendary Smitemaster

Rank Points: 5058
Registered: 02-04-2003
IP: Logged

trick wrote:
Two problems after the update:
...

Could you please give me a diff of these when you get to it? I'm not sure I understood everything. Thanks.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

The FrontEndLib patch is done! It now compiles on linux almost without warnings (there's one warning left in Sound.h about ignoring the pragma warning() there, but that's no prob). Yay

mrimer wrote:
Could you please give me a diff of these when you get to it? I'm not sure I understood everything. Thanks.

No problem. After some retries i managed to diff it, and put the patches up here. Let me know if you have any questions. The Makefile.linux there belongs in the FrontEndLib dir, by the way.

- Gerry

mrimer
Level: Legendary Smitemaster

Rank Points: 5058
Registered: 02-04-2003
IP: Logged

Thanks. I got 'em.

Just a question. I've noticed you've rearranged some of the vars in constructor initialization lists. I was wondering what the warning was that requires doing that to remove it?

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.