Times of War Development Team

Instead of a separate thread to check for disconnects, have something like this, in one thread:

Code:

---

if(GetData(...))
{
    //Do Data Stuff
}
else
{
    //Check for disconnect
}

---

Z.

Well the way it works is it polls the socket, it checks to see if disconnected then it checks for data, if there is data it runs a function which receives it and posts it back through the virtual functions, the only problem is the data function jamms and so i gotta make a seperate thread to control it.

2 threads per user is not gonna effect the stability as long as its restricted to no more than 10-20 users.

Grrr, sometime i run it and it wokrs fine other times it doesnt.

I trapped the error down and i know where its from. I dunno how im gonna get to fix it.

I know how that is =).

Z.

I modified the model loading code so that when it loads, it generates a scaling matrix that is applied when the model is rendered. This matrix causes the model to be 1 meter tall, wide, and deep, so that another scaling matrix can be applied on top of the first to allow for custom sizes of objects.

Z.

So basically when you import a model it's a fat short guy?? Hehe!

Exactly =).

Z.

I started in on a device remodelling tonight. Tomorrow I will finish it, so that a device can be loaded from a DLL, which means that we can write rendering plugins (D3D, OGL, Software, whatever), without modifying the engine code.

Z.

Hello there. Im back...my network suddenly appeared to work again. I have NO idea what's going on with that, but never mind. I've also ran into a bit of personal problems lately and have been stressed with school too...I am working on an exceptional hard piece for my exam..
(If you've heard it: Beethoven's "moonlight" Sonata, 3rd movement)
However. I have been composing a lot the days I've been away...My piano sonata is soon to be finished. I've started a new theme for you guys too, but the music always seems to be the same, so I'm gonna take it with me to school and see if I can get some good advices.
However...I'm back and I will be updated from now on

Excellent, if you haven't been able to review Psyvision's working on the Networking code now and doing a good job of it ;)

Today i have made a thread class which should make the new server easier to manage. I thought i had realised what the problem was with the server, but it wasnt to be.

I have been thinking a bunch about the map, lately, as I want to get that Implemented soon. I know that Sas doesnt want a really curved map, I have been thinking about going back to a regular grid, with a catch. It is very easy to make a gid wrap, as long as it is big enough to give the idea of vast size.

So, I have been thinking. Let me know your comments on what YOU want to map to look like. When you guys have done that, we can sit down, combine the things we like, throw away the things we dont, and get that done. Sound good to everyone? Ill go first =).


Personally, I dont think we require a level of detail terrain mesh. Today's hardware is perfectly capable of rendering full quality terrain, especially since the amount of visible terrain is fairly low (isometric perspective).


Z.

When released maybe, but people may want to just play and not have a fast computer. I think there should be an option, it just looks horrible in Black & White (which was a very well done game, however).

Ill place it in a DLL, with a set of interfaces. That way, we can replace it at lesiure. Besides, I dont have a fast computer (not int he least =), so if I can get it running at 10 or 12 FPS, I will be happy with the performance.

Z.

Ok, I believe that I have cleaned up the Rendering Device stuff, at last. As it stood before this renovation, there were two availible APIs, implemented with switch statments. Ewww.

Now, I have abstract interface classes, and soon will be able to load the correct definitions of these classes from a DLL. This means that someone else could write a software renderer for TOW, and it would work fine. The current classes are as follows:

Code:

---

SYSDevice : abstract main rendering device.
IVertexBuffer : abstract vertex buffer container
IIndexBuffer : abstract index buffer container
ITexture : abstract texture container (not complete)

---

At the moment, I am doing a quick hack to start a D3D Device, but it is simple to remove (2 lines of code).

Z.

Grrr, bogged down with homework at the moment.

This whole server thing is still not going, it receives data but its only on one thread. I need a demo of a threaded server if anyone can find me one ?!?!?

I got a demo for a threaded server and it works well, will get it sorted out from the poor coding structure of the demo into a better one then into the DNM.

Hey, right now I'm making the complete bare-bones (aka. not graphical) forum for us. It's black on white, normal text, but has options for polls, graphic upload, and VRML upload to show in a small window (user-defined). It'll also have administration options. Then, after I've gotten it all finished up, it will be easy to add graphics and CSS to make it a fully functional graphical forum environment, not unlike the one here.

Sounds good to me, Sas =).

Z.

Heh, I'm sure Igor would like a break in this department. I'll let you in, but the final decision is up to Igor because he's the "Senior" music creator, so to speak.

Well i got the server wokring fine, its accepting connections, now i just gotta put it into the dll and then setup the vitrual functions and callbacks and voila

The demo i will make first (hope it will be done tonight) shall be showing chat being done over the server.

Looking good Psy. Keep up that good work.

Z.

That sounds excellent. Here's a challenge for you though; can you make it do file transfers from user to user?

I got texturing done last night.

Z.

Well, one step forward, two back.

I got it put up into the sever.dll file but the callbacks form threads wont work so i gotta re-write the threading before its going properly. I noticed a few more problems that will need some playing around with before i can even start to consider file transfers / chat etc.

Got the plugin system up and running. I can now create plugins for the graphics sub system.

Z.

Cool =)

I have started on changing another test for the callbacks using a different thread creating method.

On this occasion, I agree totally!
YEAH BABY

A) My network cards have arrived, i dunno if my dad has ordered any cable to (havent opened the parcel yet)

B) I have BOTH bugs fixed. If the server is full, the user should connect as a normal user but a -FULL signal is sent and they remove themselves from it.


- Note -
This is still all in one exe and so no callbacks or anything of such has been tested. This is the next stage of fun =)

I realized something last night about the units. Since all units can mount and dismount, we may run into problems with archers. I would imagine that the standard archer unit would be equipped with a long bow for greater range. The problem comes when the units mounts a horse. It is nearly impossible to use a long bow while riding on a horse. So, as when on the ground, I would imagine that the archer would have to stop the horse completly to fire. So, I would think that we need a second archer type, that uses a short bow. It would have a shorter range, but would allow a mounted archer to move AND fire at the same time.

Z.

I completely agree.

All types of bows were not available to all nations in our past either. The longbow requires special types of trees, and the composite bow requires the horns of... I forget which animal, but it's native to Central Asia.

That should be easily reflected through unit upgrades. Also, allied nations could trade upgrades, and spies could steal them. I would imagine that, when an upgrade is complete, all current units are NOT upgraded, but any new units trained would benefit.

Z.

Exactly!

Yeah, and you can also put 'em back in to get upgraded, it will be a flat rate to upgrade to the newest level, so if you wait longer it'll cost less, but maybe at the cost of your life :)

It all adds more realism to the game you see!

I was having huge porblems with the threading of the server which threatened to mess the whole thing up. callbacks canot work from calling onClose etc becuase virtual functions cannot be static and the function theyre called from is static which causes errors.

I needed to create a class for packages divThreadPackage, the problem was i filled in the details as needed (it has divServer and an index variable) which then allow me to call the virtual functions this way and still be able to access the client (using the server and index variables).

The problem was the threadpackage class was getting mangled because it wasnt static.

All fixed now :D i have half of it done up into a new v2 dll. I can now do the other half now that this is fixed :D

The server is working almost properly, not all of the callbacks are working properly.

THERE IS NO STOPPING THIS GUY

I got all of the callbacks working :D

I also did a major up-haul of the naming system.

it was like divServer

but this is a seperate module for the thing so its now:

dnm_s_server

ie dnm = divinity networking module
s means its the server part (c for client, n for network)
the server bit is the class name so theres thread, client winsock etc

Looking good, Psy =).

I wanted to ask everyone to keep on the lookout for a texture artist, unless Norman thinks he can do it. We are going to have need of that soon.

Z.

I've posted a couple of times at GameDev but never gotten a reply.

Okay, I've done again and if we're lucky we'll be able to get someone from over at GameDev. If we're not lucky... oh well, it'll be another while :(