trunk codebase [code-talk]

Discuss the future of Warzone 2100 with us.
-Kosh-
Trained
Trained
Posts: 203
Joined: 16 Sep 2009, 23:34

trunk codebase [code-talk]

Post by -Kosh- »

I was looking at the condition of the trunk codebase and just thought that with every new thing being added to this project it is getting much more complicated for the average person to start digging into the codebase to fix or tweak or add new routines.
Just look how complicated stats-db.c is and that would be a nightmare to fix if people did not know SQL.
While in theory this might have been a good change in reality this is just adds much more code bloat, more possibility of errors, and ratchets up the difficulty curve greatly. Personally I do not see what is wrong with CSV style stat files.
Most everyone has a text editor on the system, the same is not true for editing SQL stuff.

The mipmap load routines for the decals is pretty silly and requires much more work to maintain. This should get the axe and let openGL handle it much the way it does for the terrain now. I do not even know why all the terrain types are still being loaded or are in the texpages\tertiles* folders?
Speaking of terrain O_o map.c is pretty darn full of hacks to force certain texture pages to load?

The music routines went from a working(?) playlist to something that is trying to be a playlist but fails. I do not know the reason for the change but this is resulting is music being played over the top of each other sometimes and you can not specify directories or have .mp3 files anymore. Yeah I know we should use a external player but why the change(s)?

I am not trying to sound harsh but trying to recruit new people to maintain this stuff is going to be a continuing challenge for this project unless these things get simplified.
This is a waste of space. Something important should be here.
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: trunk codebase [code-talk]

Post by Per »

-Kosh- wrote:Just look how complicated stats-db.c is and that would be a nightmare to fix if people did not know SQL.
While in theory this might have been a good change in reality this is just adds much more code bloat, more possibility of errors, and ratchets up the difficulty curve greatly. Personally I do not see what is wrong with CSV style stat files.
Most everyone has a text editor on the system, the same is not true for editing SQL stuff.
I agree. I think we should revert the (half-finished) SQL stuff from trunk as well (it was previously reverted from 2.2 branch).
-Kosh- wrote:The mipmap load routines for the decals is pretty silly and requires much more work to maintain. This should get the axe and let openGL handle it much the way it does for the terrain now. I do not even know why all the terrain types are still being loaded or are in the texpages\tertiles* folders?
There is a lot of cleanup to do of the old map drawing code. But the "pretty silly" mipmap load routines was a simplification of what was there previously back before the new terrain renderer came into the picture ;)
-Kosh- wrote:Speaking of terrain O_o map.c is pretty darn full of hacks to force certain texture pages to load?
I don't think so. Some pages are hard-coded, though.
-Kosh- wrote:The music routines went from a working(?) playlist to something that is trying to be a playlist but fails. I do not know the reason for the change but this is resulting is music being played over the top of each other sometimes and you can not specify directories or have .mp3 files anymore. Yeah I know we should use a external player but why the change(s)?
O_o ?