IRC logs for #opendune on OFTC at 2010-06-15
⏴ go to previous day
12:25:14 <proyvind> has yer efforts stagnated a bit lately?
12:25:31 <proyvind> haven't seen much recent commits lately..
12:26:06 <TrueBrain> I personally am too busy with other things .. like study and stuff :p
12:26:26 <Xaroth|Work> I personally slack a lot, but life's been hectic
12:26:48 <Xaroth|Work> though thankfully TrueBrain provides entertainment every now and then :P
12:26:57 <proyvind> but less stress at work, so maybe I should try get some stuff done again
12:27:20 <TrueBrain> Xaroth|Work: what?!
12:28:51 <proyvind> btw. IIRC you seemed more bent on doing all of your stuff yourself to get to fully know all parts of the code, but I've uncovered a few more structures and their uses in dune2 lately which might interest you..
12:29:36 <proyvind> ie. some tile related stuff etc.
12:43:38 <planetmaker> says the voice from the off and goes back to hibernation ;-)
12:44:23 <glx> the first step is still full conversion :)
12:44:30 <TrueBrain> lol @ planetmaker :)
12:44:56 <TrueBrain> proyvind: there is still the dangarous of us looking at such data, assuming it is correct, and that then it turns out to be slightly different .. makes our process much harder :)
12:49:56 <planetmaker> TrueBrain, how can it be more difficult to check a patch than figuring out youself?
12:50:23 <planetmaker> (provided it's sufficiently small and documented ;-) )
12:52:53 <proyvind> planetmaker: the case is that it's for a different project, written in c++, so just providing patches to you would be a bit tedious..
12:54:42 <proyvind> and I do have to admit that my amount of documentation isn't the very best for much of it, but I do put a lot time into writing pretty generic and sufficiently self-explainatory code though..
12:55:30 <proyvind> so with c++ objects etc. with sensible names and all for class members etc., they should usally be mostly meaningful
12:56:22 <proyvind> and large part of it, where I find it appropriate is done in my library, so trying to make it a bit easier to understand and all is kinda implied :)
12:57:40 * SmatZ wonders "C++" isn't forbidden here
12:57:46 <proyvind> (and the game was originally written in c++ after all, so some classes of mine probably resembles the original c++ code better, but just "some" ;)
12:59:51 <proyvind> SmatZ: hm? not sure what you mean, but what I'm getting at is more code to look for reference to help figuring out stuff not yet identified, not actually being able to use the code itself (I have a STL fetish, so that would make it even harder;).. this is pretty much what I do with opendune and benefit greatly from :)
13:00:33 <TrueBrain> proyvind: I can find 0.00000 evidence Dune2 was original written in C++. I have the strong idea that it was written in C, given some contractions and methods used.
13:01:47 <glx> but it was compiled using borland c++ ;)
13:01:52 <proyvind> Borland C++ - Copyright 1991 Borland Intl.
13:02:24 <TrueBrain> doesn't mean it was written in C++ :)
13:02:41 <glx> true, and asm more like C than C++
13:03:11 <TrueBrain> and it mostly has to do that Borland didn't had a C-only compiler
13:03:17 <TrueBrain> they only have the C++ variant
13:03:59 <TrueBrain> but most entries do not follow the typical C++ setting
13:04:09 <proyvind> hmm, maybe, but a lot of the data structures etc. would remind me more of an object oriented approaches.. but sure, you guys know the low level details better, I humbly bow myself to you ;)
13:04:19 <glx> no member functions it seems
13:04:36 <TrueBrain> proyvind: structs already exists in C :)
13:05:43 <proyvind> TrueBrain: of course, but some of the stuff while plowing through it, made me thinking of it having more of an object oriented mindset to it
13:05:59 <TrueBrain> what would you define as object oriented mindset?
13:06:06 <proyvind> but you guys would certainly know better about this than me anyways :)
13:06:29 <glx> anyway it clearly uses malloc/free :)
13:06:57 <proyvind> not like it would be c++98.. ;p
13:07:20 <TrueBrain> either way, there is nothing that really says: this is C, or this is C++
13:07:26 <TrueBrain> just I can find no logic for it to be C++
13:07:36 <TrueBrain> and if it aint C++, it is C :p
13:07:57 <TrueBrain> mostly the fact that the pool code exists for both structures as units as teams
13:08:08 <TrueBrain> gave me the idea there was no parent class for pools
13:08:14 <TrueBrain> which most likely means there were no classes at all
13:08:47 <glx> even if structures and units share some data ?
13:08:50 <TrueBrain> else they would have done it via an extend, I would tihnk :p
13:09:26 <glx> (fucking functions accepting both and very hard to convert)
13:09:33 <TrueBrain> on the other hand, parts of the structures and unit data struct is shared, which would be typical for a class extend ;)
13:10:17 <TrueBrain> 1 thing I know 100% sure: it is not pure C++, nor pure object oriented
13:10:22 <TrueBrain> the libs used are for sure C
13:10:29 <TrueBrain> and it has many global functions which are not in any scope
13:11:09 <TrueBrain> yeah, but that happens in any C++ project too
13:11:22 <glx> but global data is bad ;)
13:11:32 <TrueBrain> back then, nobody cared
13:11:39 <TrueBrain> looking at the code .. nobody cared about the code anyway :p
13:11:53 <glx> and looking at some constructions they had bad coders too ;)
13:11:56 <TrueBrain> but for it to be C++, I would expect to see ctors and dtors .. I don't (yet) :p
13:12:21 <proyvind> c++ coding practices from that aera were totally different from now..
13:12:54 <TrueBrain> [cd]tors are native to C++, that is something the compiler inserts (from the oldest C++ on, as that is what makes C++)
13:12:58 <TrueBrain> and they had terrible coders
13:13:11 <TrueBrain> mistakes that are made .. can only be described as terrible
13:13:20 <TrueBrain> I think the real code will be very unreadable
13:13:54 <proyvind> c++ code(rs) from that periode was known to be terrible ;)
13:14:18 <TrueBrain> that sounds like C coders were better :p
13:15:39 <proyvind> I'm amazed at how much c++ code out there that isn't 10 years old, that still does so much in C-style, using heap allocated c-style arrays, implementing their own stream classes and what not
13:16:00 <proyvind> rather than just using a lot more efficient, nicer and standardized STL containers
13:16:07 <TrueBrain> because 90% of the 'C++' coders don't understand what C++ means
13:16:20 <TrueBrain> well ... STL is not always more efficient, not always nicer
13:16:26 <TrueBrain> just standardized ;)
13:16:35 <proyvind> it's a complex standard indeed
13:16:47 <proyvind> and some of the classes has legacy design issues
13:16:50 <TrueBrain> not only that ... you often can't say what you want
13:16:57 <TrueBrain> it ALWAYS uses a RB tree
13:17:01 <TrueBrain> good, for 90% of the cases
13:17:09 <TrueBrain> just sometimes I really need an BH
13:17:16 <TrueBrain> because it is (over) generalized
13:17:31 <TrueBrain> sso writing your own STL things is not always a bad thing
13:17:50 <glx> (implementation dependant)
13:18:07 <TrueBrain> that is a whole other issue, but yet
13:18:13 <glx> we had some fun with the differences between gcc and msvc
13:18:18 <TrueBrain> something you need to write your own implementation just to overcome incompatibility
13:18:56 <TrueBrain> just because the standard does not describe corner cases
13:19:06 <TrueBrain> and MSVC is bugged for sure in removing iterators :)
13:19:16 <proyvind> but in most cases, you end up with better code most optimized and appropriate for your use, architecture etc. using generic classes, rather than having to only care about such when it's important or you just feel like it, and even then create code that's way less intuitive and easy enough to understand as there's no standardized types for alll it..
13:20:00 <TrueBrain> you assume reusage of your custom code
13:20:05 <TrueBrain> which for most companies is not an issue
13:20:09 <TrueBrain> as the code will only be used in that project
13:20:16 <TrueBrain> standards are only good if more things will use it
13:20:28 <glx> they like to reinvent the wheel ;)
13:20:31 <TrueBrain> but STL is known for not being the fastest, because they are generalized
13:20:32 * proyvind don't know anything much msvc, but rarely hear good things about
13:20:55 <TrueBrain> as you can't have both :)
13:21:23 <proyvind> TrueBrain: well, I'd say it's more generilized in api and wrapping, but more optimized in many cases under the hood..
13:21:51 <TrueBrain> proyvind: it may be optimized for 90% of the cases
13:21:54 <TrueBrain> just not for the remaining 10%
13:22:04 <TrueBrain> and because you can't configure ... STL is not always the best pick
13:22:34 <proyvind> have you read scott meyer's books btw.? :)
13:23:16 <proyvind> if you have any interest in c++
13:23:20 <TrueBrain> either way, C, C++, STL, ... it is about preference, habbit, and pick-your-poison
13:23:27 <proyvind> it's a definitely book worth reading
13:23:51 <proyvind> notice the -Wefc++ flag in gcc
13:24:04 <proyvind> which is related to specific tips from mhis books
13:24:12 <TrueBrain> I personally write in both C and C++, and I have no issues with either one .. you just need to know when to pick which
13:24:56 <proyvind> reading his books made me much more confident about what and where to use different STL types, how to use and not to use it all the best and ++
13:25:18 <proyvind> making it a whole lot easier to be aware of what's being closer to "the best way" and all
13:25:26 <TrueBrain> you really need to know how a few STL things are implement to pick the best solution for your current problem
13:25:41 <proyvind> it's a complex standard
13:25:47 <TrueBrain> for that you need to know a bit about datastructures in general :p
13:25:48 <proyvind> but his books are covering a lot of these things
13:26:23 <TrueBrain> either way, back to Dune2: I strongly doubt it once was C++
13:26:32 <proyvind> which makes things a lot easier in a surprisingly easy to read and way to understand :)
13:26:54 <TrueBrain> C++ will never be 'easy' to read, as you can do a lot more dirty tricks :(
13:27:02 <TrueBrain> does not mean 1 is assigned to a
13:27:50 <proyvind> made me write a lot more efficient code in shorter time, enjoying it better without overanalyzing things too much, oletting over-critical perfection getting too much in the way
13:28:04 <TrueBrain> enough promoting a book already
13:28:15 <TrueBrain> you have stocks in them or something?
13:28:33 <proyvind> I'm just very enthusiastic about them :)
13:29:59 <proyvind> as I've been writing them a lot lately and they've really helped me getting closer to coding things more the ~"right" way and all
13:30:56 * proyvind is a bit OCD perfectionist when it comes to those things, so being uncertain about what actually being the best approach and all is something that tends to waste a lot of my time and keep me rewrting things way too often
13:31:11 <proyvind> or refactorizing might be a better word for it
13:31:16 <TrueBrain> sadly for you, there is no right way in C/C++ :P
13:31:19 <proyvind> aka not being very efficient
13:31:38 <TrueBrain> I mean, there are 6 mainstream coding styles for C alone :)
13:31:45 <proyvind> which is why I said ~"right"
13:31:54 <TrueBrain> just habbits and conventions
13:32:09 <TrueBrain> take OpenDUNE. Personally I don't care about 90% of the rules. There is just 1 thing important: that we all follow the same ones
13:32:15 <TrueBrain> as long as you do that, you get a good project
13:32:22 <TrueBrain> else, you can close the doors before you started ;)
13:32:52 <proyvind> providing STL classes and all, is a nice step in the right direction for reaching something more approximate to "standard/right" ;)
13:33:01 <proyvind> I'm a python d00d as well
13:33:17 <proyvind> so you can prolly' realise where some of my compulsion comes from ;p
continue to next day ⏵