Page 1 of 2 12 LastLast
Results 1 to 15 of 23

Thread: make SEQ smaller, faster, more modular ?!?!?!

  1. #1
    Registered User black.rabbit's Avatar
    Join Date
    Mar 2002
    Posts
    21

    make SEQ smaller, faster, more modular ?!?!?!

    the problems:
    a) my SEQ system isn't the fastest (P1/200; i would prefer my G4 to run it, but w/o a working libEQ ... well ... :-)
    b) also i would like to do an alternate interface, but don't want to interfere with the existing algorithms.

    so i had some ideas:
    1) move the packet filtering stuff to a (kernel) module.
    2) put the packet analysing stuff and the calculations in a library.
    or maybe even more libraries.
    3) module support for SEQ

    what are the reasons:
    with (1) the packet filtering runs in kernel mode, so it will not get interrupted (so easily) if it "doesn't want to" and it should have more ressources availible, or have more control over them. actually doing something like ipchains was my basic idea.

    idea (2) should make it possible, to make different alternate clients, for example a C based Xlib only version. or even a
    TTY only version for very very special things.

    ok, for point (3) the idea is, only to load things that are needed.
    if i don't want the "special AC tracking and hunt down" module, but instead need the "how to kill flippy 1000 times an hour" and configure this using a file, like apache does it for example.

    additional thoughts:
    i like C++ and Qt, but they grew a lot in the last years, and IMHO a C/Xlib (maybe Xt) based solution should be more suitable for smaller machines. i know they are a bit more complicated to do, because i did Xlib/Xt programming, and was delighted when i started with Qt.

    also maybe more people could "donate" work to this project. some may like to shift the bits in the kernel, others prefer the analysis part, and last but not least some may like to work on GUI interfaces. maybe some even start to add skins to SEQ, with a site like "skins.seq.org" ... ack ... ;-)

    [putting on my fire resistance gear ... ;-)]

  2. #2
    Registered User
    Join Date
    Dec 2001
    Posts
    1,262
    I'll say before everyone else gets here...

    Its open source... drop us a line, and let us know how your "modularization" is going

    --Jeeves

  3. #3
    Registered User black.rabbit's Avatar
    Join Date
    Mar 2002
    Posts
    21
    this highly intelligent reply somehow gives me the impression you are a "on error resume next" user. and even the doesn't help it.

  4. #4
    Registered User
    Join Date
    Dec 2001
    Posts
    1,262
    No, I'm just a realist. This project is hardcore hobby work... I seriously doubt the dev's are looking to spend months on serious architecural changes for the sake of a 10% speed iprovement and a TTY renderer...

    You must be one of those programmers that says "SOAP is the next big thing, all are products MUST use SOAP now!"... then 3 days later.. "WAIT! ebXML is the next big thing, all our products MUST use ebXML now!"...

    --Jeeves

  5. #5
    Registered User
    Join Date
    Dec 2001
    Posts
    247
    black rabbit.

    The project is always open to suggestions. The ultimate decision factor of code changes being implemented is up to the project folks.

    I ran and developed showeq on a pentium 166 quite happily for a long time. At this point I doubt you will recieve much support for a C Xlib version though, atleast from me at any rate. I can almost guarantee libEQ will not be back ported to straight C.

    I think I finally have access to a GNU toliet seat I could build libEQ, I'll see what I can do.

    As to skins, I believe Qt supports a similar feature thru its Style class.

    Anything you are willing to contribute would be well appreciated.

    Fee
    Last edited by fee; 04-04-2002 at 11:23 AM.

  6. #6
    Registered User Zaphod's Avatar
    Join Date
    Dec 2001
    Posts
    648
    1) The packet filtering is occuring in the kernel using the existing kernel level filtering modules through the pcap library to maintain portability to other Unices... Then the packet capture thread makes calls to pcap to bring the captured data from kernel space to user space. We then do analysis and dispatch in the main thread. Except for having the seperate capture and main threads, this is basically also how tcpdump works. I'll let fee (floyd) respond further on this topic.

    2) Yeah, but we'd prolly still keep them in Qt. Relatively speaking it's not adding too much memory/CPU.

    3) Module support would be nice. We've actually been working towards that. We've come a long way towards seperating the GUI from the state storage and management. It's also why lots of the GUIs and state management are done in seperate classes in seperate files. We've also been working to get rid of some of the artificial interdependencies in the code base. Right now a migration to runtime loading of modules would be problematic without forcing a migration to Qt3. Which we are reluctant to force since many peoply have already had to upgrade compilers and Qt versions for ShowEQ, and I don't wanna deal with the uproar until we're ready to release ShowEQ 5 someday...

    As to speed and memory, we've come a long way. Between SEQ 3 and 4 we increased ShowEQ's speed tremendously and drastically decreased its memory footprint. We've still got things to improve upon, like seperating state maintenance from the GUI code in the ExperienceWindow, CombatWindow, and EQInterface. We also need to cleanup the handling of channel messages and support away of clearing the history (this history can get quite large over time) either on zone or via menu pick.

    If you are having memory and some speed issues, start turning off certain displays. This would have more impact but one of the developers (you know who you are) removed the runtime instantiation of the Player Skills, Player Stats, and SpawnList of these GUI; this will be fixed. The map display is has been and continues to be one of the biggest CPU sucks of the entire program. If you have a slower machine I would recommend only using 1 map, and start turning off some of the "Show" options, or turning off "Animate Spawns". This can have a radical impact on speed. After that the Spawn list is a big CPU suck.

    also maybe more people could "donate" work to this project.
    As for volunteering and donating work, I await your FIRST patch with the utmost anticipation. We are making progress on improving ShowEQ, and we do need help. It's difficult to keep up with the latest Verant changes and add features. This is a well established and "old" code base with a lot of legacy. We're cleaning it up, but it takes time and support from volunteers like yourself. Just try to make your contributions modular, with GUI seperate from state/data storage, and without tightly binding modules throughout the code. Lastly, don't use the Experience Window (or it's son Combat Window) as the basis for future design. We could also use volunteers to help debug crashes, as well as protocol and structure changes from VI.

    Enjoy,
    Zaphod (dohpaZ)
    Chief Software Engineer of the Apocalypse.
    http://showeq.doomed.to/
    SourceForge.net user: dohpaz.

    Personal thank you donations are now accepted.

  7. #7
    Registered User black.rabbit's Avatar
    Join Date
    Mar 2002
    Posts
    21
    now this _is_ a response i was waiting for, because this is something where you can start to talk about ideas and how crappy they are.

    Originally posted by Zaphod
    As for volunteering and donating work, I await your FIRST patch with the utmost anticipation...
    i will try to do my best, but i bet i will take some time before i will do something like that, because programming 5x10 at a large company isn't quite a good base to add some more hours of coding after work.

    on the other hand, doing work for SEQ would be some creative work.

  8. #8
    Registered User black.rabbit's Avatar
    Join Date
    Mar 2002
    Posts
    21
    Originally posted by high_jeeves
    No, I'm just a realist. This project is hardcore hobby work... I seriously doubt the dev's are looking to spend months on serious architecural changes for the sake of a 10% speed iprovement and a TTY renderer...
    a) i never wanted a TTY renderer ... on the other hand a pretty good idea

    b) i never said the dev team _has_ to do the changes, but i was speaking of ideas, people could talk about. and maybe if some are interested they may team up to do something together.

    Originally posted by high_jeeves
    You must be one of those programmers that says "SOAP is the next big thing, all are products MUST use SOAP now!"... then 3 days later.. "WAIT! ebXML is the next big thing, all our products MUST use ebXML now!"...
    interesting thought ... but if i would be such a guy, do you really think i would like to code in C ... wouldn't i be one of those java or C# fanatics ?

    gimme a break, this is nuts ? why can't you reply in a manner like Zaphod ? if i wanted to start a personal flame war with you, i would have gone to the "Help Desk" and asked how to install "Windows XP" on a Mac.

    i wonder if my question/ideas was/were really so fucked up ? can't have been so bad, or Zaphod must have been pretty stupid as well, to take the time to respond in such a big post ! and he knows how to kick ass is in a mannerly way.

  9. #9
    Registered User black.rabbit's Avatar
    Join Date
    Mar 2002
    Posts
    21
    Originally posted by fee
    As to skins, I believe Qt supports a similar feature thru its Style class.
    that was just a sick joke ! do you really think i want to have such spiffy things ?

    i really start to love Jeeves idea about a TTY renderer.

    Originally posted by fee
    ...I can almost guarantee libEQ will not be back ported to straight C.
    i already saw it is not C based, after i nmed it. i still hoped it is C based and "only" has a C++ wrapper in it.
    Last edited by black.rabbit; 04-04-2002 at 01:25 PM.

  10. #10
    Registered User
    Join Date
    Dec 2001
    Posts
    247
    blackie wabbit,

    welcome to the land of lunatics and insane childish taunting.

    a) i never wanted a TTY renderer ... on the other hand a pretty good idea
    i seriously hope this is joke...

    See Zaphod is a polite individual who prefers subtly as opposed to outright AE fire. Its his way. The rest of us are somewhat more... wide open...., so relax and enjoy




    Lesson 1, have a sense of humor.

    Here endith lesson 1



    Seriously though, if you submit any code in C expect it not to get used.

  11. #11
    Registered User
    Join Date
    Dec 2001
    Posts
    1,262
    I posted a perfectly reasonable response, you are the one who started with the name calling. There are too many people who come around here with feature demands... If you want changes, start adding patches instead of telling the developers what they should do for you...

    I've run ShowEQ on my Pentium 75 laptop.. is it slow? Hell yes! Does that mean the developers should spend time rearchitecting their system, and rewrite the app in C and Xlib? No! (I just chucked my book on Xlib last week, I havent looked at it in 5 years, kinda made me laugh to here that people still write using this!)

    As for the TTY renderer, here is a quote from you:

    or even a TTY only version for very very special things.
    So, lets not call it the jeeves TTY renderer....

    --Jeeves

  12. #12
    Registered User
    Join Date
    Mar 2002
    Posts
    60
    Would be cool if the thing ran faster, but then again, computers are pretty cheap these days. I think I'll just upgrade
    Say no to sig.

  13. #13
    Registered User black.rabbit's Avatar
    Join Date
    Mar 2002
    Posts
    21
    how about a C++ TTY renderer then ?

    well, let's see what i may do ...

    what i really already learned, was the (1) in Zaphod's post, because i knew tcpdump uses libpcap, but i didn't know how it works. that's why i thought an ipchains like module - even it would be sort of linux only - may be more direct.

    but fee, please don't go into those details.

  14. #14
    Registered User
    Join Date
    Dec 2001
    Posts
    247
    details?

  15. #15
    Registered User black.rabbit's Avatar
    Join Date
    Mar 2002
    Posts
    21
    Originally posted by fee
    details?
    Originally posted by Zaphod
    1) The packet filtering [...] tcpdump works. I'll let fee (floyd) respond further on this topic.
    those details ...

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

You may post new threads
You may post replies
You may post attachments
You may edit your posts
HTML code is Off
vB code is On
Smilies are On
[IMG] code is On