Re: 2 Player mode

[Jens Granseuer <jensgr@xxxxxxx>]

> On Monday 09 October 2006 10:46 am, Jens Granseuer wrote:
> > It looks like to do this properly we need NetBuffer to allocate
> > memory dynamically (so we can do history->Save( NetBuffer )).
> > However, the standard STL classes (vector, string) are not really
> > suited for this purpose since we also need raw data access for
> > the SDL_net API. Do we really need to implement our own buffer
> > class? Any clever ideas?

On 09.10.2006 20:41, Henk Jonas wrote:
> Well, SDL could have a memory file class. I don't know.

It doesn't.

> But why is 
> something like the string class not usable? All you need is something 
> which grows on write and can then be read in again. When the network 
> code receives the data, it knows the size of the buffer, as it is part 
> of the header.

The one thing we need dynamicity (?) for is history->Save( buffer ),
and string could be wrapped to do that, but it doesn't support
SDLNet_Recv( socket, string.c_str(), size )...

On 09.10.2006 20:48, Dave Fancella wrote:
> Doesn't string have something like string::c_str() or something that gives 
> access to the underlying char*?

Yeah. Only for read access, though.

> Failing that, you could rip the tList class out of Armagetron Advanced.  Or 
> maybe it's tArray you want, one of the two.

Those look like simplified recreations of the STL containers. Why didn't they
just use those? For our purposes they are probably a little over the top.

> What I'm thinking is you want a class that just stores each turn internally in 
> like a std::deque or something, and then encodes it right before sending it 
> to the network.  Obviously it would decode it when it gets it from the 
> network.  Maybe that's what you meant and I"m still half asleep

We've already got the deque: it's called History. What we're lacking is a
clean way to serialize it (into memory/network).

Jens