Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  ByteBuffer allocations and object members in GLOs  (Read 983 times)
0 Members and 1 Guest are viewing this topic.
Offline c4scroller

Senior Newbie





« Posted 2006-06-28 01:16:37 »

Hello,

I have a question which I think has an obvious answer, but I will ask it anyway :-) Regarding the ByteBuffers etc. required to represent a message to be sent from server to client, say if I have a GLO which needs to send players information about other players present in the GLO (room)

* When and how should this be declared? Should I always create the buffer on the fly (e.g. with allocate), or would it be better to use an object member and therefore a reususable buffer? In the simple SwordWorld example, for instance, you do a ByteBuffer.allocate() and put() a String into the buffer, and send it, for each request. If I make it an object member (i.e. in the class definition for a GLO), won't I get problems with serialisability?

What is the right approach (or at least, what are some good guidelines?)

Greg
Offline Jeff

JGO Coder




Got any cats?


« Reply #1 - Posted 2006-06-28 01:35:07 »

Making it an object member really gains you nothing and just adds to the time to acces the object.

Keep in mind that the object is being deserialized from the store when it is used and serialized back when you are done.
Thus there is *always* an allocation of a ByteBuffer going on, the only difference is whether you are doing it or the serialization code is.

However is you DO make it part of the state of the GLO then yo uare adding to the work needed to serialize and desearilize the GLO because the serilization code is going to believe that the entire state of the buffer needs to be preserved.

So, the genral rule is the ONLY things that should be non-transient fields on the GLO are real data state that needs to be saved.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (24 views)
2014-07-24 01:59:36

Riven (24 views)
2014-07-23 21:16:32

Riven (18 views)
2014-07-23 21:07:15

Riven (21 views)
2014-07-23 20:56:16

ctomni231 (50 views)
2014-07-18 06:55:21

Zero Volt (45 views)
2014-07-17 23:47:54

danieldean (36 views)
2014-07-17 23:41:23

MustardPeter (39 views)
2014-07-16 23:30:00

Cero (54 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!