rollo

Members
  • Content count

    415
  • Joined

  • Last visited

Community Reputation

366 Neutral

About rollo

  • Rank
    Member
  1. OpenGL programming for ATI 9250

    hmm, I didnt think that card could do SM2. Are these extensions supported: GL_ARB_shader_objects GL_ARB_vertex_program GL_ARB_fragment_program
  2. thanks for the reply guys. I will be making a minimap-like thing also, but what I really was after was a way to cut down on graphics memory use of my map. its a pretty big map, so I need to run some mesh simplification algorithm on it. The important part is that there are certain vertices the algorithm must not touch. I'll have a look at hoppe's stuff as suggested
  3. Hello, I need to implement a method for simplifying geometry for a "map", and googling isnt very helpful when half the worlds academics have written a paper on the subject... so I thought I'd ask you guys for tips. - My data is generated from bitmaps. One specifies regions, the other is a hightmap. - Edges between regions must be left intact and not moved. Basically, edges are marked in the geometry, so the algorithm must be able to leave those alone. - Simplification should be done for each region in isolation if possible. - This is a preprocessing step, so performance isnt as big deal as it would be otherwise. Ease of implementation and robustness are much more important. Very grateful for any pointers to good papers or example implementations.
  4. Meta server system

    He must be doing large quantities of Bullshark Testosterone :D Genetically different, baby!
  5. Quote:Original post by bubu LV 8. I don't prefix enum values with any symbols. When I need namespace for enum I do: struct SomeEnum { enum Type { FIRST, SECOND, }; }; I do this as well, but with a c++ namespace instead of a struct. Why use a data structure when all you want is a prefix. Of course, if it is connected to data in some way bubu's way is the way ;) I got my whole coding convention available here if anyone is interrested. It reads kind of as-is, but can be run through doxygen to look better: codingstyle.h It kind of grew over the years :)
  6. Improved Alpha Magnification

    Unless you do this for work and have to support old hardware I say this: People with crappy intel graphics cards DON'T DESERVE nice graphics. damn, it felt good saying that....
  7. On Pair Programming Part 2

    I'v been planning on writing a long reply to your previous post on the subject, but never got the time, so I'll just write some short observational stuff here... I'v done Pair programming and XP reasonably seriously, and I ran into the same things as you pretty much when starting out (although this was not in game development). 1. Development methodologies shouldn't be Laws. Use what works, dont use the rest. Just as you say, if something is trivial there is no point in pair-programming it. *however* defiantly stick with it now while you are learning, it takes longer than you think at first before you really make the mental switch, and its better to just go 100% by the book at first. 2. you will sometimes run into a pair-mate you don't click with at all. Many places rotate people between pairs, but personally I prefer people picking their own groups. Another way which works really well for breaking in new recruits and getting them up to speed is to pair them with a more experienced programmer thereby teaching/spreading the knowledge. Of course, this can be frustrating for the senior since it will feel like he is being slowed down, but I think it defiantly makes the overall team stronger in the long run. 3. 100% pair programming unfortunately requires that you work at the same times as your partner :( 4. you talk about scheduling problems. what if you kept on pair programming? bring your partner and solve your bugs, then solve his. you will both gain knowledge of each others code areas, which can only be a good thing. 5. a tip: if you notice you both aren't speaking, there is probably something wrong going on. 6. speedwise, it is usually quite a bit faster than normal speed when pair programming, so you shouldnt really write it off as half of the time wasted (although this is certainly true in the beginning). 7. I like two machines placed next to eachother instead of just one. This way the partner can google solutions, looks up API stuff etc etc instead of those idle moments you speak of. also if you have a bunch of really simple tasks that require no pair programming it is less of a shift to do them sitting next to eachother.
  8. Gui library

    wxwidgets if you want a proper application. cegui is for simple ingame gui. you might want to check out trolltech's Qt as well, its supposed to be good.
  9. here is another idea: use a texture atlas, eg put all your textures into one big texture. that way you dont have to switch and can render all objects in one go.
  10. best game engine below 7000$

    Quote:Original post by Jazonxyz WOW! I should make my own overpriced engine ;-) considering the amount of time and manpower it takes to make a full engine and polished tools I'm not sure its that overpriced. Especially considering the small market to sell it on.
  11. Its using recursion to do the calculation. if you are unsure of this do a google search. The best way to understand small functions like this is to take a piece of paper and write down the flow of execution. I'm sure after writing a few lines you will get how it works
  12. Quote:Original post by c_olin Yeah, I definitely see why a setting would not be a good idea in that case. But what about the camera class? I've already run into places where I need to change the FOV or the target from outside the class. Is it a bad idea to have both a getter and a setter for the FOV or the target vector? Should it be public? On the camera you definitely don't want data like FOV etc public because: 1. this will lock you down to a single internal representation of a camera 2. you cant manage stuff like "recalculate view matrix when user want to change FOV automatically" without some encapsulement. Things like this have to decided on a case-by-case basis. If you have POD type (plain old data, like vector etc) you don't want accessors. If you have something where its a gain to hide the internal representation and you have a feeling it might change in the future (this stuff is all down to experience). If you are unsure, go with accessor methods. it better than having used public data and suddenly need to hook in some extra logic when that data is changed, but as mentioned above, going the old Java route and making everything public will spread out solutions to particular problems and increase dependencies between classes.
  13. Parallax mapping

    all true, but to be honest parallax mapping tends to stand out more (pun intended) when the camera is moving
  14. Assert Sucks

    Yeah, I think everybody ends up writing their own asserts. If anyone wants to do so, this is a good starting point (it will illustrate those tricky details you mentioned): Stupid C++ Tricks: Adventures in Assert.
  15. Effective Coding(Books)

    Code Complete is very good, it mainly contain advice applicable to any programming language, so 2004 doesn't mean its too old. I'm going to suggest something you can try: Stop commenting and write unit tests for you code (junit for java is good). I'm not saying you should never comment, but see it as an exercise. If your code needs comments its probably more complex and hard to understand than you want. Unit testing has an advantage over comments, they will not go out of date, and will show the programmer who is trying to understand/use your code exactly how it works with post and pre-conditions.