
with some bug fixes since RC1, have fun !!
No problem, keep up the good work!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
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: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?)...
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: 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...
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: 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.
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).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.
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.Doors wrote: Just wish C/C++ had been designed to be read not compiled.
yeah maybe they'll listen this timetobing 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.
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.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?
There are similar tools for Linux, I use mainly svn tools to do this: "svn diff" gives me everything I need.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...
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.
Users browsing this forum: No registered users and 7 guests