ShowEQ 6 Beta Test

[fransick]

Hey Fransick, I havent seen that script, or at least I am not familiar with it. Can you put it in the dev forum?

It's not something I've seen. I think it's something Newby did to help automate whatever manual process he was going through to find critical opcodes. I could be wrong but I thought he mentioned something. If I am wrong on that, apologies. When I do them it's the old fashioned manual approach, haha. Whatever he is doing it is way faster than what I am doing haha.

[cn187]

I don't really use the find input (except when I'm in the wrong window and wind up searching for wwwwwwwwwwww instead of moving) so I hadn't noticed, but I'm 99% sure that's a QT-related issue. There were a lot of case sensitivity related changes to the API. I thought I got all of it sorted out, but I guess not. Thanks for mentioning it, I'll take a look at it.

[BlueAdept]

Things are finally getting back to normal. I got some of the essentials unpacked and got some furniture assembled. In about a week or so, I should have some time to play around with the new version.

[cn187]

Fransick,

Regarding the Find issue - I've managed to reproduce a case-related issue, but I'm not sure of the cause yet (contrary to my previous thought, it may or may not be QT related), or if it's the same issue you're seeing.

Out of curiosity, do you do an empty search (to clear the highlights) in between searches? Or do you go from one thing directly to another?

[fransick]

Fransick,

Regarding the Find issue - I've managed to reproduce a case-related issue, but I'm not sure of the cause yet (contrary to my previous thought, it may or may not be QT related), or if it's the same issue you're seeing.

Out of curiosity, do you do an empty search (to clear the highlights) in between searches? Or do you go from one thing directly to another?

Both. I'll keep any eye out to see if one way or the other causes the issue. I kind of didn't pay attention at first just thinking DB changed the naming convention of non named mobs but after visiting some old zones it seemed like something changed.

[cn187]

Both. I'll keep any eye out to see if one way or the other causes the issue. I kind of didn't pay attention at first just thinking DB changed the naming convention of non named mobs but after visiting some old zones it seemed like something changed.

There is for sure an issue if you search "mob x", then clear the line and hit enter, and then search for "mob x" again - it ignores it completely. I've already got a fix for this, but I haven't committed it yet.

So far, I haven't been able to reproduce any other case-sensitivity issues in Find, so any kind of test cases that exhibit the problem would be helpful.

[cn187]

Having dug through the forums *a lot* in order to try to get up to speed, I assume he means this one - http://www.showeq.net/forums/showthr...ll=1#post48772

It was a big help to me when I first started trying to figure out opcodes. I'm mostly doing something different now, but still use the script as a fall-back.

[BlueAdept]

Lol I dont remember that at all, but I see I replied to it! I have it bookmarked now. Thanks.

[splooge]

I'm running both SEQ5 and SEQ6 side-by-side (not at the same time, obviously) on a Raspberry Pi 4-4G and while SEQ5 is super snappy compared to what it was on the Pi 3B+, SEQ6 is very slow, to the point it's almost unusable. Not sure what information I can offer to help analyze the issue but if you have any ideas I'm happy to try. I've tried exporting the display to different PC's but that doesn't make any difference.

[cn187]

I'm running both SEQ5 and SEQ6 side-by-side (not at the same time, obviously) on a Raspberry Pi 4-4G and while SEQ5 is super snappy compared to what it was on the Pi 3B+, SEQ6 is very slow, to the point it's almost unusable. Not sure what information I can offer to help analyze the issue but if you have any ideas I'm happy to try. I've tried exporting the display to different PC's but that doesn't make any difference.

Upthread, fransick had reported some performance issues (map lag) but they were resolved by a clean install. I'm not sure if that's an option for you, but if so, you might give that a shot. I suspect there could be some sort of conflict between qt3 and qt4, or some other "cruft" that's causing an issue.

Are you running Raspbian, or some other distro? What version? Was QT installed via the package manager, or a different way? What version?

Upthread I gave instructions on getting profiling data. That may or may not help, but since I still haven't been reproduce any kind of performance issues, it might at least give an idea of the problem. I'll think about it some more and see if I can come up with any more ideas, but that's all I've got for now.

[splooge]

Upthread, fransick had reported some performance issues (map lag) but they were resolved by a clean install. I'm not sure if that's an option for you, but if so, you might give that a shot. I suspect there could be some sort of conflict between qt3 and qt4, or some other "cruft" that's causing an issue.

Are you running Raspbian, or some other distro? What version? Was QT installed via the package manager, or a different way? What version?

Upthread I gave instructions on getting profiling data. That may or may not help, but since I still haven't been reproduce any kind of performance issues, it might at least give an idea of the problem. I'll think about it some more and see if I can come up with any more ideas, but that's all I've got for now.

CentOS 7. http://ftp.osuosl.org/pub/centos-alt...8/isos/armhfp/ I started with the minimal install (minimal-4-1908) and did a groupinstall of KDE Plasma since the KDE image wouldn't install for me (I couldn't get it to boot, could be a bad SD card I copied the image onto, need another SD card to troubleshoot with)

Everything was installed via yum:

[root@rpi4 ~]# yum info qt-devel
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: ftp.osuosl.org
* centos-kernel: mirror.keystealth.org
* extras: mirror.keystealth.org
* updates: ftp.osuosl.org
Installed Packages
Name : qt-devel
Arch : armv7hl
Epoch : 1
Version : 4.8.7
Release : 3.el7_6
Size : 32 M
Repo : installed
From repo : base
Summary : Development files for the Qt toolkit
URL : http://qt-project.org/
License : (LGPLv2 with exceptions or GPLv3 with exceptions) and ASL 2.0 and BSD and FTL and MIT
Description : This package contains the files necessary to develop
: applications using the Qt toolkit. Includes:
: Qt Linguist

[root@rpi4 ~]# yum info qt3-devel
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: ftp.osuosl.org
* centos-kernel: mirror.keystealth.org
* extras: mirror.lax.genesisadaptive.com
* updates: ftp.osuosl.org
Installed Packages
Name : qt3-devel
Arch : armv7hl
Version : 3.3.8b
Release : 51.el7
Size : 35 M
Repo : installed
From repo : base
Summary : Development files for the Qt 3 GUI toolkit
URL : http://www.troll.no
License : QPL or GPLv2 or GPLv3
Description : The qt3-devel package contains the files necessary to develop
: applications using the Qt GUI toolkit: the header files, the Qt meta
: object compiler.
:
: Install qt3-devel if you want to develop GUI applications using the Qt 3
: toolkit.

The best way to describe the slowness is that it takes about 10 seconds for SEQ to re-draw itself, almost as if this were Windows 3.1 and you're trying to drag a window around with a mouse and a slow video card. From the top of the SEQ Window to the bottom, you can watch it draw itself out in realtime.

Come to think of it, I was getting an error running `make`:

In file included from /usr/include/c++/4.8.2/cstdint:35:0,
from everquest.h:42,
from interface.h:47,
from main.cpp:56:
/usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.

As soon as I added

-std=c++11

to CFLAGS in the Makefile it compiled without any further complaints.

I'll try a re-install of the minimal image and this time I'll leave KDE out of the picture, I'll just install the dependencies as it complains about them being missing.

Thanks for all the time you're putting into this, if you have paypal or venmo I'd like to send you a donation.

[cn187]

I'll try a re-install of the minimal image and this time I'll leave KDE out of the picture, I'll just install the dependencies as it complains about them being missing.

Thanks for the info. If you do the reinstall, then I suggest maybe trying to build/run *only* QT4/SEQ6 at first, see how it behaves, and then go back and add in QT3/SEQ5 if you still want/need to.

[splooge]

Thanks for the info. If you do the reinstall, then I suggest maybe trying to build/run *only* QT4/SEQ6 at first, see how it behaves, and then go back and add in QT3/SEQ5 if you still want/need to.

I saw a post that you cured someone of some slowness by fixing something in libpcap. Hoping I would see the same results, I went ahead and did a fresh install of CentOS 7 and ShowEQ 6 on a Raspberry Pi 4-4G.

Same slowness, without even sniffing packets yet. I'm forwarding the X11 display over SSH from the RPI to a laptop. Poking around, I saw that sshd was taking 25% utilization. Interesting. So I decided to do the X11 forwarding without ssh. Still slow.

I wanted to see what was going on with the network, but I couldn't find ntop for arm, so I just went ahead and looked at my laptop's task manager, and here's what I found.

ShowEQ 5 with QT3 exporting the display to the laptop uses almost zero network bandwidth: 0.1Mbps

ShowEQ 6 with QT4 exporting the display to the laptop uses about 800x the bandwidth: 82.9 Mbps

I have zero idea what could be causing this, but I figured you'd be interested in seeing what I'm running into. Perhaps not many others are exporting their display to a remote machine which is maybe why you haven't heard any other people complain? I'm using Xming, an X server for Windows as well as XQuartz, an X server for MacOS. Both show the same issue.

And maybe this is a problem everywhere, but is hidden by the fact that most PCs can probably handle this sort of graphics locally?

Here's some screenshots of Windows task manager reporting the network utilization of the X server:

https://i.imgur.com/4Ws9wDN.png
https://i.imgur.com/U7NJHAf.png

I hope that offers you some insight as to what might be going on. I can't make any sense of this at all.

Thanks

[cn187]

Thanks for all the time you're putting into this, if you have paypal or venmo I'd like to send you a donation.

Regarding this - thank you. I appreciate the offer. While I'm doing the work on SEQ for a number of personal reasons, financial gain isn't really one of them. Well, unless you're super rich and want to donate enough that I can quit my job and retire to a life of playing EQ and working on SEQ and other open source software. Then I might reconsider

I'm also the "new guy", and while I have been doing a lot of work on the codebase recently, I think that the folks that have been keeping this project alive all along (BlueAdept, Newby, Fransick, and others) deserve donations more. Without them and their efforts, there might not have been anything left here for me to contribute to. Maybe you could kick them a few bucks instead.

[BlueAdept]

Bah, I dont do anything really. I just happen to a user that has been around longer than most. Anyone who actually contributes to the code base are the ones that deserve the credit. Without all you, this project would have been dead and buried long ago. Putting a donation link is fine and deserved.