Re: [warzone2100-dev] OpenGL requirements for trunk
Per Inge Mathisen wrote: Let me know what you think. Sooner or later that switch would be inevitable anyway. If the decision is made to use these features, we should make sure that people are informed long before any release, so they know in advance that coming WZ versions won't work with their hardware. I am for that switch. On a side note: It'd be yet another big thing started (afaik we currently have new widgets/GUI, lua, savegame format (and other formats as well probably), stats conversion in the making). - 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] OpenGL requirements for trunk
On 9/26/09, Per Inge Mathisen perxx...@gmail.com wrote: I have been working with OpenGL 2.0+ features lately, and I think I could have a good shot at making the current model drawing code much faster by using such features. However, this would require working support for VBOs and GLSL shaders. It probably means bye-bye Intel integrated graphics hardware (at least until they manage to get the drivers up to speed on the more modern of their hardware). The trunk branch was supposed to be for modern graphics hardware, and the way graphics development is going, the OpenGL 1.x way of doing things is more and more a thing of the past. On the other hand, Intel integrated chipsets have bigger market share than either ATI or Nvidia (at 40%, 27% and 20% respectively in one article I read). So perhaps we should do a 2.3 branch of the current trunk before any such changes, and hope that Intel users can use that? From what I have heard, at least some Intel users have been running trunk successfully. Of course, once we start using shaders and VBOs, a lot of new interesting possibilities open up in the graphics department. So it is not just to increase the speed of model drawing we would be adding this requirement. Because of the intrusive changes needed, maintaining two drawing paths would not be feasible. Let me know what you think. Are you insane? How can I play this game on my 5+ year old machine then!?!?!? ;) All kidding aside, I am fine with almost all of this. GSSL will be nice, but I worry about the support, and if we need to have fallback routines or not. We just don't have the manpower to have fallback routines. The part I do not agree is about the version. I much rather we have the current trunk as 3.0. Then the new trunk (with shaders / GLSL+ whatever else) should be 3.5 or maybe even 4.0. This leaves us with 2.2 branch to move up to 2.9 for room to grow, instead of doing 2.2.11 :) In case we want to backport stuff from trunk to the 2.x line. I have more comments on 2.2+ shortly. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Warzone 2100 Trac] #961: Data integrity routines
#961: Data integrity routines -+-- Reporter: Buginator| Owner: Type: enhancement | Status: new Priority: major| Milestone: 2.2.4 Component: other|Version: svn/2.2 Keywords: | Operating_system: All/Non-Specific Blockedby: | Blocking: -+-- This is the *start* of data checking. Currently, it will only work on platform specific systems. So windows - windows, or linux - linux but not windows - linux. The reason for this is the current data in the SVN needs to have the EOL set to the same for all platforms--see ML for more details. This could either be CR (mac?) CRLF (windows) LF (linux). I think it should be set to CRLF since most all utilities are windows based, and those require CRLF to work. On to the routine. In simple terms, it throws the buffer to the hash routine, and calculates it. Then when people enter the game, it will kick people out if the data does not match. A) I don't think we should parse the buffer to strip \r\n (or \r or \n...) just takes up more code and can be easily solved by changing the EOL style on SVN to CRLF.[[BR]] B) There *is* a log message for when it kicks you, but you will be dumped back to the main menu. It is the same as if you pressed quit while in- game.[[BR]] C) This is only phase one of the data integrity routines, more advanced routines are planned. This is mainly meant so people with different mods can't play together, since that tends to screw up games.[[BR]] D) I am not 100% sure of the endian issues, I think I got them all, but if someone can double check...[[BR]] -- Ticket URL: http://developer.wz2100.net/ticket/961 Warzone 2100 Trac http://developer.wz2100.net/ The Warzone 2100 Resurrection Project ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Version scheme (again)
First off, I really think we need room to grow for the 2.2 branch. If we start to backport some changes from trunk to the current 2.2 it can/will break things, and saying 2.2.5 won't work with 2.2.4 because of XYZ isn't really a good way to handle it. Minor improvements and or bug fixes are for minor bumps in the version, but something more major really needs a major bump in the revision numbers. For example, the net code. As we all know, it is pretty different in trunk and branch, and it is much harder for us to maintain two versions of netcode. If we backport that from trunk to 2.2, it should be 2.3.0 not 2.2.5 (or whatever). Some of the other stuff would be the new savegame format and whatever else. Last topic of this nature was pretty much everyone said it was OK to make the current trunk 3.0. Can we all, finally agree how to handle this? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Version scheme (again)
On Sun, Sep 27, 2009 at 4:00 PM, bugs buggy buginato...@gmail.com wrote: For example, the net code. As we all know, it is pretty different in trunk and branch, and it is much harder for us to maintain two versions of netcode. If we backport that from trunk to 2.2, it should be 2.3.0 not 2.2.5 (or whatever). ... Last topic of this nature was pretty much everyone said it was OK to make the current trunk 3.0. Can we all, finally agree how to handle this? I thought we'd already agreed that that was exactly how we were going to handle it. o_O At least, that's what I mean when I say 2.3 and 3.0 on the forums nowadays. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.2.3a for Macs?
Nice of someone to notice that we were stripping the mac exe, so the crash dumps are more or less useless. I think the mac builds need to be redone ASAP, so we can have half-way decent crash dumps from the mac people. I do NOT think we should tag a 2.2.3a, just commit the xcode changes to 2.2.3, and do another mac release from that, and make it known on the frontpage /download page that it is updated. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
