gnelib-users — Discuss/Ask questions about GNE with other GNE users.

[GNE]GNE Guide

[Gillius <gi...@ma...>]

I've made a small beginner's guide which has gone onto the front page of 
the doxygen HTML documentation.  The purpose of the guide is to provide the 
overview of GNE so that the user will be able to understand the main 
groupings of the classes, and have a good idea of what classes to use to do 
what things.  It will tell them the classes and examples to look at first.

For those of you about to start using GNE or have just started it, give it 
a look over and let me know how helpful it was.  For those of you who have 
used GNE can still let me know what they think about it.  I appreciate your 
help on this since I cannot "test" my own explainations.

You can get the guide in one of two ways.  If you are using CVS you can 
update to the latest version and then run doxygen.  If you are using the 
last public version you can get the guide by downloading it from bottom of 
the GNE page:
http://www.rit.edu/~jpw9607/gne/

Keep in mind that documentation applies directly to the very latest CVS 
version, and although there have been lots of changes since 0.45 there have 
only been small API changes so the guide definitately still applies but I 
would refer to the 0.45 official docs for the reference.

Gillius

[GNE]Official TurboFighter site open.

[Niek A. <in...@da...>]

Hello gnelib-users,

  The Official TurboFighter Homepage is online
  and the latest alpha version of TurboFighter can be downloaded
  there. The game will be using GNE in future versions.

  Check it out at:

  http://www.turbofighter.com

Best regards,
 Niek Albers                         mailto:in...@da...

[GNE]Re: [GNEdev]GNE 45 Release Canidate 1

[Elias P. <el...@us...>]

> Please update your CVS version of GNE and run all of the programs and tests 
> and let me know if there are problems with any of the programs.  exnetperf 
> should be fine but I need to look over its code again and I am also not 
> done implementing it (ie it works for only one client now), but still 
> report issues with that other than it works for only one connection.
>

Ok, as we already talked in IRC, i get some issues with exnetperf:

That one time, the following happened:

I hit a key in the server, and it closed and wrote:

Assertion failed: connections.find(socket) != connections.end(), file src/Connec
tionEventGenerator.cpp, line 104

The client wrote this:

Socket failure: Network error when trying to write to connection.

and stopped responding to key presses.

[GNE]GNE 45 Release Canidate 1

[Gillius <gi...@ma...>]

Elias (and others),

GNE 0.45 RC1 is now in the CVS.  The code is done but I haven't updated the 
readmes and stuff.  Like from 0.003 to 0.40 this is a HUGE release.  The 
user API has not changed a lot but the GNE code that implements it is 
DRASTICALLY improved and changed.  There were so many holes and bugs in the 
old version if is wasn't ideal conditions that it was like swiss cheese.

Please update your CVS version of GNE and run all of the programs and tests 
and let me know if there are problems with any of the programs.  exnetperf 
should be fine but I need to look over its code again and I am also not 
done implementing it (ie it works for only one client now), but still 
report issues with that other than it works for only one connection.

I am hoping this new revision of the code is SERIOUSLY rock-solid and I 
mean seriously so (at least for what is implemented).  Like if your 
computer explodes in the middle of connection while the connection is going 
but the client is processing onNewConn and sending and receiving at the 
same time, everything should terminately cleanly with no mem leaks or 
crashes.

Now the event system is GUARANTEED to be only one thread accessing events 
at any time and event order is now GUARANTEED and behavior guaranteed 
rather than saying it does but in the worst scenarios it breaks down.  IE 
before if an error occured between certain lines it might cause two events 
to happen at the same time, or events to become out-of-order, or objects to 
be destroyed while other threads are executing methods of that object.  
This happens no more!  Now the API is defined and is specfic for every 
single little place and between each action what happens if an error occurs 
or some other event occurs including which events came before and which 
events follow and which objects will be destroyed and when.  If you see any 
holes please let me know.

Gillius

[GNE]New Event System

[Gillius <gi...@ma...>]

I just got through with an 8 hour code-a-thon here working on making a 
completely new event system.  Note that to the user the API to follow is 
the same.  The main difference is now that it WORKS.  It is much cleaner 
now and does a few cool things like:
  Doesn't crash.  Does what it the docs says it does.  It accessed by a 
single thread as is easy to control.

Before there was ONE event thread for everything, and events weren't 
controlled.  One thread can call one function and one thread could call 
another etc.  Sometimes three different threads could be in there and it 
was hard for the user to follow and hard for me to follow.

onDisconnect could theoritically be called before onConnect while 
onDoneWriting was being called and threads sending information while 
another tries to read at the same time.  That is no more.

There is one SINGLE thread that maintains an event queue, one thread for 
each connection.  It serializes the events and actually guarantees 
onConnect always comes once and only once and first and onDisconnect comes 
only once and only as the very last.

This has the additional benefit that GNE can process events for other 
connections at the same time AND do reading as well.  Before almost all 
events and reading was handled by the same thread.  Now it is not.

Gillius

[GNE]GCC 2.9x Support

[Gillius <gi...@ma...>]

The current CVS version of GNE has GCC 2.9x support.  I am still trying to 
decide wether to release a patch or wait a few more days and release a GNE 
0.41 (since a bit more changes have been made since them as well).

The CVS now additionally supports the two previously supported compilers 
MingW and GCC 2.9x under Linux, in addition to MSVC 6 and GCC 3.x.

Gillius

[GNE]GNE 0.40a Released

[Gillius <gi...@ma...>]

GNE 0.40 alpha has been released, and 4 months of work has happened on GNE
since the last release 0.003pre-alpha.  Almost nothing was implemented yet
in 0.003 but almost everything is implemented in 0.40.

The changlog is too big to fit into a single message, but some general
highlights:
  * Maturing of the threading and timers code.
  * Greatly expanded and tested Console I/O API
  * Nearly complete redesign to the Connection API, and new types of
Connections have been added and implemented
  * Better packaging support and directory/include structure.
  * Linux support now working and actively maintained.
  * Several more example programs, bug fixes, and more classes implemented
  
across the board.

GNE works and has been tested with MSVC 6 and Linux using GCC 3.0.2. 
These are the primary ports.  Unfortunatly ports that used gcc 2.9x do not
work anymore due to an old incompatable libstdc++.  MingW32 should work if
you get gcc 3.x for it.  Sun Solaris 8 should work now using GCC 3.x and
GNU make but is untested.

  GNE stands for Game Networking Engine and it is a high-level networking
library made in object oriented C++.  GNE is meant to handle the common
elements of any networking task and provide a framework for your game's
specific networking code.  Some things that GNE does:

  * Cross-platform multithreaded programming
  * Precise timing capabilities using callbacks in threads.
  * Multithreaded Console I/O (meant for text-based servers, do input and
output at the same time)
  * Bandwidth throttling (control and specific bandwith capabilities) *
  Packet parsing, serialization of Packet data, conversion between 
different processor formats, type checking and error detection.
  * Connections and disconnections and negotiating connection parameters *
  In the future GNE will have a list server built in similar to 
Battle.net or Half-Life where all GNE games will be listed.

  Visit the GNE website at http://www.rit.edu/~jpw9607/ and click on the
GNE link on the left for more information.  The GNE SourceForge page is
http://www.sf.net/projects/gnelib/ , where you can find mailing lists,
news, and CVS access.

Gillius

[GNE]Re: [GNEdev]GNE .4 alpha and Linux

[Elias P. <el...@us...>]

> Elias, I haven't seen you for a very long time in #allegro, so I was 

Yes, because of different time zones, and because I yet have to get used
to lectures every morning. (Right now I sleep like 8 hours, and even longer
on weekend..)

> wondering if you could help me out by creating a Linux version of the 
> makefile, if you can do that?  You don't have to test it -- I can do that, 
> but I know you will know better what to change, and I feel safe in asking 
> because I think very little changes for Linux.

Sure, I try it this weekend. The makefile.mingw should actually work, but
I have mandrake8.1 now, so it's no problem for me to test it and change
what's necessary. (in the makefile, not in the code, usually unix gcc
complains about different things in the code when using it with -Wall for
me, when I try to compile a mingw source the first time with it..)
 
> The rest of this message is just informational about what I've been doing 
> with GNE (so if you are busy you can skip past/skim it)...

[..]

Ok, sounds really good. It seems that the basic networking API will be
finished really soon now :) I think once I see it in an example which
can do a bit more than sending Hello World, I'll also better understand
what's going on :)

Elias

[GNE]GNE .4 alpha and Linux

[Gillius <gi...@ma...>]

Elias, I haven't seen you for a very long time in #allegro, so I was 
wondering if you could help me out by creating a Linux version of the 
makefile, if you can do that?  You don't have to test it -- I can do that, 
but I know you will know better what to change, and I feel safe in asking 
because I think very little changes for Linux.

The rest of this message is just informational about what I've been doing 
with GNE (so if you are busy you can skip past/skim it)...

I need to start testing the lib for Linux because I want to make sure it is 
working there before I release .4 alpha.  I've been doing an extreme amount 
of work on GNE lately.  I ran into some big problems with SyncConnection 
now, and I had to sorta restructure the API.  There have been class 
additions and deletions and some major changes that will break all 
Connection-based code.  The new event system is looking more and more like 
Java's Swing everytime I modify it ;).

SyncConnection is going to be more complex than before.  Now instead it 
will be a wrapper for Connection, because I noticed that virtually all of 
SyncConnection's code was the same as Connection, and because of the 
synchronous requirement, the code was inferior and didn't have the flow 
control or caching, since that is very non-trivial for "memory-less" 
syncronous connections.  So instead the class now acts as a wrapper, and 
registers itself with the connection you give it to become the event 
listener (events are now done through listener regististration, rather than 
overloading functions).

This has many advantages.  Firstly, the SyncConnection will actually be 
asyncronous, but appear and act fully syncronous to the user, by "hiding 
and caching writes."  It will also use the flow control.  Plus, with this 
method, there is no "conversions" taking place, and a SyncConnection can 
wrap a Connection at any time (although in practice it is best to only wrap 
it during the connection process, where it is automatically done for the 
user).  Also, the simpler ConnectionListener class where the events go make 
it easier for the user by needing to know much less internals of GNE, allow 
the user to potentally save memory as well.  Multiple Connections can send 
their events to the same listener, rather than having a child class receive 
everything.

The API is now much more robust, easier to use, and all potential flaws, 
memory leaks, and "questionable programming practices" that I could see are 
eliminated.  Since SyncConnections are meant for connecting, and they 
aren't an entity in themselves exhello will be retrofitted to use them.  
Exhello should become much simpler and much of the "bad" code (such as 
objects destructing while their functions are still running etc), will be 
eliminated.  Right now it works only because I wait a few seconds and just 
hope that everything is done by then so I can quit.

Gillius