Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Everlong Online
#26
It loads alright after the gigantic images are cached. Personally, I would convert them to .gif format.
Reply
#27
How much b/w do you have?

1000 hits per day, 800 kb, 30 days in a month, 24000000 kb a month, 2.400 MB. That's 2.4 gig a month for the main page. If I'd leave my FF auto-refresh on, 1 hit per 5 seconds (let's take it slow) 414720000 kb a month, over 40 gigs.
Reply
#28
I got around to trimming the news section, the size is about half now. I finally made a new page for "old news". Tell me if it helps you guys out.
Reply
#29
Why're you loading the entire fucking border every page?

Set a generic background and load from there.

[Image: screen.png]

You could have simply used a single set of frames for the images, and traded out the small area around "Screenshots" between pages.

Anyway, I'm not huge on the style. It's completely over-used since I released Essence's .PSD file. Now everyone and their grandma have a parchment GUI with a textured border with a stroke and inner glow :3
Quote:Robin:
Why aren't maps and shit loaded up in a dynamic array?
Jacob:
the 4 people that know how are lazy
Robin:
Who are those 4 people?
Jacob:
um
you, me, and 2 others?
Reply
#30
Because I've looked @ essence?
Reply
#31
Overhead on objectstreams? Sure, in comparison to datastreams which are essentially just byte arrays, but use of multiple sockets per client and gzip compression streams means your packets are still tiny, and it allows you to implement a fantastically secure and structured object oriented code design.

An uncompressed objectoutputstream running on a single threaded socket is insanely faster (we are talking lightening) than vb6's winsock implementation. Also, by using this method we can simply create a new instance of the object being sent, fire it through a static factory and actually reduce server-side overhead dramatically as objects are being instanciated, dealt with and disposed of bloody quickly.

After coding the entire networking backend both ways, the objectstream design model just has so many advantages and such a tiny speed difference I just have to conclude it is a better way of handling this kind of problem.

Also, datastreams are io blocking on the socket which is fucking mega bad news, object streams are not..

I'm not trying to flame you or anything, I genuinely went out and wanted to find the best possible way of writing the networking for a java powered mmo. Just sharing my experiences.
Reply
#32
Oh and with regards to the topic, www.mirage-realms.com/oldside/ demonstrates how to use a graphically heavy layout efficiently, as well as how to create a dynamic content height and expanding layout and use php include in such a way so you only have one 'template' to edit when you are updating the layout and adding content.
Reply
#33
Coke Wrote:Oh and with regards to the topic, http://www.mirage-realms.com/oldside/ demonstrates how to use a graphically heavy layout efficiently, as well as how to create a dynamic content height and expanding layout and use php include in such a way so you only have one 'template' to edit when you are updating the layout and adding content.

[Image: 1-50.jpg]
Reply
#34
Woops, I'll fix that when I'm home. Stuck in hospital at the moment on my g1 -.-
Reply
#35
Everything ok? Hope no one is hurt :X
Reply
#36
Coke Wrote:Overhead on objectstreams? Sure, in comparison to datastreams which are essentially just byte arrays, but use of multiple sockets per client and gzip compression streams means your packets are still tiny, and it allows you to implement a fantastically secure and structured object oriented code design.

An uncompressed objectoutputstream running on a single threaded socket is insanely faster (we are talking lightening) than vb6's winsock implementation. Also, by using this method we can simply create a new instance of the object being sent, fire it through a static factory and actually reduce server-side overhead dramatically as objects are being instanciated, dealt with and disposed of bloody quickly.

After coding the entire networking backend both ways, the objectstream design model just has so many advantages and such a tiny speed difference I just have to conclude it is a better way of handling this kind of problem.

Also, datastreams are io blocking on the socket which is fucking mega bad news, object streams are not..

I'm not trying to flame you or anything, I genuinely went out and wanted to find the best possible way of writing the networking for a java powered mmo. Just sharing my experiences.

Objectstreams certainly offer a more structured approach. Sometimes I wonder if the structured approach is really worth the hassle. Do you have any code for an objectstream design? I'd really like to see it, I've been unable to find much information on this. I have done a lot of research on different design approaches, but good code isn't easily accessible.

The key word here is 'static factory', could you explain to me how your static factory works? Does each class sent over a network connection have to implement or extend some interface/abstract class? I was actually using this design pattern for interpreting packet data, so I'm kinda going in the same direction and I may consider switching to an object stream.

I understand you aren't flaming, I've been searching for the same information.
Reply
#37
Just got back from the hospital, everyone is alright! Aside from Austin, who has a horrid broken arm ^.^

I'll respond properly tomorrow, but a quick answer is yes I have a massive flow chart drawn out in our programming dept. at work of how its all set out, all the coders at work have been helping me plan and put it together so I'm cheating a bit lol. I'll see what I can do to get it to you.

And as for a static factory, a factory is essentially just a class that is fecking quick at deciding what you need. Say I get an object in on one of my streams, the factory will check what kind of object it is very quickly, for example objPlayerMove, and fire off everything I need. Its really a glorified listener (without actually listening to anything or using resources while it waits) that knows exactly what we will need to deal with each packet. So objPlayerMove arrives, my factory will go RIGHT! give me a playerMovementHandler(objPlayerMove) and return me something I can send the client to let it know we are A-OK. While you are at it, I want a new globalPlayerPositionUpdate and notifyPlayersOnscreen object too, as they are going to be used by my playerMovementHandler.

Factories are great when used properly, in this instance I am using one to create new instances of everything I will need when any given packet comes in, its like the backbone of the server. They basically will look at what you have, and give you what you need back in any given situation. If something happens and I am going to need 5 new objects because of this, my factory creates all these and passes required information onwards.

Because my socket is open, I can fire all of my objectInputStream data into my factory and it will deal with it all. No evil server loops, no 2389749823879489237489723 listeners, no overhead and no fuss. Just one beautiful aspect of java perfectly suited to the job ^.^

Anyway, goodnight xP
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)