Starting learning openGL/GLUT or something O_o

Maz · Post by **Maz** » Thu Jun 14, 2007 14:52

No Problem Paggy

Actually, there's nothing much to look

Pager · Post by **Pager** » Mon Jun 25, 2007 4:02

Hey Maz, isn't there a built in function in glut that allows you to draw a circle? I think there's one for a sphere, in fact I'm sure of it...that would save you some code in your "make ball" function...

Also, the question about the framerate or slowing down the code and having to use unix...well, I seem to recall writing a model of the solar system in which the planets moved at different speeds, and slowing them down was a nightmare, but I think we just basically froze the code for the redrawing of the spheres, for relational times to each other, I seem to recall spending hours converting the speeds of the planets in comparison to pluto...I'll see if I can get a hold of that code to show you what I mean...

But so far it looks decent, keep it up...I haven't done any coding like this in a while, so I'm a whole lot of rusty...

Maz · Post by **Maz** » Mon Jun 25, 2007 12:12

Thx Pag

I have not done a thing in a week or so, (coding related), and before that I just had other projects on mind for a few days...

I had a week off from work, we visited some friends ~100kilometres orth from where I live, then we spent some days on a summer cottage having our midsummer festival and so on...

But I guess I'll return to this GLUT thing soon(ish)

Especially now that my enthusiasm towards learning how to create linux kernel modules has lowered a bit... (after crashing the kernel for a few times, and (accidentally) overwriting a memory area of an old soundcard...)

And yes, there's lots of room for improvements in my implementations, but those are easyish to fix and improve, after the overall structure for the program is decided

Maz · Post by **Maz** » Wed Jun 11, 2008 8:53

It took a little longer than expected... But I decided to continue this journey

I more or less scratched all previous ideas, and did some new planning as roughly explained in this post:
http://curlysworldoffreeware.com/viewto ... 5712#25712

I may later post a zip with the stuff I've written this far

Pager · Post by **Pager** » Sat Jun 21, 2008 8:41

I found your old version on my PC the other day and was wondering whatever happened to this project, thanks for the update Maz, can't wait to see what the newer versions have in store...

Maz · Post by **Maz** » Wed Jun 25, 2008 1:30

Well, this is actually a mess. It was last compiled on Windows machine, with DEV-CPP IDE (freeware

)

But it was not runnable back then, I just wanted to get rid of a few syntax bugs back then. After it, a lot has been done, and many parts of the code are still same as in first test versions which relied upon totally different ideas... So it is a mess. It wont compile, and it is hard to know what I am really up to.

Most recent things are the network related files, but those are not even nearly ready. Anyways, since Pager asked for this, here it is.

Note that GLUT/openGL part of the code are not really even started yet... Basically I try to build system which calculates ball and plate's positions in 'server process', and means to fetch that data at client side (in order to draw the situation).

My main concern at the moment is:

How to implement the position information delivery reasonable? Obviously the easiest approach would be the client requesting data from server before drawing a frame, but I am a bit nervous about the amount of traffic it generates... Another option is to make server to send the information only when ball reflection/speed or plate direction/speed changes, but that would require some position calculation algorithm to be implemented on client side too. Also synchronizing clocks between server and clients might be an issue...

Maz · Post by **Maz** » Sat Sep 20, 2008 13:56

once again I returned to this.. It was tough after so long delay, I could do nothing but keep saying: "What have I been thinking of...". So at this time there's not really much of anything new done in this version, I just ironed out compile errors with DEV_CPP (didn't try with gcc yet). So now it compiles, but client stops right after start since socket cannot be connected to server - even though it seems the server is listening. Well, it is probs because so much is not yet done.

Well, anyways, I updated the zip in abowe post.

Maz · Post by **Maz** » Tue Sep 23, 2008 22:07

Yet another version. Does not even compile.

Maz · Post by **Maz** » Sat Sep 27, 2008 1:00

This compiles with Dev-Cpp. And it even manages to establish the connection between server and client exe

(but nothing graphical in there yet, just some prints related to handshake).

Maz · Post by **Maz** » Sat Sep 27, 2008 23:43

I am stuck. I cannot do a decision which I should do in order to proceed.

Whether to make the server part of the game simple by allowing a server to handle only one game at a time, or to try to make it complicated, and allow it to handle many games simultaneously?

This affects on what kind of data storage I need to build, and how will the server calculate the position updates etc.

If I do it multi game server, it wont be good for running many games unless the underlying Hw is superb. (For example threaded server as it is generates overhead (context switches), and the planned messaging system is too heavy. But options Eg. asynchronous sockets and client side position calculating, client and server timing synchronization etc. are too big tasks for such a eternity project this seems to be...)

So, simple and 1 game/server, or harder to do - badly performing server able to host many games at same time? Well, I bet Hamlet would've been puzzled

Maz · Post by **Maz** » Mon Nov 03, 2008 21:11

Well, again I changed my plans.

I decided that instead of the clumsy singleton cpp class keepinge up the data storage, I'll just write a simple circular buffer where server writes the positions etc. all the time, and where the clients query the data when they need it. Server will be just a big calculation loop, keeping track of positions and later possible random events.

Nice idea, but when will I have something actually done?

Maz · Post by **Maz** » Sun Dec 28, 2008 19:58

plah plah plah. I just hacked the code and makefiles so, that linux compilation seems to work. However all datastructures etc. should be replanned and redone. I've forgotten what I have been thinking when I last time touched this :/

Maz · Post by **Maz** » Mon Jan 05, 2009 0:41

updated. started reworking data storage structs.

Maz · Post by **Maz** » Mon Jan 05, 2009 11:30

Just a update on what's going on with MazPong (as if anyone was ineterested

)

Actually... The data storage is a mess. (and as always, it is the key of operation).

I've pondered this for a while, without getting any reasonable conclusion. Just to clarify how things have went to this point...

Firstly I started writing this game as a game to be played on one computer only. Hence I thought that graphical client drawing things, and engine calculating positions of balls and pads would reside in same process. Hence I thought of using C++ singleton for data storage.

Later I decided to make this a network based game, where independent server process would take care of calculating positions, and each client being own process accessing to this data via sockets. Hence the CPP singleton lost it's meaning.

I was thinking of creating a ring buffer, where server would update data continuously, and from what the clients could read it. But but... Why to use ring buffer? Do we need the old data anywhere? No. The current situation is only relevant thing.

So currently I am just going to create mutex protected global structs for data storage on server, and decide the storage format on client later. I may also change the server storage later, if globals seem like a bad idea.

I am now pondering the time calculation. I am tempted to go through an easy way, of having a 'tick process', which just increases a global tick number for every 10 millisec, and base the timing on that. Easy way to do this with decent accuracy, would be to make individual thread which just loops through sleep'N increase number procedure. However the implemetation of sleep may not be that accurate on non realtime machines... I am tempted to use SCHED_FIFo scheduling for this ticker process, which would make the accuracy decent enough. However that has it's own stability issues, and additionally requires running the server with root privileges... And I have no idea if SCHED_FIFo is implemented on windows... And who want's to run my neetwork pong as root? Any volunteers??

on the other hand, I am not expecting this pong to be ever run by anyone. (or I may do that if I ever can make it through

)

Post by **Chroelle** » Mon Jan 05, 2009 11:36

I follow Mazpong from time to time, so dont worry that noone follows your progress.

Maz · Post by **Maz** » Mon Jan 05, 2009 23:50

Today I felt like writing MazPong.

Server side is now slowly taking it's form, what comes to handshaking and data serving for clients. I now know how I'll do the mainline in this.

serverStartup.c and pong_server_accept_client.c files will be playing the big role, rest will just be implementing functions. Now I like this implementation concept, (CPP like C

).

If I only will have some time in next few weeks (before I forget what I've been doing), I may actually have something done

And new revision:

Maz · Post by **Maz** » Tue Jan 06, 2009 23:49

first (really working) draft of server's handshake with client (and really collecting and saving the client's information) is almost written. (Yea, but I haven't tried to compile it in a while..... :/)

It lacks proper data struct cleanup functionality for disconnecting client/ending game, and good method to detect and inform to others about problems with a client. Also the last steps in handshake skenario are not yet done (receiving and handling the join req, and preparing & sending the start_msg with initial data). But that last step requires me to plan the format of datas to be actually passed to client... It is area which I have quite completely neglected this far, since I should really start thinking how the client works :/

Maz · Post by **Maz** » Tue Jan 20, 2009 22:36

It compiles on linux, but.. Well, there's lots to do

Whole client part should be rewritten, and so should part of the server which calculates positions && updates em. I also believe I should somehow manage to handle the effects of network lag.. But that will be worried later ... a lot later with my speed

But anyways, it compiles on linux again

Next thing will perhaps be restructuring the code... I believe I'll create src folder containing folders, exe (or bin), server, client and common, and place relevant files under correct dirs. It naturally means some changes in make system, but I don't really care. I should also browse through all files, and calmly discard/rewrite the old code, and rename files which have confusing names

After that I (and possibly even someone else) may be able to follow the code

Anyways, updated version once again

Pager · Post by **Pager** » Thu Jan 22, 2009 5:24

Cool, will see if I can get it to compile under windows.

You know...after using UNIX to develop over the past few months, I find it very difficult to try to compile in anything but unix...

Maz · Post by **Maz** » Fri Jan 23, 2009 12:11

Actually, if you have correct libraries installed, it should compile on windows, when:

1. uncomment TGT_oS=WINDoWS and comment TGT_oS=LINUX from Makefile.
2. Set include paths correct according to your environment.

You can get the needed additional libs at least by installing Dev Cpp, and using it's pkg installer from help menu. (community devpacks at least did contain all needed libs). But you may want to wait untill I clean the obsolete things from package, and clarify filenames && change the folder structure. I must also clean the different definitions written in here and there...

But after that is done ... welcome to write the game with me