Retextures for earth and beyond

[Nemulas]

Don't get me wrong, because the game looks fantastic even to this date, especially more so when I override the game settings for texture filtering and such with vision, but I was wondering if anyone was working on a retexture for earth and beyond, or if such a thing is possible on the client side of things

[Slayerman]

Due to the game engine/client being so old, i doubt that we could improve the textures (more polygons etc)

We have a team looking at the graphics, but I personally think we are very limited in what we can do.

[Nemulas]

Even if texture work could be done that would be great. would be nice to see a more crisp UI and sprite effects, I figured poly count changing is probably a no go because of engine limitations itself.  But honestly. the game looks great when you force settings on with vision

 

https://dl.dropbox.com/u/52905807/overide%20settings.bmp
 

Edited December 16, 2012 by Nemulas

[Tradermagoo [GrA]]

I'm doing my best to do whats asked of me..

 

If you have specific ideas and want to share them maybe we can work them in.

 

I'm always looking for new ideas and mobs to tinker with.

 

If you watch the information on the testvid we have for setting the game up the max polygons it lists is around 29,000

 

That means everything in the screen can't exceed about 30,000 total polygons in 1 scene(aka your viewport/monitor) the average hulled mob according to 3dsmax without weapons can be 1100-1500 polygons.

 

The sector is 6 polygons and a typical ship for us is 13-1500 polygons average asteroids are in the 150-200 range gas clouds are models with gas effects.. they have polys also and so on.

 

When you have say a group of 2000 poly ships (12,000 + 6 for the sector and 12 1000 poly tengu for example you are at 24,000 remember the game has a 30,000 limit now add in ammo and beams and all the stuff going on and you can quickly hit the poly count for a sector.

 

It's why the fish bowl for example hits the limit with 2 groups and you get some serious video lag. 

 

It's not the video card's fault it's the limitations of the game engine itself.

 

Seriously to stop the lag you get in some raids try using first person or if you are a terran turn around and face away from the action.

 

As for adding more pretty this game doesn't use sprites..

 

There is no normal or bump mapping and not a lot of shiny either..

 

There is no specular highlights.

 

To say this game has rudimentary 3d graphics is generous..

 

I hope this answers some of your questions.

 

If you have more questions feel free to ask me in the game. I'll do my best within my limitations to explain this or other things to you.

[VincentTH]

Beg your pardon, but I'd rather have the devs spend their precious time fixing the annoying gating-handoff CTD/CTM/Hang failure than this.

Edited December 18, 2012 by VincentTH

[Stanig[IS]]

Beg your pardon, but I'd rather have the devs spend their precious time fixing the annoying gating-handoff CTD/CTM/Hang/Failure than this.

Honestly that issue will probably never be fixed as every time you gate you pretty much log out and back in, and that is subject to lag, connection quality, status of the login portion of the server, lost packets, and the like.  There is literally nothing that can be done to fix it, this game client is 12 years old and uses a version of direct x that is ancient by modern standards.

 

Please remember this is not a brand new game.  This game was designed to run on early versions of Windows XP and even Windows 98se/Windows 2000/ME

[VincentTH]

That is too bad!  Yes I know it is hard to change the client, but I was hoping that something can be done to fix it :-(

I am playing on Win 7, but my mate plays on Win XP-SP3, and I don't remember the game crashed that often back in Live, so I was hoping a fix from the server side can fix it!!

Edited December 18, 2012 by VincentTH

[Stanig[IS]]

Believe it or not, but when you CTD or have login issues?  Usually your machine, not ours.  Unless its a full crash or other times when everyone cant get in, of course.  The vast majority of tech support issues are fixing user side settings.

[VincentTH]

Sorry to hijack the thread, but since there was a question for me, so here is:

 

- It looks like that it mostly __hung__ at the galactic map (90%) when the server is busy (Load above 60%).   It never crashes.  The other 10% are split between CTMegan (5%) and last-but-not-least, connection to server loss (5%) (i.e. the client seems to be running, but clicking on the map does not get the route traced, and your form-mate cannot see you).  The lastest form of the handoff loss just happens within the past week.

 

Notes:

 

- The problem seldom happens when the load at the server is below 40%.

- My mates and I are playing on the same room, so I can tell that the slower the PC, the more likely that the handoff failure would happen.  By slower I mean, it takes longer for the client to display the galactic map, i.e. how fast it receives the handoff from the server.

- Packet loss do happen, but the client server connection uses TCP (according to Kyp), so the sender of the handoff (the server) handles the retry automatically.   Kyp did say that some router just drops the connection from the client ends, but I cannot confirm that given that several PCs share the same router in my setup.

- It is not due to multiboxing.  My desktop (i7 950, ASUS Sabertooth) running a single client, have this problem more often than my laptop which has boxing (ASUS G74SX i7 2630QM)

Edited December 18, 2012 by VincentTH

[Stanig[IS]]

Master handoff/loss of packet.  Like I said, you actually "log out and back in" every time you gate.  If its a heavy traffic time, the chances increase exponentially how often a packet will miss.  Those are your loading screen problems.

[C Del[IS]]

Server devs almost never muck about with graphics stuff, it's not usually within their scope, so don't be worried about graphics work diverting attention from server development.  Unfortunately, the client is the real limitation here.  I found, when I replaced the texture used for the environment shield effect, that the client will only accept textures up to a certain size (for effects), which I believe was 256x256 px.  We can still try and improve things, but there will always be limitations.  I would love it if we could roll a DX11 client with all kinds of prettiness, but that would take a long time and a lot of people =(.

[Kyp [LDEV]]

Something like that, the stations use TCP (or did at one point) but the rest of everything is UDP. This we found was a necessity because due to the nature of TCP, we would have regular hangs due to waiting on confirmations and other things. It caused lag for the server that way.

 

There is a disconnection and reconnection between each sector, and as the communication must be UDP for technical reasons, this sometimes means that packets will drop and they are not requested again, if enough of them do this while you're trying to connect, the server will drop you as idle. If we could switch to TCP we could eliminate this, but it wouldn't work the last time we tried and as the population went up it made for more and more lag. 

[efialtis]

I really was hoping for a possible improvement in the login/logout portion of gating/docking causing the hangs in map screens.

It seems to be more evident when the server is under heavier load but its not absolute.

It seems to affect me more when docking/undocking than gating. Don't know if there is something different in the process or it has to do with capacity between sectors/stations.

Oh well i've lived with it for a long time to let it drag me down now :)

[Stanig[IS]]

Believe me I think we all have been wishing it was different, but from how Kyp just described it, its a choice between:

 

- Occasional Disconnects/hangs as server load increases

 

vs.

 

- Horrible unmitigatable lag resulting in performance suffering as load increases.

 

Tough one to swallow either way.

[C Del[IS]]

Believe me I think we all have been wishing it was different, but from how Kyp just described it, its a choice between:
 
- Occasional Disconnects/hangs as server load increases
 
vs.
 
- Horrible unmitigatable lag resulting in performance suffering as load increases.
 
Tough one to swallow either way.

This is essentially correct. The real middle-ground solution is a reliable-UDP system, which is already in place to some degree. I'm not familiar enough with the handoff code right now to say precisely what the problem is, but I suspect it may have to do with the fact that you're changing ports between sectors/stations, so it's hard for the server to tell if something goes wrong between sectors - reminds me of the comms blackouts they have when spacecraft re-enter the atmosphere or pass behind the moon.

[VincentTH]

It can be improved even if the server uses UDP.  All it takes is a few tweaks of the handshake between the server and the client, and add some retry mechanism and timeout, plus a sequence number to guard against duplicate request/ACKs especially when UDP is used.  For example (I don't know how complicated the handoff codes are (I bet it is), but a simple handshake with retries look like):

 

- CLient: Send gating request (with seq #)

                                    - Server receive gating/docking request and start handoff.  Wait for client ACK

- Client wait for 5 secs, if it does not receive the ACK from server, increment seq# and resend the gating/docking request.  Wait for handoff for 20 sec

                                    - Within say 15 sec, server keeps sending handoff start request

- Client ACK the handoff if received, otherwise if 20 secs have passed, display an error message and go back to login prompt.

                                   - Server drops connection if 15 secs have passed.

[rodsmith3510]

It can be improved even if the server uses UDP.  All it takes is a few tweaks of the handshake between the server and the client, and add some retry mechanism and timeout, plus a sequence number to guard against duplicate request/ACKs especially when UDP is used.  For example (I don't know how complicated the handoff codes are (I bet it is), but a simple handshake with retries look like):
 
- CLient: Send gating request (with seq #)
                                    - Server receive gating/docking request and start handoff.  Wait for client ACK
- Client wait for 5 secs, if it does not receive the ACK from server, increment seq# and resend the gating/docking request.  Wait for handoff for 20 sec
                                    - Within say 15 sec, server keeps sending handoff start request
- Client ACK the handoff if received, otherwise if 20 secs have passed, display an error message and go back to login prompt.
                                   - Server drops connection if 15 secs have passed.

LOL sounds like we have a volunteen who even seems to know what he's talking about.

[C Del[IS]]

It's supposed to be somewhat like that already.  I'm not sure where exactly the problem is right now - I haven't had time to look.

[SiSL]

I don't know if any of you took a look at Galaxy On Fire 2 HD (for PC)

 

But it has really nice textures that "might" be used in E&B...  Especially I like the planet & station textures...

Edited December 23, 2012 by SiSL