Windows clients

[Reven]

First of all, I'll point out that the work I did was just in porting this client to Windows. So my work was getting it to compile in MingW, tweaking the SDL code slightly to work in Windows, and adding Windows OpenGL support. My purpose in asking for testers was to make sure OpenGL works ok, as I encountered some problems that I had to work around. The other bug reports are useful, absolutely, but if you find a repeatable bug that is unrelated to OpenGL, the best place to report it is in the bug tracker on Sourceforge.

Well, now crashs : the configure menu looks a little buggy : I have 3 crash dump when I was clicking on "configure menu" -
I have not ur symbols but it can perhaps help with thoses stacks :

At the moment it would be more useful just to know if you can reproduce it with any sort of regularity.

- this client apparently didnt use per account/server settings of keybinding ? (so my keybindings were not keeped and cant be different for different account...)

I've notice this. I'll grep around and see what's up.

- containers are opened in the same window as the container window : they are almost unusable like this : the gtk client open container in another window bottom (or up if its on ground object). And regarding to container, when u open an active container and click again on it, they normaly come back to "active" : here no...

This is a feature. Containers that are opened open into your normal inventory window, but the items in them are indented so you can tell. That way you don't have to have a huge "floor item" window just for the odd cases when you open large chests.

The problem is, when you open a container on the floor, there is a bug when you try and put stuff in it. You first have to open the container on the floor, drop something, then pick it back up. Then it will go in the container.

Well, to conclude, it looks really great : as I said, its slightly more fast than gtk client : with gtk client and a ~3 year old laptop (P4 2.7Ghz, video card ATI RADEON MOBILITY 9000), I can almost only put 13*13 client it its sometimes slow. Here, 25*25 display looks very fast !

There is a bug/misfeature/design flaw in GTK for windows - pixmaps are glacially slow. Really, what these clients are doing should run rock-solid fast on a 486 - and in fact can in Linux. On Windows this isn't the case. This was one of the driving factors why I worked on SDL & OpenGL for Windows.

[Ryo]

- this client apparently didnt use per account/server settings of keybinding ? (so my keybindings were not keeped and cant be different for different account...)

Really? Reading the code it should be doing seperate per account on the gtk2 client too.

Actually, GTK1 client has separate keybindings per player and server. GTK2 has keybindings per player, but not by server (i guess that's what findufin was refering to).

[Rednaxela]

There is a bug/misfeature/design flaw in GTK for windows - pixmaps are glacially slow. Really, what these clients are doing should run rock-solid fast on a 486 - and in fact can in Linux. On Windows this isn't the case. This was one of the driving factors why I worked on SDL & OpenGL for Windows.

One interesting question, is the glacially slow pixmaps when loading them into memory from the server, or rendering them on the screen? When trying gcfclient2-win32/pixmap/wine, it was glacially slow when receiving images from the server to load, however was pretty reasonable at doing the animations themselves. Is that the case also when running on windows as opposed to wine?
Just as a note to compare, gcfclient2/pixmap/linux is the fastest on my system, and opengl and sdl mode both run fairly well, both in native linux, and running your win32 port in wine.

[findufin]

Well, u asked me more details on containers : its perhaps common to all gtk2 clients - and perhaps explained (in some part) in the bug u were refering previously (so its perhaps on the right forum) :

its completly buggy :

- empty opened bags dont have any "+" stuff on left :


- its hard to see when a bags stops (here is a bag with 1 item) :


and another with 2 :



or worse : begining of a bag with lot of stuff :



and end (silver coin) -- as u can see, its almost impossible to find the end of a container :



--> and here, scollbars remains completly unusable (huge) with containers with lot of stuff...


- AND : when u open a contaier on the ground and use right click on an item in ur inventory, u put it on ground, NOT in the container.

- but it still works with "drop ..." and "get ..." commands : u still eventually can put an item on a container of the ground with that commands.
--> on containers on ur inventory, that commands still works like on gtk1 commands (hopefully) - BUT they become strange : u open a bag : items are near ur inventory

- with previous behavioud (gtk1), it was easy to open a bag, scroll in the stuffs, and close (or activate) it again : here, its not easy at all..


Well, to resume, I find that new container behaviour insane

[findufin]

sorry I forgot details :

At the moment it would be more useful just to know if you can reproduce it with any sort of regularity.

--> its quite easy : use that configure menu at differents state of connection (before / after server connection / deconnexion and in game when connected too)

[Rednaxela]

Well, u asked me more details on containers : its perhaps common to all gtk2 clients - and perhaps explained (in some part) in the bug u were refering previously (so its perhaps on the right forum)

Yes, all of these container issues are not specific to the win32 build and are either bugs, or potential design issues in the gtk2 client.

- empty opened bags dont have any "+" stuff on left :

I've noticed that too, and would consider that a bug.

- its hard to see when a bags stops (here is a bag with 1 item) :
and another with 2 :
or worse : begining of a bag with lot of stuff :
and end (silver coin) -- as u can see, its almost impossible to find the end of a container :

I've also noticed this, however for the most part I personally like the new way of displaying containers, but those are issues. Hmm, do you think it would be better if the image was shifted over as well as the text, and possible do something like have a different background color for items in the container (sort of similar to the java editor's style of inventory display for anyone familiar with that)?

--> and here, scollbars remains completly unusable (huge) with containers with lot of stuff...

Hmm, though that issue is more prominent with containers, I think that's something that doesn't just apply with containers. Anyone have any ideas for general solutions to too many items in the inventory list? Perhaps there should be a new inventory display tab to only show open containers and their contents.

- AND : when u open a contaier on the ground and use right click on an item in ur inventory, u put it on ground, NOT in the container.

That's indeed the bug I mentioned earlier which was recently introduced but used to work fine.

[findufin]

I just have really played (not little test like previously).

First, I confirm that its very smooth and fast display : in that opengl display, it never have "slow" time, and with 25*25 its better than 13*13


regarding to containers, u said (Rednaxela) :

I've also noticed this, however for the most part I personally like the new way of displaying containers, but those are issues. Hmm, do you think it would be better if the image was shifted over as well as the text, and possible do something like have a different background color for items in the container (sort of similar to the java editor's style of inventory display for anyone familiar with that)?

mhh it would perhaps be a little better with images shifted over too. and eventually with different color in text part of item too. But I think that it would be less easy to use than gtk1's behaviour


regarding that "grey" squares that we previously discussed (on squares that u have already seen but dont see anymore), now that I have really played, I confirm my first impression :
thoses are very strange and quite ugly ---> less good than the gtk1 behaviour, that use some darkness on thoses squares but still in color

just another screenshot to illustrate : do you find thoses grey squares beautifull ?? :



And after, I found 2 bugs in the display of skills and protection :
1) when skill are too long, it goes on the next window (protection window), there is no scrollbar or stuff like that.
and then, protection are not all displayed
2) the level in parenthesis is wrong : exp points looks good but the level in parenthesis matches with other skills

see screen shot of skills window :



and of the protection window :

[Rednaxela]

Ok, I just tested it on a win32 box I had around, and all seems to work correctly except what has been already noted.
Btw, I couldn't replicate those crashes.

More interestingly, I think I have a bit of an idea of what is going on with the 25 tile offset thing. As a test, I reduced the viewable area of the map to 11x11 on both linux and windows. Interestingly, on windows, the map appeared in the bottom left, while in linux it appeared in the top left. I suspect whatever is causing that is what caused the 25 tile offset.
Now to get into more technical things, openGL measures coords from the bottom left, unlike most things which measure from the top left, and I'm suspecting that GLX and WGL handle that differently and there's something you need to do differently between the GLX/gtk and WGL/gtk init code that isn't being done differently. What exactly needs to be done differently I'm not sure of, and would probably be best to try and find people more familar with cross platform GL/gtk integration.

[findufin]

just a little message : please let me know if there are new releases of this client (for example for keybindings problem) : I now use this one for one of my accounts (one keybindings), except for sorting stuff in containers -> where I use the gtk one ).

Its great smoothness at 25*25 make me addict to this one

[Reven]

regarding that "grey" squares that we previously discussed (on squares that u have already seen but dont see anymore), now that I have really played, I confirm my first impression :
thoses are very strange and quite ugly ---> less good than the gtk1 behaviour, that use some darkness on thoses squares but still in color

I think the intention is to make fog of war look different from darkness. The old way, it is impossible to tell the difference between a square you don't know about, and a square that is dimmed due to darkness. That can cause problems, because if you assume that you can see a square, but for some reason it is "fog of war", then you might assume that there is no monster close when there really is one.

I agree that it isn't as visually nice as a shaded square, but I personally prefer to know the difference between darkness and fog.

And yes, I'll let you know when I have more work done and there is another release.