What was the change this time?

[QuerySEQ]

#1. should have been code information, not transmittable packets. Each render request goes through the same old VESA command structs, (why? I don't know.. with the new particle engine changes, I don't see why regular VESA calls are made)

Its not like I am a rocket scientist eithere.. LOL. The calls maybe just for the introduction of a request and not actually used. (MAN do I wish I could get the source for EQ.. LOL)..

#2. Yeah.. that looked a little lame.. What I meant by that, is adding those new features they need to make changes to the .exe and the Globals. The Engine Drivers for the added textures both new, old and revised. Why? I believe it was nVidia that made that happen with their code drivers, so did ATI and other Video Card manufacturers. The particle engine in EQ and the DX driver that runs it, are proprietery based, that means that each change or addition you give to the game, need to be supported by the video drivers. the eqdx driver gets changed alot, to "augment" the Video Card's native driver. Thus, when they add specific graphics changes to the game by adding to the globals (.s3d) and new textures, they usually ( not always ) have to make changes to the EQDX driver to support it.

Particle Engines and Textures not properly "parsed???" or optimized.. (or whatever) could be the cause for much of the Graphics Lag. Even people with ATI Radeon's with 128mb to GeForce 4's with 128, see these little "quircks".

Turning off the models and particles help alot, so it just is something that I think they are working on. Re-Organizing the CODE to make room is more than likely what is "breaking" SEQ.

SEQ relies on certain "constants" in order to function. Since EQ is very dynamic in its changes, making even a code placement change, will "break" SEQ. ( Actually, SEQ is not broken, it just is looking for a particular thing where it USED to be and not finding it.) As well as not seeing the compression etc...etc..


Alot can be learned by these new and upcoming changes. I look at the information I have gathered, and have decided that MAYBE, making a Module based SEQ ( where structs are cased in modules ) may allow updates to be resolved easier. Sort of like the old ".INI" features that you can make in the eqclient.ini..

Do you think?

[high_jeeves]

QuerySEQ: You are way off base here, NONE of the changes that are video related effect ShowEQ in any way.. I didnt even follow what you are talking about with relation to particle systems, and VESA calls with respect to ShowEQ..

1) Umm.. EQ doesnt make direct VESA calls.. actually, nobody on the windows side uses the VESA standard to do any graphics related operations..

2) The EQDX is more than likely a graphics abstraction layer that is used by EQ, NOT A DRIVER.. IT HAS NOTHING TO DO WITH DRIVERS. It probably contains some alternate paths for rendering on different platforms, but the core reason for it is more likely a legacy one: to allow for seperate pluggable DX and Glide renderers.

Turning particles off helps alot, because particles are all (by nature) alpha-surfaces, which are expensive on most video rendering hardware. Turning models off helps alot because your video hardware has to translate, light, render, and rasterize fewer polygons per scene. These dont have anything to do with ShowEQ. Changing these things doesnt effect ShowEQ in any way.

The only thing ShowEQ depends on to work are two things:

Packet structure
Encoding scheme (to include opcode scheme through compression/cyphering)

When either these two things change, SEQ will break. Making SEQ more modular will not change this in any way, shape or form.

[cbreaker]

Ok ok ok let me try explaining why SEQ is broken. I know nothing about EQ opcodes or the packet structures, so I'm obviously qualified here.

#1. Old floppy drives cause "video lag" due to a misuse of the flux capacitor. SoE is trying to reprogram the mouse to handle this, and thus SEQ can't decode any more packets via the USB interface.

#2. On most networks, namely token ring networks running the ChaosNET protocol, SEQ has trouble detecting your EQ session since the last patch. This is being worked on by the developers using Wang mainframes running VMS. Since this problem affects 99% of the SEQ users, it is a hot item.

#3. Since the video card obviously handles all the network traffic, nVidia and ATI are also jumping on the "break SEQ" bandwaggon. Recently they changed the way UDP works between the keyboard and the monitor, thus causing yet another headache. Those of you with Matrox and 3DFX cards are unaffected by this.

[high_jeeves]

Hahahaha.. lol cbreaker..

I hear that upgrading to USB 2, and changing your video card to a Voodoo2, has resolved all of ShowEQ's problems.

--Jeeves

[QuerySEQ]

Okay.. I wasnt talking about SEQ guys.. LOL.. I was talking about EQ. My Bad..

The changes on EQ and how some affect SeQ, and how others change EQ too.

the VESA calls are still there. ( in EQ) not SeQ.. SEQ just reads the EQ box... so I know Video, etc.. have very little if ANY bearing on SEQ's functionality.

Aye.. I know that no one in the Windows environment uses VESA/Legacy, thats why I stated I didn't KNOW. I will have to play with ASM alot more to understand more about it. But, I am terrible at the interpretation. I'll see if I can grab the MX BX and CT's and display them here so someone can tell me what I am looking at. It reminds me of the old DOOM and DOOM2 FX, MF stuff. Which, from my limited understanding were the VESA calls to the wonderful Stealth24 type video cards, STB Nitro's, ATI Rage's those wonderful Matrox cards (*cough*, *cough*).... LOL

Anyway.. Thanks for the clarity

[high_jeeves]

I dont understand what your hangup with VESA is.. try using VESA in a windows environment.. you will immediately get a protection violation. All graphics related stuff goes through DirectX, and from DirectX to the video drivers.. trying to use VESA would break the Windows HAL, and cause bad-bad-things to happen...

VESA is used for DOS games, not windows games, period, end of story.

--Jeeves