Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

306 Neutral

About Replicon

  • Rank
  1. Replicon

    OpenGL3 and NeHe relevance

    Quote:Original post by jpetrie I don't see why this would make anyone mad I figured, while my searches didn't turn up anything, it was probably asked before, because it seems like a fairly obvious question to ask :-) Quote:OTOH (again), I don't think NeHe is a particular good learning resource anyway. The code's pretty bad, and the explanations of the fundamentals are not sufficient enough for me. You have a lot of hands! I agree, the code is fairly 'bleh', and I wouldn't exactly use it as an example of good architecture by any stretch. And I always go to the official API docs with every new API call he makes. It's just a decent way of getting shown around in a modular fashion. If you can recommend a better source from which to learn it in a way that doesn't feel like a reference manual, I'm all ears.
  2. Hi, To avoid making someone angry in the OpenGL forum, I'm posting this here :-) I'm still very much an OpenGL newbie (slowly working my way through the excellent NeHe tutorials, using SDL + OpenGL). I read that OpenGL3 really fundamentally changes the API. The question is, just how fundamental is this change? That is, is the majority of the NeHe tutorial work pretty much obsolete, or do the changes only kick in for the more advanced shader stuff? I've only gotten to maybe lesson 6-7 and took a break for other stuff, so starting over with a very different API isn't the end of the world hehe... Also, if my video card supports OpenGL2, will everything I do with the new 3.0 API be software-only, or does it have a good conversion layer to still use the OpenGL2-based hardware acceleration? cheers!
  3. Replicon

    Compilation time.

    I don't know if such a thing exists on the Visual Studio world, but there is something called "distcc" on the GCC side of things. You basically have a list of boxes somewhere, and it delegates compilation tasks, in parallel, to various other boxes on the fleet. If you configure it right, you can bring the compile time down at least proportionally to the number of boxes involved. But again, I really doubt MS has something like that (but never know). Also, is it your compile time that eats up most of it, or link time? I've seen some stuff that takes forever to link statically.
  4. Replicon

    C++ map object and find()

    Before you throw an exception, though, decide whether it's actually an exceptional case (i.e. "not finding it is totally unexpected, and some weird error must have occurred [like having a typo in a config file]" as opposed to "well it's not cached yet so not found"). Another way to do it is to use a construct like boost::optional.
  5. Replicon

    Game Trailers

    If you're talking about the trailers showing some in-game action, then you could use a tool like GameCam or FRAPS (wikipedia them) to record some gameplay, and then use something like vdub to edit/combine them. vdub is open source, and GameCam/FRAPS are shareware you pay for... though GameCam just sticks a logo at the bottom right of your screen, which is easy to edit out if you know what you're doing (especially if it's out of your actual game play area within the screen).
  6. I wouldn't worry TOO much about programming jobs being outsourced. As was probably pointed out more than once, there is a HUGE communication problem going on, and when you can't do live feedback/updates as the project goes along, it won't work out, and will end up costing even more... cause now, you have to maintain a mountain of garbage. It all comes down to supply and demand. So the time you spend worrying about it could be better spent, say by making sure you're worth the price difference by being more competent/qualified, and keeping up with technology.
  7. Quote:Original post by rip-off Works for me... Hahahaha! Thanks, I really needed that. I'm out of caffeine, and that did the trick :-D. That will work, but you have to rename the file to .exe first haha. ...erm... yeah, I don't have a real contribution, the helpful stuff has already been said.
  8. Replicon

    File compression

    zlib has some really easy to use helper functions. Like it literally looks something like: compress(inBuf, inBufSize, outBuf, outBufSize); (with some requirements as to the minimum size of outBuf, clearly documented) You can do files, or random memory buffers... And of course, if you wish not to use the helper functions, the API allows you to do some pretty nifty things.
  9. You may want to revise the sentence before "...except pointers" ;-). When asked to rate their understanding of C++ from 1 to 10, the best candidates tend to claim to be in the 6-7 range hehe. Anyway, at its base, a pointer is nothing more than a memory address. It's said to "point" at the data in that memory address. Read up on how Linked Lists work. All the arrows in the diagrams are basically pointers. There's a super-common real life example right there.
  10. Replicon

    Math and Programming

    Well, if you want to formally understand/prove why some algorithms work, you need to summon the powers of math sometimes. That being said, I find the math portion of my programming is kind of a background process (i.e. doing complexity analysis without really thinking too explicitely about it, etc.) For the most part, I think it's more of a correlation that people who can wrap their heads around solving programming problems can generally wrap their heads around math problems as well. As far as "type of math" goes, I guess discrete math has the most direct translation into programming...
  11. If this pattern expands a whole lot for you, then it sounds like you might be interested in reading up on Policy-based design. It's fairly advanced, and possibly not the direction you want to go, but it's definitely an interesting brain exercise at the very least :-).
  12. Replicon


    It really depends on what it's used for. What are you planning on putting into your DB?
  13. Replicon

    inserter operator woes

    Quote:Original post by Antheus Another reason which isn't shown here is that template magic regulates which log statements get compiled, and logs that are useful in debug builds are never generated for release builds, even without any use of macros. Hey, thanks for that, I'm really liking that approach. Can you expand a bit on that last part? I was originally going to use an uglyish macro for this, but if you say the template magic fixes that, then I'm all ears. Drigovas, I definitely want to enforce log levels, which is why I didn't go the iomanip way. cheers
  14. I guess this counts as a newbie topic, since this is the first time I play with operator<<... I'm trying to implement a very simple logger that does two things: - log levels - outputs log to as many streams as I want it to. Roughly speaking, the usage looks something like: Logger log(LogLevel::WARNING); log.attachStream(std::cerr); // and any others, say file handles.... log << LogLevel::ERROR << "uh-oh, " << 75 << " errors occured...\n"; Currently, I don't yet have the LogLevel stuff working. So if we ignore the loglevel, it's pretty straight forward: template< typename T > Logger &operator<<(Logger &logger, const T &x) Then, just keep shoving what you get into all the streams. But right off the bat, I am seeing an annoyance: I'd like to be able to call flush() on each of my output streams ONCE per "line of code" (for the lack of a better way of saying it). In other words, for something like: log << 1 << 2 << 3 << 4 << 5; I want to call flush() just once, after the whole "12345" has been shoved into my streams. Is there a way to do this without having to write a Logger::flush and call it manually? I'm thinking 'no'. And I'm thinking it probably doesn't matter (depending on implementation of flush I guess), but it's worth a shot hehe. Secondly, I'm not really sure how I'll put the log levels in there. Should I just change the operator<< above to have these two instead: template< typename T > LogLevel &operator<<(LogLevel &logLevel, const T &x) Logger &operator<<(Logger &logger, LogLevel &logLevel); and then have the loglevel one maintain an ostringstream, and have the Logger's operator<< look at logLevel and decide whether to publish the data? The problem I forsee there is that there's probably no guarantee on order of execution, so instead of the desirable: operator<<(log, operator<<(LogLevel::WARNING, "test")); It might try something goofy like: operator<<( operator<<(log, LogLevel::WARNING), "test" ); Which would not even compile... Thoughts?
  15. Replicon

    undefined reference to 'SDL_SetVideoMode'

    Yeah, you probably want to add -L"C:\SDL\SDL-1.2.10\lib" (or where ever you installed it).
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!