TA3D 0.4.2

Post by **zuzuf** » Sat Mar 15, 2008 2:29 pm

It's out

,

with some bug fixes since RC1, have fun !!

Balthazar · Post by **Balthazar** » Sat Mar 15, 2008 4:10 pm

Yay!!!

REVENGE · Post by **REVENGE** » Tue Mar 18, 2008 11:30 am

Hmm. I was testing campaign, and noticed that on the second arm mission, the mission was victorious immediately at the start.

REVENGE · Post by **REVENGE** » Tue Mar 18, 2008 11:33 am

Also, please add an option for right click movement and commands. Playing it on left click is very unnatural.

Also, it appears there's no way to configure teams...

Post by **zuzuf** » Tue Mar 18, 2008 11:53 am

You're right, this is still lacking.

Teams aren't implemented because there were no easy way to test it before we got AI so now we can implement it

It's the first release with campaign support, so a few things may not work as expected (we couldn't test all the missions ...). Thanks for reporting

REVENGE · Post by **REVENGE** » Tue Mar 18, 2008 9:11 pm

zuzuf wrote:You're right, this is still lacking.

Teams aren't implemented because there were no easy way to test it before we got AI so now we can implement it

It's the first release with campaign support, so a few things may not work as expected (we couldn't test all the missions ...). Thanks for reporting

No problem, keep up the good work!

I think one area that needs to be worked on in general is interface. Some things are quirky, such as mouse sensitivity not behaving as it would in Windows and the inability of factories to issue guard commands, in addition to having to manually select guard.

tobing · Post by **tobing** » Thu Apr 10, 2008 7:53 am

Hi all,

being new here, I'm trying to compile this from the sources. Using MSVC 7.1. Well, the existing documentation is not exactly helpful, so I'm here asking.

What is glew.h? That file is expected in tools/win32/include/gl/glew.h so what library is this and where do I get it?

I'm an old-time fan of TA, played a lot back then, but then I got involved in other games. Well, I'm happy to see that TA is still living! So maybe I'll be able to contribute a little something, depends on how I get this compiled and running.

I'm german, so maybe I will be able to add some german texts as well...

Post by **zuzuf** » Thu Apr 10, 2008 11:10 am

Hi,

the required files are on our svn repository:
svn co http://ta3d.darkstars.co.uk/TA3D ta3d
you can also access it through a web interface:
[url]http://ta3d.darkstars.co.uk/websvn/[url]

they're lacking from source packages because we currently use mingw32 to build TA3D, but it should also build with msvc (maybe you'll have to fix a few build errors since it hasn't been built on msvc for a year now).

If you want to contribute, we would be glad to welcome you in the team

tobing · Post by **tobing** » Thu Apr 10, 2008 11:34 am

Thanks for the warm welcome. I just found glew on sourceforge and downloaded the current version. I'll see how that works...

tobing · Post by **tobing** » Thu Apr 10, 2008 12:31 pm

Well well. So that one works now, but here come some more severe issues:

1) Function _splitpath_s does not exist for MSVC 7.1. I guess that it should be possible to use an allegro function for this? Like get_filename, get_extension, make_relative_filename or similar?

2) There are many warnings about mismatches between signed and unsigned types, especially in comparisons. Most of these are not particularly severe, but simply annoying, because many warnings always tend to overshadow the few severe ones.

3) There are many instances of warning C4258: 'cur' : definition from the for loop is ignored; the definition from the enclosing scope is used. Which gives a hint that some variable name has been reused in a more inner scope, like a for loop. This should be avoided because it's error prone...

So, to continue I would need a replacement for _splitpath_s: this is used in stdafx.h, so nothing actually compiles because of this missing function. Hmm.

Edit: compiler does not complain, when I use _splitpath instead. But now things get tougher:

4) there are a lot of calls that lead to error C2668: 'sqrt' : ambiguous call to overloaded function, where instead of sqrt it also shows atan2 and similar calls. This may be due to allegro's fix type, not sure.

5) MSVC does not have unistd.h

6) MSVC does not have a definition of error_t, fopen_s, _vsnprintf_s, _TRUNCATE, strncasecmp: some of these seem to be new in MSVC 8. Hmm.

Balthazar · Post by **Balthazar** » Thu Apr 10, 2008 1:05 pm

Well, not so long ago here was Cire, who worked on TA3D in MSVC, but he is busy now, and now only Zuzuf could help you with this. Wait a little.

tobing · Post by **tobing** » Thu Apr 10, 2008 1:26 pm

No need to hurry.

Right, Cire has made a lot of comments which refer to MSVC porting. But as I see it, many of these issues may be due to the fact that my version is a little too old. Have to think of what the right way to go is, maybe use MinGW for this? Or try the new MSVC 8 SP1? Or stick to the binary distro and write some german texts into the relevant files? Or would it be a desired thing for this project to have it compile and run with MSVC 7.1?

Post by **zuzuf** » Thu Apr 10, 2008 2:32 pm

It's a good thing to support various compilers, it can help finding and fixing bugs. But since I am using Linux I don't have msvc (even if it could be installed through wine, but I am not sure about that ) and it's much easier for me to use mingw32 since I can crosscompile TA3D from Linux and further test it with wine (hopefully wine is good enough to make it run correctly) and when it's not enough we have windows testers

.

Doors also makes win32 packages with all the mingw32 environment required to build the game, you can start with that:
http://ta3d.freedoors.org/ (NB: there is no package with current SVN since it doesn't build on win32 because of new socket classes).

Beware that mingw32 and msvc won't build exactly the same code, mainly because of FMOD binary compatibility (mingw32 uses the C interface whereas msvc uses the C++ one).

PS: Cire won't be there for some time because of personal problems ...

tobing · Post by **tobing** » Thu Apr 10, 2008 2:43 pm

Hmm.
I have the 0.4.2 sources... which is not a good starting point for making changes... should get SVN head, but if that doesn't compile on Win32, maybe it's better to wait a while, until that's completed (I assume that this is some work in progress?)...

What about all these warnings I get? Would you prefer to disable them or rename variables at the places where conflicts are reported? There are many dozens of these...

I have seen the packages by Doors, but I have some version of MinGW installed, so I'm not sure if that works well together. Usually, when I try to get something like this running for me, I always try to build everything locally. That makes some effort, obviously, but when I'm done, I can debug into all and every function call, which is something I really like when I want to work with something.

As a side note, for my own game project, I had some struggle to get all of allegro, allegrogl, guichan, lpng, lzip, freetype, glyphkeeper, openlayer and so on up and running, but now I'm very happy with all that, and I was able to contribute to some of these other projects. Well, it's mainly a matter of taste and liking, so for me, this just means that I prefer source code over binary code.

Post by **zuzuf** » Thu Apr 10, 2008 3:15 pm

tobing wrote:Hmm.
I have the 0.4.2 sources... which is not a good starting point for making changes... should get SVN head, but if that doesn't compile on Win32, maybe it's better to wait a while, until that's completed (I assume that this is some work in progress?)...

Currently WIP brings only networking code which isn't finished yet, it's in a very early stage of development. So if you want to start looking at the code you should start with 0.4.2 code since networking code is very likely to change soon.

tobing wrote: What about all these warnings I get? Would you prefer to disable them or rename variables at the places where conflicts are reported? There are many dozens of these...

There are a few warnings that show only with some compilers, but we should fix some of them. There are also some warnings (like putting -1 into a uint32 variable ...) which are not a priority but you can start fixing them if you want, it'll help you discovering the code.

tobing wrote: I have seen the packages by Doors, but I have some version of MinGW installed, so I'm not sure if that works well together. Usually, when I try to get something like this running for me, I always try to build everything locally. That makes some effort, obviously, but when I'm done, I can debug into all and every function call, which is something I really like when I want to work with something.

According to Doors, you can have several installations of mingw32 but of course this is a good thing to understand how all this works.

tobing wrote: As a side note, for my own game project, I had some struggle to get all of allegro, allegrogl, guichan, lpng, lzip, freetype, glyphkeeper, openlayer and so on up and running, but now I'm very happy with all that, and I was able to contribute to some of these other projects. Well, it's mainly a matter of taste and liking, so for me, this just means that I prefer source code over binary code.

You only need to install Allegro (>= 4.2.2), AllegroGL(>=0.4.3 but should build with any 0.4.x with only graphical bugs) and FMODex, other libraries such as jpgalleg (because of a bug fix for 64 bits systems) or lua (because there is no standard shared library for lua).

And you can always get more from the source than from binaries

tobing · Post by **tobing** » Thu Apr 10, 2008 4:19 pm

Do you have any written coding conventions?

When I make changes and want to submit them, what format would you prefer?

I can't find the SVN data to get from the depot, could you post that or direct me to the right place?

Post by **zuzuf** » Thu Apr 10, 2008 5:45 pm

svn is there:
svn co http://ta3d.darkstars.co.uk/TA3D ta3d (commandline to grab it with svn)

you can get it with your web browser too:
http://ta3d.darkstars.co.uk/TA3D

if you still can't get it, I can send it by mail (it's around 10Mo)

You can send your modifications in one of the following formats:
*.zip,*.tar.gz,*.tar.bz2,*.7z,*.rar or even *.tar but this isn't compressed at all

Doors · Post by **Doors** » Thu Apr 10, 2008 5:57 pm

[quote="tobing"]
I have seen the packages by Doors, but I have some version of MinGW installed, so I'm not sure if that works well together. Usually, when I try to get something like this running for me, I always try to build everything locally. That makes some effort, obviously, but when I'm done, I can debug into all and every function call, which is something I really like when I want to work with something.
[/quote]

[quote="zuzuf"]
According to Doors, you can have several installations of mingw32 but of course this is a good thing to understand how all this works.
[/quote]

The ability to run multiple copies is single largest reason I use Mingw instead of Cygwin. With Cygwin you have registry entries for Mount points meaning if you want to have multiple copies you need to edit the registry. With Mingw it builds the environment locally on launch.

I run around a dozen installs of Mingw for various projects with each of them setup uniquely. Use only one at a time though, trust me.

As far as my all in one setups go they contain everything presetup and ready to compile when you get done extracting. If you use a drive letter other than C:\ then some adjustments will be needed. The details are on my page.

I will be slightly redoing my package so it installs to 'ta3d-dev' instead of to 'mingw' like it does now in order to move it to my development drive from my experiments drive, the new default extract will be 'c:\ta3d-dev'. I will also be making a few maps to go in the archive so it will contain the demo materials and a few maps making it a compilable & playable package all in one as a standalone development environment for win32.

zuzuf is of course welcome to whatever he wants out of it for the linux or other crowds.

P.S. - Having alot of fun trying to get this playing on Reactos to.

tobing · Post by **tobing** » Thu Apr 10, 2008 7:05 pm

zuzuf: Thanks, got this into TortoiseSVN and copied the depot. When I eventually have anything to submit, I'll send you either the modified source or a patch to apply to the depot, whatever suits better. Or both.

Olof, the chief developer of guichan, always prefers diff files to easily submit a patch into SVN.

Doors: So will you upload a new package that I can download later?

I'm not very familiar with MinGW, but I'm learning. At some time in future I want to see how that works with Eclipse, but I'm quite busy these days, so that has to wait a while.

I see that you made af ew changes to jpgalleg, to fix something? With allegro 4.3.10 jpgalleg is part of the allegro distribution and resides in the addons directory. So maybe it would be nice to contribute these fixes to allegro 4.3.10? That's the version I'll use for my compiles, as well as the included allegrogl 0.4.4 (in fact, I'm using the SVN head in both cases).

Post by **zuzuf** » Thu Apr 10, 2008 7:18 pm

I only use stable releases from Allegro & AllegroGL. As far as jpgalleg is concerned I notified the author there was a bug but nothing happened, at least there was no release with the fix, that's the reason why jpgalleg is included in TA3D ...

Concerning your modifications, I prefer you send me the files that changes, with a small description of what has changed, only for some a the first times, then I'll give you developer access to the SVN, but first I want to check your code to make sure it integrates well with the rest of the code (I don't expect you to read and understand all the code in a few days ...). I prefer the whole files because sometimes I make modifications to some parts of the code and I cannot always connect to our SVN repository (from university it's firewalled

), but if you don't edit the following files, you can send me only patches:
menu.*, network.*, socketclass.*, ta3dsock.*, well everything related to network in fact since it's what we're working on currently

Doors · Post by **Doors** » Thu Apr 10, 2008 8:14 pm

Doors: So will you upload a new package that I can download later?

---
It will hopefully go up this weekend along with notes on my page.
I am currently doing data recovery for a very anxious customer on both of my development machines. The twerp who made the networkable dynamic disk patch for win32 needs to have a creative fate made just for him. One drive letter, two machines on a network, this is so much fun I could just #*#^ @$&*( &$%#(@&.
So I may be a little behind schedule.
---

[quote='tobing']
I'm not very familiar with MinGW, but I'm learning. At some time in future I want to see how that works with Eclipse, but I'm quite busy these days, so that has to wait a while.
[/quote]

---
No idea on Eclipse I don't use it, Played with Google android thingy but decided that Java is just to weird, I prefer assembly or pascal.
I am playing with code blocks and a few others but the whole visual layout stuff is still not my thing.

Mingw is Cygwin recompiled to be native on win32, no more cygwin dll, the advantages are obvious.
Anyway the 'ta3d-0.4.xxx' directory under home will be to play with the demo files already in place & the ta3d directory will be for programming and compiling.

My hope is take advantage of Mingw's local nature to let someone play the game only or develop if they want all in one package.

tobing · Post by **tobing** » Fri Apr 11, 2008 6:46 am

Customers first! No need to rush. Good luck for the data recovery...

During the weekend, I'll be quite busy on my own, so I have to see what I can do.

Well, you can get very much used to visual layout when developing. I'm using MSVC for 10 years now, versions 6.0, 7.0 and 7.1, and we're about to move to 8.0 but hesitate, because that version does have some drawbacks. So that's why I keep an eye on Eclipse, and on Code::Blocks, now that you mention it. They did make some progress, didn't they?

I like the idea of your packages very much. That way, no matter how some developer has set up his directories and compilers, he would be able to go into ta3d, compile and run, very neat. That way, it would be very easy for me to get through everything once and see what all this is about, while on another directory I try to get it compiled using MSVC 7.1.

zuzuf: I'll have a look at the differences in jpgalleg and send that to the allegro developers mailing list, is that OK? Maybe it's a better time now to get that right than it was before jpgalleg was put into the core distribution.

Changes need to be made in many places, but before I send anything, I'll have to think about how to do it with minimal changes. Not sure yet. There will also be changes in parts of the networking, because it seems that Winsock2 has some subtle differences compared to the linux sockets. I assume that there's no simple way to just disable networking completely, using some #define or so?

My way of working with projects like this is to have multiple directories, e.g. one as a copy of SVN, another with my current work in progress, and maybe yet another one. Then I compare these with WinMerge, which is a fantastic tool to compare whole directories and the files in them, allowing immediate edits to both sides. Very neat. Something like that should exist for linux, too...

Doors · Post by **Doors** » Fri Apr 11, 2008 7:09 am

[quote="tobing"]

Well, you can get very much used to visual layout when developing. I'm using MSVC for 10 years now, versions 6.0, 7.0 and 7.1, and we're about to move to 8.0 but hesitate, because that version does have some drawbacks. So that's why I keep an eye on Eclipse, and on Code::Blocks, now that you mention it. They did make some progress, didn't they?

I like the idea of your packages very much. That way, no matter how some developer has set up his directories and compilers, he would be able to go into ta3d, compile and run, very neat. That way, it would be very easy for me to get through everything once and see what all this is about, while on another directory I try to get it compiled using MSVC 7.1.

My way of working with projects like this is to have multiple directories, e.g. one as a copy of SVN, another with my current work in progress, and maybe yet another one. Then I compare these with WinMerge, which is a fantastic tool to compare whole directories and the files in them, allowing immediate edits to both sides. Very neat. Something like that should exist for linux, too...

[/quote]

I just have problems with the whole message que idea in MSVC or for that matter in windows, I am not a linux user at all. All the directories just confuse me, nobody has ever been able to tell me what they are all for and the logic behind the whole design.

I am also NOT!!! a C/C++ programmer, still hunting for OpenGl guides that don't devolve into gibberish or self referential or even worse custom terminology at the drop of a pixel.

I'm much more of a nuts and bolts kind of guy, I'll use shortcuts and easy ways only after I can do it the hard way so I know the real results of doing something not just the documented ones, saves troubleshooting.

By providing the whole environment in one file differences can be compared, if you follow the directions and get a different outcome then you have a good copy for comparison forensics, saves hassle and helps people just starting out learn for themselves and encourages learning troubleshooting skills.

Working on a game like this sure beats explaining programming to auto mechanics in terms of Crankshaft and Camshaft as firmware with the ignition switch as the power button and the driver controls as joy stick inputs to control the vehicle.

Just wish C/C++ had been designed to be read not compiled.

Post by **zuzuf** » Fri Apr 11, 2008 7:41 am

Doors wrote: Just wish C/C++ had been designed to be read not compiled.

That's the dream of many programmers, but with a language designed to be read you lose some control over your computer. The higher is the level of a language the less control you have.

tobing wrote:zuzuf: I'll have a look at the differences in jpgalleg and send that to the allegro developers mailing list, is that OK? Maybe it's a better time now to get that right than it was before jpgalleg was put into the core distribution.

yeah maybe they'll listen this time

tobing wrote:Changes need to be made in many places, but before I send anything, I'll have to think about how to do it with minimal changes. Not sure yet. There will also be changes in parts of the networking, because it seems that Winsock2 has some subtle differences compared to the linux sockets. I assume that there's no simple way to just disable networking completely, using some #define or so?

you cannot disable networking easily in current SVN since there are new menus that allow joining/hosting a game which use lots of networking functions.

western sent me some improvements for win32 on networking code, I've integrated them into my working copy and managed to build TA3D for win32 and to join a game hosted by a linux server, chat works but file transfer doesn't because of some bug in TCP server code. I'll commit that as soon as I am back home tonight.

tobing wrote:My way of working with projects like this is to have multiple directories, e.g. one as a copy of SVN, another with my current work in progress, and maybe yet another one. Then I compare these with WinMerge, which is a fantastic tool to compare whole directories and the files in them, allowing immediate edits to both sides. Very neat. Something like that should exist for linux, too...

There are similar tools for Linux, I use mainly svn tools to do this: "svn diff" gives me everything I need.

tobing · Post by **tobing** » Fri Apr 11, 2008 9:00 am

Doors: Message queueing/passing is about Windows and MFC, not about MSVC. MSVC is only just the compiler/IDE used to compile C/C++ programs. I don't like MFC very much and only used it once for a tool.

Read C++? Much of that depends on proper naming of classes, structs and variables, and proper naming schemes help a lot. The rest is getting used to *&{!}++|; etc.

jpgalleg: Tried to compare, but they now have version 2.6 and there are many many differences. How did you find the 64bit issues? Or do you know what exactly you have changed (despite from changing the filenames to *.cpp)?

I think I'll get the head revision tomorrow and work on that, there are too many differences between 0.4.2 and SVN head right now.

Post by **zuzuf** » Fri Apr 11, 2008 10:57 am

jpgalleg wasn't building on 64bits systems because it converts some pointers to int, which works in a 32bits environment but doesn't work with 64bits since int is still 32bits and a pointer is much larger ... so I replaced those int with pointers.

I'll look at 2.6, this looks interesting

tobing · Post by **tobing** » Fri Apr 11, 2008 11:59 am

I found one issue in jpgalleg 2.6, I think I'll put that to the AD mailing list. We'll see what happens with that.

There are several occurrences of sleep(...) in the code, I suggest they all be replaced by rest(...) which is the portable allegro equivalent.

gui.cpp(1318) reads
if( wndFile->PullAsBool( obj_key + "common.grayedout" ) == 4 )
which can never be true, as the result of PullAsBool is a bool.

network.cpp(1019) function Network::sendChat does not always return a value, i.e. not all control paths. My guess is that the last else is missing and should return -1.

particles.cpp(666) reads
if(part.light_emitter != light_emitters ) continue;
which should be changed to
if(part.light_emitter != (light_emitters!=0) ) continue;
I would guess.

In thread.h, all Spawn() methods should return void, i.e. nothing, because that is what they all (except one) do: return nothing, and no caller cares for the return value anyway.

There are more minor issues, related to ambiguous functions and such, but that will be for later. The remaining severe issues are SocketClass.cpp which gives a number of compiler problems, this is most probably due to Windows not being compatible to the linux sockets implementation. And a somewhat funny compiler limitation in fbi.cpp: In UNIT_TYPE::load there's a HUGE cascade of else if statements, and MSVC only accepts a nesting of 128. Not sure what the best solution here would be...

So that be it for today. Maybe you have some minutes to look at these and see what you are willing to submit, I'll be back to get files from the depot tomorrow.

Post by **zuzuf** » Fri Apr 11, 2008 4:05 pm

Thanks, I'll fix that when I am back home

PS:

tobing wrote:particles.cpp(666) reads
if(part.light_emitter != light_emitters ) continue;
which should be changed to
if(part.light_emitter != (light_emitters!=0) ) continue;
I would guess.

light_emitters is an int but is used as a bool. I needed an int because I use it in a 'for'. Since light_emitters is only 0 or 1 in this expression both expressions are equivalents (if you enable compiler optimizations)

tobing · Post by **tobing** » Sat Apr 12, 2008 8:02 am

The light_emitters thing is just to get rid of a warning.

Goalie Ca has made a small change to jpgalleg to get rid of the warning I posted. See http://www.allegro.cc/forums/thread/595951

I saw you have #define'd sleep to be rest... while that works, I would have preferred to replace the few calls to sleep in the code be rest instead. Having many #define's in the code can introduce a lot of confusion, makes it harder to read especially if you #define something known to be something else, and lastly my source code tools will more likely screw up and not tell me the right things. I'm using Visual Assist for example, and WorkspaceWhiz, which make code navigation so much easier, especially through unknown code.

Compiling the current code is due for later today...

TA3D 0.4.2

TA3D 0.4.2

Who is online