On Tuesday, 12 September 2006 at 23:45, Dennis Schridde wrote: > Am Dienstag, 12. September 2006 02:29 schrieb Christian Ohm: > > On Saturday, 9 September 2006 at 2:30, Dennis Schridde wrote: > > > Hi! > > > > > > I added 2 new pages to the wiki and would like to get some comments: > > > http://wz.rootzilla.de/wiki/user:codingstyle > > > > Well, the coding style is mostly personal preference, the main thing is > > to keep it consistent (as far as possible, since the existing code > > isn't). I'd only like to comment on one thing: Tab size. There is a > > indentation style where tab size is irrelevant: Use tabs to indent and > > spaces to align, like this: > > > > int bla(int blubb) { > > int i = 26; > > float honk = 84.332; > > if (blubb < i || > > blubb > honk) > > return 37; > > } > > return 982; > > } > > > Actually that int i doesn't align here very probably... (Might be due to a > non > fixed fontsize.)
Yeah, a proportional font will do that... do you use one while coding? It was just a (bad) example, I don't like those aligned variables - if you add a new one with a longer name, you have to re-align all others, that's just stupid. > > That would be my preference. > > > > And I'd move the first six points of "Other" to user:coding, as that's > > rather code organization than coding style. > I thought that that's all the same. Idea was to have one reference for > someone > who wants to know "how shall my code look like". I counted both API style as > well as indentation into that wish. Yeah, both are important - I was thinking more about the organization of information - do you have everything in one large page, or several smaller pages (my preference). > And it is still a complete draft. Maybe some things are totally irrelevant > and > maybe very relevant things are missing... Aye. We're working on it, right? :) > > > http://wz.rootzilla.de/wiki/user:wishlist > > > > Question: What about the TODO file in the repository? Do we need both? > That's also a question I asked myself when I found out that parts of the TODO > also should be in the wishlist... > > If not, which one do we keep? In my opinion, the wiki is more suitable > > for that as it can be changed more easily. > Actually I don't know. It seems like not so many people look into a TODO file > as look into a wishlist Wiki page. > We probably need to decide on that question. Idea: Have the wiki page for larger changes (a longer term roadmap), while the TODO file contains more immediate matters (things that can be fixed without larger rewrites, and stuff like "Oh, while coding I noticed something odd, investigate later"). > > Not all of the points you listed are major changes ("Make it possible to > > close Warzone with ^C, ALT+F4 or closing the window", "Fix memleaks in > > lexer files"). > That page was all about design questions, which both points involve to some > extend. > Closing with ^C requires Warzone to be design in a way which makes it > possible > to call a subsystem's init function and register it's exit function to > atexit(). > Those memleaks are also similar: It is perhaps more a question like: How can > we help prevent memleaks by design? Instead of how can we fix this memleak. > And even fixing that memleak is tricky, because eg MSVC's memleak detection > fails on all of those memleaks, because it doesn't know where they come from, > because they don't have the crtdbg.h redefinitions of malloc and free. OK. It just looked kinda out of place in that list. > > "Improve the menus for usability (esp. networking)" is connected to an > > overhauled GUI system; "Increase drawed area In-Game" and "Find a better > > (easily useable) dataformat for models (?) and textures (DDS?)" depend > > on the graphics engine. > Yes, there are some dependancies. Perhaps we can display them better? Nested list. > > DDS looks to Microsoft/DirectX specific to me, > DDS can include (and that's the sense why I added it) S3TC compressed images. > (MS calls that DXTC.) Those images can be loaded by any more or less current > graphicscards in hardware. (List of OpenGL drivers/hardware supporting it: > http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_texture_compression_s3tc) > > The DDS file structure is documented by MS very well and you can simply load > the texture (if it is S3TC compressed) out of the file into the hardware. (No > need of extra libraries.) > That's why I thought about this format. > > which Linux program can edit those files? > Now that you remind me of this I find the flaw in my idea... GIMP seems to > not > support it and actually I don't know of any other... (Perhaps there are > converters?) I was almost convinced about DDS, until I tried (wanted to try) your example. It compiled and ran and showed a white cube. Then I installed the GIMP plugin and wanted to convert the tertiles image. But the plugin complains about "GL_S3_s3tc or GL_EXT_texture_compression_s3tc is not supported by your OpenGL implementation" (the mesa3d r300 driver). Your test program doesn't seem to use those extensions, can you send me the dds file to test it? Result: Disappointing. If you need the S3TC extension to edit and load DDS files, it gets no vote from me. > > And what's wrong with PNG / > I think some time ago someone said that he/she thinks that pngs are quite big. Compared to what? > I don't remember who it was. (I think one of the devs.) > And png needs an external library. :P I think I saw a PNG loader without libpng somewhere (might depend on zlib, though), I could try to find it again. But is it a problem to depend on libpng? That one should be quite standard, no? > > what's better about TGA? > Don't ask me that, that idea is from Kamaze. ;) The only advantage of TGA I know of is that it's quite simple, so you can write a quite small loader for it. But it's about twice as large as PNG (for the tertiles image). -- Humor in the Court: Q: What can you tell us about the truthfulness and veracity of this defendant? A: Oh, she will tell the truth. She said she'd kill that sonofabitch--and she did! _______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
