SnT2k

Members
  • Content count

    50
  • Joined

  • Last visited

Community Reputation

118 Neutral

About SnT2k

  • Rank
    Member
  1. OpenGL OpenGL 3.0 canceled?

    Quote:Original post by Daaark 3) Sloppy docs all over the place. When I used to look up extensions, I'd go to the extension site and have to read through a long .txt file full of stuff about meetings and the purpose of the function, instead of just getting a clean function description, like the nice CHM file I get with my MS SDKs. I used to have a page at creative's site boomkmarked because it had a handle function listing without all that stuff. Why wasn't there on on OpenGL.org? +1 I find it really irrritating that the documentation doesn't provide sufficient code examples. Pair this up with the lack of description on how a group of functions are to be used (currently, the description only states "See Also" with a list of "related" functions and some inline links sprinkled here and there); the entire documentation could very well be an IQ test on abstract reasoning. Oh, and let's not forget the extensions list/reference which looks like (or IS) a bunch of delta patches with ASCII art that the developers have to "mentally apply". Moreover, it's hard to track whether the said extension has been promoted to the core in version X. To be fair, those are reference pages after all (so discretely defined functions are a bit expected). But having a programming guide to complement the reference pages would relieve some texts from the reference pages and, at the same time, provide a better guide on how to "properly" use the functions. Compare this with the documentation of DirectX which is pretty much self-sufficient; one can just read it and easily get started as opposed to OpenGL where one has to buy the blue/red book to see how those functions in the reference manual play together (The "OpenGL SDK" is very disappointed compared to the SDK of DirectX). Anyway, just my thoughts >_>.
  2. Starting...what language to pick?

    Quote:Original post by MaulingMonkey It wasn't my example originally. I'd prefer to rattle off a list of common causes of undefined behavior instead: Create another topic and rattle about it. Or even better, post it on your own blog. You're not helping our dear beginner here by posting a thesis worth of complaints on C++'s undefined behaviors. Oh, and your examples of UBs are really traps that a programmer should watch out when using any language that deals with memory addresses (which, of course, as of this time, only applies to C or C++ or probably any other languages out there). Yes, there are many traps compared to other languages but that's because of its purpose as a general programming language that can be mid to high level (you can get away with not using pointers), or low level (you get direct memory access <pre-empitive counter-argument: you don't handle the actual memory, but the virtual memory that the OS provides>). The same actually goes for any language, only you'll get either get Compiler Errors (good) to Exceptions (worse). Actually, come to think of it: with all those pitfalls because of the compiler or the lack of virtual machine doesn't shield you the flaws of the computer architecture.... it may also be good idea to learn C or C++ if you're interested in computer organization or leaning a bit more on the computer engineering side.
  3. Starting...what language to pick?

    Quote:Original post by chairthrower extern void do_something( int *p); void func() { int *p = new int[ 100]; do_something( p); delete [] p; } there's a big potential memory leak here, yet its typical c++ code that is seen almost everywhere. I don't see any problem with the code except for the possible exceptional execution of do_something(p), which, in that case, wouldn't matter whatever language you use ( Replace "int *p = new int[100];" with with something like "FileReader a = new BufferedFileReader("somefile.avi");" and "delete [] p" with "a.close()" and the same thing happens whether it's Java,C#,Python, or whatever language you have.) @MaulingMonkey: Thanks for the reference. But IMHO, your examples are probably a bit too contrived to start with (you win though). In any case, start off with Flex, Flex Builder 3 is free for educational puposes (www.flexregistration.com). I sent them an electronic copy of my School ID and they responded in less than a day.
  4. Starting...what language to pick?

    Just a tiny nitpick: "Undefined" behavior is not the same as "unexpected" behavior. So far, all the examples I've seen are "unexpected" behaviors. Not undefined ones. (Undefined behavior would usually be something along the lines of the order of evaulation of function arguments) Anyway, every "what language should I pick?" question almost ALWAYS ends up being a debate about C++ (geez, there HAS to be a law about this somewhere). As what the previous poster said, pick a language and stick with it for a while. Know the ins and outs of it and move to another language if you don't feel like you like it. In any case, don't get stuck up with one language. As for my recommendation? Try Flex/ActionScript 3.0/Flash. It's very promising especially with the next upcoming release which supports pixel and audio blenders (i.e. pixel shaders and audio units), some 3d graphics and FileReference support. C++ is also nice because it's fun to design your own types. C# or Java if you're scared of memory management... but that aside. C++ is actually better when it comes to general resource management (file handles, network sockets, IPC resources) thanks to deterministic destructors. (Well, C# has that using block so... yeah...) Side note: It's just my own opinion but I'd advice you to stay away from dynamically typed languages at least for the moment. You'll want your head to know the concepts of programming rather than memorizing what arguments to shove in x function and what it returns.
  5. My personal preference would be C++ because of the flexibility it gives you (Object Oriented? Object Based? or plain procedural? Pointers or references?) and because of templates which _almost_ makes the language dynamically typed. One instance a good use of its flexibility is one time when I had recursive code which does a lot of substringing: since I only get the substring of the last n - 1 chars, instead of passing a substring std::string class or passing the original string plus the offset, I just used pointers and it simplified the code a LOT. Despite of this I do believe that the language still has a lot of shortcomings. For instance, its ABI, #includes, and multi-dimensional dynamic array declaration/allocation (which can be fixed by tr1::array) needs a lot of polishing. One of the programming languages I don't like (more like hate) is Java. Mainly because I can't instantiate an array of generics nor can I instantiate a generic array and that it has no concept of RAII (which is why its scoping of try {} catch() {} finally{} goes against general scoping rules). However, I do appreciate its ease of use when it comes to importing libraries and the code analysis tools it has. Python, well I like it as a "system" but I can't get used to they syntax :P, same with Ruby.
  6. In my case, I would probably include the fourth element as a backup just in case one of the other three elements that I implemented didn't pass.
  7. It may actually depend on the function itself and the linker you're using. If a specific function gets called a lot of times (when I mean a lot, I mean a LOT), the function call overhead may kill performance (however, it's no different compared to calling a function in your program). Linking statically MAY cause your linker to inline some function calls in your code, eliminating the overhead. In anycase, if you're calling a function a lot of times (i.e. Texture::setPoint( x, y, color ) ), you're better off batching them which has a better chance of improving performance.
  8. GLFW or SDL?

    I would recommend against SDL because SDL's support for the Mac at the moment... frankly sucks. I tried to compile the SDL library on a mac and encountered mixed results. The worse problem is that it encounters some bugs when running fullscreen. Check the buglist of SDL, it's there.
  9. Filter Graphs

    er... you seem to have misunderstood me. As I was saying, I'm not interested in using DirectShow or using any filter graphs. What I'm interested is how its underlying implementation works. In other words, "how do I do something like that?" I'm trying to make my own audio filter graph and I have no idea how to implement filter graphs.
  10. I wish to know if there are any resources in implementing Filter Graphs such as DirectShow's filter graphs, Maya's hypergraph or Mac OS X's Quartz editor where a process is broken down into multiple units which interacts with each other. I tried searching for information about these but to no avail, the only results I found were either something about DirectShow or some algorithms about graphs (BFS, DFS, Djikstra etc.) One of my problem in implementing filter graphs is... where do I start and how do I traverse? Since the units can merge or split, tracking the the dependencies on each unit/node will be a pain. Has anyone have any experiences with this and could offer some advise or resources?
  11. I recommend "Computer Graphics using OpenGL" by F.S. Hill. Although it's a bit outdated (2001), it does give many concepts of computer graphics from 2d to 3d (unfortunately, shaders are left out) and it even has a TON of challenges (called "case studies"). Note that it's not really about game programming, but it WILL greatly help you when you do graphics programming.
  12. If you're developing applications, C# has a big advantage of C++ in terms of rapidness in development (just drag-n'-drop the controls and add event handlers: no messy WinProc and subclassing stuff) however, in terms of game development... there's no real advantage... other that .net handling the garbage collection and other nitty-gritties (like strings and arrays) for you, which could be solvable by STL or your own home-brewed library. it's not too bad to learn C# to, it may help you in creating level editors and stuff.
  13. WTL: http://wtl.sourceforge.net/ if you're using msvs2005, get version 8.0 And for your information, the entire WTL is only a series of header files, no .cpp, .lib to link to. The only thing that you have to link it to is the ATL libs... which is pretty lightweight and could be statically linked without any heavy consequences. Some comparisons of WTL vs. MFC: http://www.endurasoft.com/vcd/mfcwtl.htm Though it still have those idiosyncracies of MFC like those BEGIN_MESSAGE_MAP() and message reflections... and alternative is wxwidgets: www.wxwidgets.org or if you want a little more .net-ish: http://upp.sourceforge.net/
  14. 2D Game Programming

    Unknone: I know how you feel...... if you want to skip the crap, just scroll to the bottom of the post and read the second to the last paragraph. er.. after reading throu the posts, I just want to say to just shoot what you can for now. Chances are, you'll be able to learn another api or something sooner or later (ergo, you're brain isn't limited to learning only DirectX or OpenGL Graphics API or [insert your favorite x engine here] ). When it comes to presentation, what's important isn't how the API is designed/organized like DirectX's screwey COM interfaces + elegant OO APIs against OpenGL's straight forward gl* functions which, for the sake of platforms without C++ compilers, are not OO or like the ugliness of the Win32API startup code (WinMain and WinProc.. ungh) against the simple abstraction of SDL/Allegro/wxWidgets/Ultimate++ etc.... What's importatant is, repeating what others probably have said, understanding the concepts. In this case, know that things aren't just blitted to the screen; know that in order to keep the view intact (don't let the viewer see it drawn step-by-step - present the entire scene as a whole) do at least double buffering; know that in cases where resources (bitmaps loaded to video memory for blitting.. common in DirectDraw but not in Direct3D) are not managed, they have to be reloaded when the program loses the device; know that drawing fonts isn't like Microsoft Word, you have the option to pre-render the fonts to a bitmap for faster performance or have it generate at runtime for better quality... But make sure you don't go too far: you're making a game, not a vector/graphics/game engine. If the api provides you one, it's probably smart to use it. Then if it doesn't suit your needs, then replace the API call with your own algorithm. (I.E. Direct3D(and Allegro/Haaf's/[insert favorite engine here]) supports sprite transformation fuctions while DirectDraw and, probably SDL, doesn't, so if you chose the latter, good luck) Above all, know how to structure your program/game. Whether you want it frame-based or time-based, whether for a shooting game, you want the bullets to have an AI or just fly straight blindly - each calls for a different data structure, whether you want the game to be scripted at runtime by reading a file (i.e. use GameMonkey, Angelscript, Lua etc.) or compiled with the game etc. Know the pros and cons of the possible forks (I'm not saying EVERY) and from that, try to choose the best path - don't let the API limit any of this (in other words, abstract it from the API calls). As for those cross-platform stuff, if you do it in C/C++ (and not in VB/Objective-C... Java is probably ok though I'm against Java due to bad experiences) and abstract things carefully, no matter which API you chose, chances are you will only need to make little changes to make it compile to another platform (the degree may vary depending on the original api you chose, for example, SDL/Qt/GTK/Allegro/wxWidgets might make things a lot easier compared to using raw OpenGL or DirectX or Win32API/Motif/Xlib/Carbon). A caution however, screw cross-platformability for a while especially if you're learning as this make bog down your progress a lot; learn those after you "experienced" writing on a platform. To wrap it up, knowing that you're having problems compiling those 3rd party libs, I suggest you use what's "closest" to your environment - Direct3D, DirectDraw and GDI. DirectDraw is a bit primitive and nightmare-ish (you need to write your own transformation algorithms like rotation and scaling) but Haaf's Game Engine or some other stuff might help you, GDI is a bit slow but usable... finally, Direct3D, paired with D3DX, is easy to use (the D3DX provides a sprite interface which almost has all the stuff you need), but hard to get started (start-up code) and master (you'll eventually learn 3d in the process). If you're feeling a little bit adventurous, try Allegro and SDL, for those compiling issues, play with the Code Generation under C/C++ -> Compiler (MT, MTd, MD, MDd etc.) or exlude libcmt(d).lib in your linker options. P.S. Some might notice that I referred ogl, dx, sdl, allegro, gtk, win32api etc. singly as API, while some might object, it's because using interfaces provided by those engines/api both presents stuff to users - they basically do the same thing: to present. Another point is that I'm too lazy to refer to them separately from time-to-time :P
  15. What host are you using? Some host allow you to edit values via .htaccess while some allow you to override settings by placing a php.ini in the same directory (for .htaccess, place "php_value name value").