Corun

ATI Rage 128 Is about the worst graphics card that supports 3D acceleration on Mac OS X. I'm not surprised at the speed :-). About the Chat System. Phew.. I was looking for ages trying to fix that bug. I couldn't work out why it was appearing on Mac OS X (Other people I asked who I guess weren't running the CVS version said theirs worked fine). I gave up in the end hoping that someone else would fix it :-)

*) Move and GetColor needed to be changed because one of the library headers includes Carbon(A Mac OS X API) and that defines Move() and GetColor(). I changed them to get rid of the name conflict. *) On OS X, #define ELC is in global.h. This is needed by translate.h. *) I don't think making a makefile would be useful. The OS X version really needs an xCode(OS X IDE) project to be built properly. I checkout a fresh version and had to change the following to get it to work: -GetColor and Move -#include "global.h" in translate.h -the #endif after "#include <X11/Xlib.h>" on line 25 of paste.h needed to move to the end of paste.h

Patch posted. Email with link to fully made version ready for download sent to wytter.

I dunno how to make a patch :-/. I'll just email you a zip of the source and binary at some point or I'll email a link if it's too big.

Sorry, I've been a little busy with other things I will commit something today and give a binary to someone binary somewhere(who, how?)

Created. UN: Corun I will CVS my changes later this week. Thanks for those references Wytter, those shouldn't take too long to endianize.

It does? Cool :-). I just guessed at what Write16 and friends did. I should really have looked at the Docs :-). In that case we should most definitily be using them... But.. Oh well :-) We should still make sure that the SDL DLLS that come with the windows ELC had TCP_NODELAY defined when they were compiled, though. An update on the Mac OS X Port: - All endian stuff seems is done I think (Some random guy gave me a sword and helmet for no reason in a trade ) - Found the bag bug. Bags weren't being added properly. - Pasting doesn't work. - Delete key doesn't work in text fields. - Loading is a little slow. - I need to make sure I've put #ifdef OSX and #ifdef EL_BIG_ENDIAN around all my changes.

Doesn't this lead into problems eventually? Because we can't suspect players to compile SDL_net for themselves, ensuring TCP_NODELAY is defined when compiling, wouldn't we have the need to include (a self-compiled) SDL_net with the distribution of the client? I don't see how it would lead to problems. What I am suggesting is distributing the Windows client with SDL_net compiled with TCP_NODELAY defined. This would possibly decrease lag slightly for the windows users. For people compiling it themselves from cvs we could put something in the readme recommending that they compile their SDL_net with TCP_NODELAY defined. It won't make things worse if they don't (because that is how it is done currently) But it would make it better for those that did it.

I wouldn't recommend using them because they will make networking a lot worse in some cases; If SDL_net is compiled with TCP_NODELAY #defined then it will send one tcp packet for each SDLNet_Write*() function and there would be a lot of unneccessary bytes used in the TCP headers. What we really want is to do it like it is done currently and make sure that TCP_NODELAY is #defined when SDL_net is compiled. (Note: Normally, when stuff is sent with TCP there is an algorithm which collects data together to try and send a large clump at once. This can cause there to be a short wait between write()s and the actual sending of the data. TCP_NODELAY turns of the algorithm and makes write() send stuff instantly which is what we want.)

Hi, I'm the person who is porting elc to Mac OS X. It's not far from complete but I do have a few questions: At the moment there seems to be a problem that occurs sometimes when a bag tries to be removed. In void remove_bag(int which_bag) in items.c the line: sector=SECTOR_GET(objects_list[bag_list[which_bag].obj_3d_id]->x_pos, objects_list[bag_list[which_bag].obj_3d_id]->y_pos); Is crashing with segfaults a lot. I don't think it's an endian problem. Have any of you been experiencing this problem? Here's a teaser screenshot (with a few bits not working that you can probably see): http://www.evula.org/corun/elscreen.jpeg I also have a request. Please write your code and think about endians! Here's how it goes: If you are a reading something from a file or from the server then you must swap it. So, imagine 'data[10]' is a buffer which contains an int a short and a float(in that order) from the server You are doing this: int myInt = *((int*)data); short myShort = *((short*)(data + sizeof(int)); float myFloat = *((float*)(data + sizeof(int) + sizeof(short)); What you should do is this: int myInt = SDL_SwapLE32(*((int*)data)); short myShort = SDL_SwapLE16(*((*((short*)(data + sizeof(int))); float myFloat = SwapLEFloat(*((float*)(data + sizeof(int) + sizeof(short))); (Note, SwapLEFloat is not part of SDL but it will be in misc.c when the OS X port is commited). The same thing goes if you pointer cast in to struct. You should do this: typedef struct { int myInt; short myShort; float myFloat; } FileHeader; FileHeader he; he = *((FileHeader*)data); he.myInt = SDL_SwapLE32(he.myInt); he.myShort = SDL_SwapLE16(he.myShort) he.myFloat = SwapLEFloat(he.myFloat); The good thing about this is that SDL #defines SDL_SwapLE32(X) (X) and friends on little endian machines so it won't slow anything down for you PC people but what this will do is it will make us big endian people happy :-).