Re: [warzone2100-dev] Warzone's direction for 2.3 series
On Mon, Apr 5, 2010 at 2:52 AM, Guangcong Luo za...@wz2100.net wrote:
Looks like the ML is back up.
On Sat, Apr 3, 2010 at 2:27 PM, buginator buginato...@gmail.com wrote:
...
...
The network code, AFAICT, we do not have any network related crashes anymore.
Yes, we got sync issues, but the 2.3 series will always have them.
Cyp's work with newnet should fix the sync issues, but, last I looked,
that version will __NOT__ work with 32bit systems at this time. This
is both on MSVC cross-compiled builds.
What about newnet requires 64-bit support? That seem so weird...
I think (97.13% sure) that it was working on a 32-bit Linux system
with sse2, and was working on at least one mac.
If I remember right, then the only issue is it not working on w32,
even if cross-compiled with gcc. I couldn't cross-compile it myself,
and haven't seen the assembler output of fptest1() in main.c, so I
can't determine if it's a wrong-code generation, or if it's windows
messing with the floating point registers somehow. (I once had an
issue with a version of Linux failing to restore the floating point
state correctly, so something like that wouldn't surprise me too
much.)
The assembler output must contain sse instructions, not x87 fpu
instructions. And no fused-madd instructions.
As far as I understand, -msse -mfpmath=sse -mno-fused-madd should fix
32-bit floats - fptest1(), and -msse2 -mfpmath=sse -mno-fused-madd
should fix 64-bit floats - fptest2(). Since there aren't many doubles
used, it probably doesn't matter if fptest2() fails.
So, as far as I know, the status is:
Linux x86_32: works
Linux x86_64: works
Linux ARM/MIPS/Alpha/PPC/sparc/ia64/...: unknown
Mac Intel: works
Mac PPC: unknown
Windows x86_32: fails
Windows x86_64: unknown
3 possible solutions:
1. Get windows to do floating point correctly.
2. Convert everything to C++, and typedef float Float; on Linux/Mac,
and class Float { ... }; on windows.
3. Use integers only. (Fixed point, that is.)
I think the bMultiMessages change I committed may have made the sync
worse, so I guess it should be reverted once again. This is really
frustrating, because it really does fix seven different bugs relating
to bMultiPlayer having an unexpected value.
(Background: Much of the code assumes bMultiPlayer is TRUE if in a
multiplayer/skirmish game, and FALSE in campaign. However,
bMultiPlayer can be FALSE in a multiplayer game because
turnOffMultiMsg messes with it. I thought my code was the most
reliable way to fix the problem, but apparently it was unsuccessful.)
For 2.3, I'm indifferent. Reverting that in trunk would probably cause
a few hundred merge conflicts with newnet.
No objections to Qt and newnet being merged as soon as possible.
I don't have any spare time at the moment. If squeezing a merge in, I
would at most be able to test if it compiles, not whether it runs.
(Should one expect 60fps via ssh X forwarding over a very unstable
network, or would it just be the usual 30fps as when running native?)
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Qt branch merge?
On Sat, Apr 3, 2010 at 5:47 AM, Per Inge Mathisen per.mathi...@gmail.com wrote: We need to merge some of the large trees into trunk soon. I have a number of things waiting for a merger of the Qt branch, and I am holding off any larger changes to scripting waiting for the lua branch. I am also trying not to change too many things in order/action/net code because of the newnet branch. As this situation is unsustainable, I would like to start merging the Qt branch soon, even though it may still have some sharp edges. Perhaps we merge Qt+newnet into a new experimental branch, then? I have three major objections to merging Qt and newnet in: 1. Some of our users play trunk primarily. jaakan and those MSVC guys, for instance. You can meet them by making a commit that breaks compiles. :P I'm sure they'd rather dislike being unable to play an updated version of trunk for however long it takes to fix them will be an issue. 2. One of the forum users complained about the bugs in Qt branch making it unplayable, and I had to reassure him that Qt branch would not be merged into trunk until those issues were fixed. 3. I develop with Mac OS X and Windows. It is my understanding that once they were merged in, I wouldn't be able to develop with Windows, and I'd come up with several serious bugs in Mac OS X. I think those mean that it's a bit early to be merging them in. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.2.4
Guangcong Luo wrote: I don't think any other software company has done that, ever, which should be the first clue that perhaps it's a bad idea. We are not a software company. And we do not produce commercial games, so please don't compare us with them all the time. Is there anything wrong with continuing to support 2.2.4 nominally, like we do now? It's a lie. We haven't supported 2.2.4 for at least three months now (r8763 was the last commit to the 2.2-branch, r8283 was the last commit to 2.2.4-tag). And there is a difference between latest stable and supported version. We label something stable if it's good enough (compared to what it was before we improved it). So, we won't say there is no stable version, only that the last stable version isn't supported anymore (and has not been supported for 5 months, the release of 2.2.4). It's really a rather minimal amount of extra work; I mean, when's the last time we've gotten a 2.2.4 bug report? Probably you are missing the point here (or I am xD): It's not about the additional work of maintaining the 2.2 series, it's about informing the users of the state the project is in. We don't lose anything saying that we do not have a _supported_ stable version currently, we've got a supported beta. And that's one of the advantages of being a FLOSS project: You don't need to think about all the stuff marketing people in companies have to do, we won't lose a single dollar/euro. Additionally I don't care that much about our reputation as long as it's defined as lie to people so they are happy instead of telling them the truth. - Kreuvf signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.2.4
On Mon, Apr 5, 2010 at 3:15 AM, Kreuvf kre...@warzone2100.de wrote: We are not a software company. And we do not produce commercial games, so please don't compare us with them all the time. Okay, software company was the wrong word. I meant out of any software project, commercial or free, proprietary or open. I don't think any of them have ever labeled a stable version unsupported before a newer stable has been released. Probably you are missing the point here (or I am xD): It's not about the additional work of maintaining the 2.2 series, it's about informing the users of the state the project is in. Well, I think the problem is that the term supported is not well defined. I couldn't find a definition on Stack Overflow, Wikipedia, or Wiktionary. To me, supported means This is the latest stable version, and we will try to help you if you have a problem with it. Sure, most of the time, that help is probably upgrade to 2.3 beta 12, but I think that qualifies. I mean, sometimes, problems with 2.3 beta 12 are solved by downgrade to 2.2.4. I mean, maybe it's just me, but I still think 2.2.4 is more stable (or at least differently stable) than whatever latest beta we have. I mean, 2.3 beta 12 still has that template issue. It's also that we break netcode/savegame compatibility every other day in the 2.3 betas, so someone who wants a stable game in that sense is better off playing 2.2.4 on the lobby servers, and we support that behavior on some level. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.2.4
Guangcong Luo wrote: Well, I think the problem is that the term supported is not well defined. I couldn't find a definition on Stack Overflow, Wikipedia, or Wiktionary. The one I had in mind is: We will try to fix bugs you report and come up with a new version after some time. Support in the sense of helping when there are problems with the latest stable is mainly done in the forums, I cannot say anything about it, but based on my experiences elsewhere I think that most support is user-to-user support, isn't it? And each dev could still help people that have problems with 2.2.4. - Kreuvf signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Qt branch merge?
On Mon, Apr 5, 2010 at 11:54 AM, Guangcong Luo za...@wz2100.net wrote: Perhaps we merge Qt+newnet into a new experimental branch, then? That only helps if all the developers start working on that branch, instead of trunk. The new 'experimental branch' would then be the new trunk. So what you are in effect suggesting is to copy trunk into a new to-be-stable branch, before merging in Qt and newnet. That only makes sense if we are planning to release a 2.4 from current trunk without Qt and newnet, and I do not think we are. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.2.4
On Sat, Apr 3, 2010 at 9:26 PM, buginator buginato...@gmail.com wrote: Hey all, just wanted to update a few things about the project. First off, 2.2.4 should be dead. Really. It serves no useful purpose for us at all. I am a bit uncomfortable with that. I do not think we want linux distros etc to use a random 2.3 beta. If I had any idea that the 2.3 series would have dragged on this long, I'd have kept backporting fixes to 2.2 branch and pushed for a 2.2.5 already... Something went awfully wrong on the planning of 2.3 - it was only supposed to be 2.2.4 + the new trunk netcode :-( - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.2.4
On Mon, Apr 5, 2010 at 5:33 AM, Kreuvf kre...@warzone2100.de wrote: Support in the sense of helping when there are problems with the latest stable is mainly done in the forums, I cannot say anything about it, but based on my experiences elsewhere I think that most support is user-to-user support, isn't it? And each dev could still help people that have problems with 2.2.4. Well, whatever definition of the term support we use, dropping support for the latest stable while the newer development version hasn't been made stable yet is unprecedented in any sort of software. So if we're doing so, I think that means we're doing it wrong. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On Mon, Apr 5, 2010 at 9:17 AM, C yp cyp...@gmail.com wrote:
3 possible solutions:
1. Get windows to do floating point correctly.
2. Convert everything to C++, and typedef float Float; on Linux/Mac,
and class Float { ... }; on windows.
3. Use integers only. (Fixed point, that is.)
What parts of the game state still relies on floating point? I can
think of experience, power, movement (though I have an almost complete
patch for changing that, just need someone to up the precision), and
not much else? I do not think this option should be so hard.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10489] branches/2.3/src/multijoin.c
On Mon, Apr 5, 2010 at 5:24 AM, bugina...@users.sourceforge.net wrote: Revision: 10489 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=10489view=rev Author: buginator Date: 2010-04-05 03:24:05 + (Mon, 05 Apr 2010) Log Message: --- As a temporary solution to the oil features not being put back. How is this fix supposed to work? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.2.4
On Monday, 5 April 2010 at 2:44, Guangcong Luo wrote: Is there anything wrong with continuing to support 2.2.4 nominally, like we do now? It's really a rather minimal amount of extra work; I mean, when's the last time we've gotten a 2.2.4 bug report? Five days ago: http://developer.wz2100.net/ticket/1723 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Warzone 2100 Trac] #1746: Save mod information
#1746: Save mod information -+-- Reporter: Zarel| Owner: Type: patch| Status: new Priority: blocker | Milestone: 2.3 Component: Engine: Resource Management |Version: svn/trunk Keywords: mods | Operating_system: All/Non-Specific Blockedby: | Blocking: -+-- '''What it does:''' When loading a saved game, this patch will load the exact mods that were loaded when the game was saved (and unload other mods). If a mod that the game was saved with no longer exists on the local machine, the game will give a pop-up warning and load the game without the mod. If the mod is incompatible (which is not always the case), the game will assert and return to the main menu. Otherwise, the game will proceed normally. One possible flaw of this system is that it is no longer possible to load a mod in the middle of a game, and unloading a mod in the middle of a game requires purging it from all Warzone directories. '''How it does it:''' This patch bumps the savegame version to 38. It adds mod information to the save game. When loading earlier savegames, it will simply won't replace the loaded mods with the mods in the savegame. In other words: This patch does not break savegame compatibility. The patch adds the function `setOverrideMods`, which will make it so the next time (and only the next time) the data directories are loaded, the mods in the passed mod list (and only those mods) will be loaded. If the saved game contains a mod list, it will pass that mod list to `setOverrideMods` during loading before loading the data directories. I plan on using `setOverrideMods` and the file sending routines to accomplish a similar thing for multiplayer games in a future patch. -- Ticket URL: http://developer.wz2100.net/ticket/1746 Warzone 2100 Trac http://developer.wz2100.net/ The Warzone 2100 Project ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On Mon, Apr 5, 2010 at 2:50 PM, Per Inge Mathisen
per.mathi...@gmail.com wrote:
On Mon, Apr 5, 2010 at 9:17 AM, C yp cyp...@gmail.com wrote:
3 possible solutions:
1. Get windows to do floating point correctly.
2. Convert everything to C++, and typedef float Float; on Linux/Mac,
and class Float { ... }; on windows.
3. Use integers only. (Fixed point, that is.)
What parts of the game state still relies on floating point? I can
think of experience, power, movement (though I have an almost complete
patch for changing that, just need someone to up the precision), and
not much else? I do not think this option should be so hard.
Option 1 should be the easiest (trivial), except that maybe it's
completely impossible instead of completely trivial.
I had to mention option 2, just for the sake of it.
That leaves option 3:
Think the main part is power, movement and experience. Think
floating-point might be (mis)used a few other random places, but
probably nowhere that isn't easy to fix. Think it's used all over the
place in src/effects.c, but that file _shouldn't_ affect the game
state (except that maybe it does, think Safety might have said
something about oil well burning times depending on src/effects.c, not
sure if I understood, since it's hard to believe there could be
something hacky like that in a codebase like this).
I think adding a // TODO Add more precision. line would probably be
sufficient for the movement patch to be committable (not that I've
tested it in any way, don't remember whether I read the patch or not).
If removing all floating point from the game state, then we can even
go the opposite way with the compile flags, and add -ffast-math...
-Cyp
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Warzone 2100 Trac] #1747: High angle area weapons self-destruct or hit friendlies
#1747: High angle area weapons self-destruct or hit friendlies --+- Reporter: lbourn...@…|Type: bug Status: new|Priority: minor Milestone: unspecified| Component: Engine: Scripting / AI Version: 2.3 beta 12a (svn r10492) |Keywords: self-destruct, area weapon Operating_system: All/Non-Specific | Blockedby: Blocking: | --+- If you place a mortar or other high angle weapon next to a cliff or a wall or hard point, and provide a target that will cause it to try to fire through the object, it will and may damage the friendly object and/or destroy itself with reflected fire. Have also noticed that area weapons will attack an enemy vehicle in close proximity to a friendly one and destroy them both. I've lost a lot of trucks that way! That's not unrealistic, but then you can't stop it either when the fire comes from a construct rather than a vehicle. I had not really noticed this behavior prior to Beta 12, or it has become more pronounced. -- Ticket URL: http://developer.wz2100.net/ticket/1747 Warzone 2100 Trac http://developer.wz2100.net/ The Warzone 2100 Project ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #702: VTOL Rearming Pads can float and/or go underground
#702: VTOL Rearming Pads can float and/or go underground ---+ Reporter: TonyTheSlayer | Owner: Per Type: bug| Status: accepted Priority: critical | Milestone: 2.3.1 Component: Engine: Graphics |Version: 2.3 beta 8 (unsupported!) Keywords: VTOL Rearm Rearming Pad Float | Operating_system: All/Non-Specific Blockedby: | Blocking: ---+ Changes (by Per): * priority: blocker = critical * milestone: 2.3 = 2.3.1 -- Ticket URL: http://developer.wz2100.net/ticket/702#comment:15 Warzone 2100 Trac http://developer.wz2100.net/ The Warzone 2100 Project ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #702: VTOL Rearming Pads can float and/or go underground
#702: VTOL Rearming Pads can float and/or go underground ---+ Reporter: TonyTheSlayer | Owner: Per Type: bug| Status: accepted Priority: critical | Milestone: 2.3.1 Component: Engine: Graphics |Version: 2.3 beta 8 (unsupported!) Keywords: VTOL Rearm Rearming Pad Float | Operating_system: All/Non-Specific Blockedby: | Blocking: ---+ Comment(by Zarel): Screw this. Why are we postponing former-blocker bug fixes to 2.3.1? Just commit it already, wait a beta, and revert it if it really is that bad. We have at least one more beta scheduled, anyway. -- Ticket URL: http://developer.wz2100.net/ticket/702#comment:16 Warzone 2100 Trac http://developer.wz2100.net/ The Warzone 2100 Project ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Bugs for next beta
I did some testing on Windows this Easter, and the crash report dialog when running in fullscreen is worse than useless, it freezes the entire game, giving a black screen. This needs to be fixed, or the dialog can just as well be removed altogether. (How does this work on X11/Mac now?) We should also take a look at http://developer.wz2100.net/ticket/1696 which is related. The well known bugs http://developer.wz2100.net/ticket/1740 (legs - is there more than one report of this happening in beta12?) and http://developer.wz2100.net/ticket/1726 (oil rigs) need to be further investigated. We should also check out http://developer.wz2100.net/ticket/619 (campaign map limiting), and apparently the network code still has issues: http://developer.wz2100.net/ticket/1715 and http://developer.wz2100.net/ticket/1716 Is bug http://developer.wz2100.net/ticket/1039 (WSS) fixed now? Dydo needs the http://developer.wz2100.net/ticket/1736 bug closed before it can be in the release. Unfortunately, I will probably not have much time to look at bugs this week. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Bugs for next beta
On Apr 5, 2010, at 3:58 PM, Per Inge Mathisen wrote: I did some testing on Windows this Easter, and the crash report dialog when running in fullscreen is worse than useless, it freezes the entire game, giving a black screen. This needs to be fixed, or the dialog can just as well be removed altogether. (How does this work on X11/Mac now?) Not having tested it fullscreen I suspect it could do Bad Things™ on the mac too depending on the exact method used. Additionally after having looked into how we are doing the alert on the mac to see if we could get clickable urls I found that this is not something we can keep as it will not work in 64 bit. It should be replaced with an alert built on NSAlert in trunk, though for 2.3 since we will not be doing a mac 64 bit release it does not matter so much. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Launchpad: Validate your team's contact email address
Hello The Launchpad user named 'Dennis Schridde (devurandom)' requested the registration of 'warzone-dev@gna.org' as the contact email address of team 'Warzone 2100 Project'. This request can only be made by a team owner/administrator, so if this change request was unexpected or was not requested by one of the team's administrators, please contact system-er...@launchpad.net. If you want to make this email address the contact email of 'Warzone 2100 Project', please click on the link below and follow the instructions. https://launchpad.net/token/N4wdzvRLDTDlZMSxX4C0 Thanks, The Launchpad Team ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] More png Crushing
On Mar 24, 2010, at 9:25 AM, Stephen Swaney wrote: Nine hours work to reclaim 100kb of disk space hardly seems like a good idea ever. The point was not primarily to save disk space (though it is a nice benefit) but rather to rearrange the why that data is stored in the png files to allow for less overhead in reading them and to cut down on overall network transfers (which has a cumulative effect over time far beyond the disk space saved). -- My Web Sites: http://dak180.dynalias.com:8080/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Bugs for next beta
On Apr 5, 2010, at 3:58 PM, Per Inge Mathisen wrote: did some testing on Windows this Easter, and the crash report dialog when running in fullscreen is worse than useless, it freezes the entire game, giving a black screen. This needs to be fixed, or the dialog can just as well be removed altogether. (How does this work on X11/Mac now?) Not having tested it fullscreen I suspect it could do Bad Things™ on the mac too depending on the exact method used. Additionally after having looked into how we are doing the alert on the mac to see if we could get clickable urls I found that this is not something we can keep as it will not work in 64 bit. It should be replaced with an alert built on NSAlert in trunk, though for 2.3 since we will not be doing a mac 64 bit release it does not matter so much. -- My Web Sites: http://dak180.dynalias.com:8080/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10489] branches/2.3/src/multijoin.c
On 4/5/10, Per Inge Mathisen wrote: On Mon, Apr 5, 2010 at 5:24 AM, wrote: Revision: 10489 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=10489view=rev Author: buginator Date: 2010-04-05 03:24:05 + (Mon, 05 Apr 2010) Log Message: --- As a temporary solution to the oil features not being put back. How is this fix supposed to work? Basically, removeStruct() does a check for .. well, look at this comment: if the structure is a resource extractor, need to put the resource back in the map and destroyStruct() doesn't stick features back. I say it is a temp fix, since I didn't (and still don't) have time to check more of the routines in question. BTW, this will be front-ported, (if it turns out to be a good change), along with the other stuff when I get back. It is just that trunk and 2.3 are diverging apart rapidly... and getting tons of merge conflicts. :( ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.2.4
On 4/5/10, Kreuvf wrote: Guangcong Luo wrote: I don't think any other software company has done that, ever, which should be the first clue that perhaps it's a bad idea. We are not a software company. And we do not produce commercial games, so please don't compare us with them all the time. Is there anything wrong with continuing to support 2.2.4 nominally, like we do now? It's a lie. We haven't supported 2.2.4 for at least three months now (r8763 was the last commit to the 2.2-branch, r8283 was the last commit to 2.2.4-tag). And there is a difference between latest stable and supported version. We label something stable if it's good enough (compared to what it was before we improved it). So, we won't say there is no stable version, only that the last stable version isn't supported anymore (and has not been supported for 5 months, the release of 2.2.4). This. It's really a rather minimal amount of extra work; I mean, when's the last time we've gotten a 2.2.4 bug report? Probably you are missing the point here (or I am xD): It's not about the additional work of maintaining the 2.2 series, it's about informing the users of the state the project is in. We don't lose anything saying that we do not have a _supported_ stable version currently, we've got a supported beta. And that's one of the advantages of being a FLOSS project: You don't need to think about all the stuff marketing people in companies have to do, we won't lose a single dollar/euro. Additionally I don't care that much about our reputation as long as it's defined as lie to people so they are happy instead of telling them the truth. and this. I just find it silly to have something that is deemed stable yet we don't support it all. People submit bug reports for it, and we say try 2.3 series, since we won't be able to fix that bug in 2.2.x anymore. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On 4/5/10, C yp wrote: On Mon, Apr 5, 2010 at 2:52 AM, Guangcong Luo wrote: Looks like the ML is back up. On Sat, Apr 3, 2010 at 2:27 PM, buginator wrote: ... ... The network code, AFAICT, we do not have any network related crashes anymore. Yes, we got sync issues, but the 2.3 series will always have them. Cyp's work with newnet should fix the sync issues, but, last I looked, that version will __NOT__ work with 32bit systems at this time. This is both on MSVC cross-compiled builds. What about newnet requires 64-bit support? That seem so weird... I think (97.13% sure) that it was working on a 32-bit Linux system with sse2, and was working on at least one mac. If I remember right, then the only issue is it not working on w32, even if cross-compiled with gcc. I couldn't cross-compile it myself, and haven't seen the assembler output of fptest1() in main.c, so I can't determine if it's a wrong-code generation, or if it's windows messing with the floating point registers somehow. (I once had an issue with a version of Linux failing to restore the floating point state correctly, so something like that wouldn't surprise me too much.) Oh, right. I forgot I got it working on linux 32bit OK. At least, I think it was OK. It has been too long. MSVC the CC version on windows are the big thorns. No objections to Qt and newnet being merged as soon as possible. I don't have any spare time at the moment. If squeezing a merge in, I would at most be able to test if it compiles, not whether it runs. (Should one expect 60fps via ssh X forwarding over a very unstable network, or would it just be the usual 30fps as when running native?) Maybe i-Nod can chime in if he got Qt or newnet working or not. For now, both branches are in a hold pattern for me, until we can push 2.3 out the door. We still have a fairly big crowd that uses MSVC, so I don't see us dropping that anytime soon, if ever. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
