enunes

Members
  • Content count

    38
  • Joined

  • Last visited

Community Reputation

123 Neutral

About enunes

  • Rank
    Member
  1. Can I avoid the hassle of these IDE's?

    I believe I understand you in this regard, and I encourage you to go ahead without the IDE. I use Linux only and, except for the first six months when I was learning to code, I have never again used an IDE for programming in my life. I work with embedded software and I can tell you can build and debug any arbitrarily complex piece of software without one of these clumbered IDEs. In my opinion, one can't actually be serious about programming in C++ if he/she doesn't know enough about how a C++ program is built from source and what are the tools and steps involved in the lower levels. Apart from software bugs on the IDEs, I can see how "obscure" linking problems would be. Googling and hoping for some blog documentation to exist on the specific problem would then become the help resources. All you need is a powerful text editor (maybe vim), knowledge about the build flow and compiler options (how to tell include and linking directories, linking options, how to build with debug symbols or optimizations) and learn to write Makefiles to automate and customize that.
  2. This is a nice article related to your question, in case you haven't read it yet: http://dewitters.koonsolo.com/gameloop.html
  3. Hmm, just a heads up; I guess I was denied permission to clone your repo: ~$ git clone git@gitorious.org:md3simpleloader/md3simpleloader.git Cloning into 'md3simpleloader'... Permission denied (publickey). fatal: The remote end hung up unexpectedly EDIT: nvm, got it. Had to add a public key there. new considerations: 1. had to chmod +x configure 2. had to make clean (to remove the existing .o objects in src, are they supposed to be commited?) 3. I copied the data folder into src as I don't want to run make install 4. running simplegame crashed here on a glBufferData(). didn't debug much.. there goes, in case it's helpful: [code]Program received signal SIGSEGV, Segmentation fault. 0xb7ca3dfd in __memcpy_ssse3 () from /lib/libc.so.6 (gdb) bt #0 0xb7ca3dfd in __memcpy_ssse3 () from /lib/libc.so.6 #1 0xb5b8f221 in ?? () from /usr/lib/xorg/modules/dri/r300_dri.so #2 0xb5dad588 in ?? () from /usr/lib/xorg/modules/dri/r300_dri.so #3 0xb5d49b9a in ?? () from /usr/lib/xorg/modules/dri/r300_dri.so #4 0xb5d075c0 in ?? () from /usr/lib/xorg/modules/dri/r300_dri.so #5 0x0804b71f in GameAsset::make_buffer (this=this@entry=0x8138470, target=target@entry=34962, buffer_data=0x813c218, buffer_size=202116108) at GameAsset.cpp:102 #6 0x0804ba6c in GameAsset::make_resources (this=0x8138470) at GameAsset.cpp:158 #7 0x0804ccc2 in Md3Asset::md3ModelLoad (this=this@entry=0x8138470, filename=filename@entry=0x804e98f "data/mario/HEAD.md3") at Md3Asset.cpp:177 #8 0x0804d0ad in Md3Asset::Md3Asset (this=0x8138470, filename=0x804e98f "data/mario/HEAD.md3") at Md3Asset.cpp:5 #9 0x08049ce0 in main (argc=1, argv=0xbfffe8a4) at Main.cpp:105 [/code]
  4. Make and Makefiles

    Also, consider Makefiles are generic in sense they aren't limited to calling your compiler. You can do anything you want in them, as long as you have some, uh, "command line" skills. Consider an environment where everytime you want to "build", you not only want to compile your code into an executable, but also to run stuff like: run scripts that auto generate documentation, run programs that check your code, generate some of the source code automatically prior to compiling, and after all, create a final product (think of creating a compacted file) containing arbitrary data (such as models and textures as this is gamedev) plus your freshly compiled executables. With a properly written Makefile you can usually do that by just running "make". (I don't have any Windows development experience so I don't really have a clue on how you would do that without make or some case specific and probably clumbered tool).
  5. Feedback to my game project: Maze Rush

    Hey Sharpe, thank you for your reply and for your suggestions! [quote name='Sharpe' timestamp='1320370458' post='4880349'] I'm surprised it seems the opponents start in the same location as the player. Maybe have them all start in a different location trying to reach the center of the maze. They'd all start the same distance away, roughly, of course. [/quote] Yeah, I agree that doesn't look much good However it was the simplest way to do so. The problem with starting in different places, like aside each other, is that maybe it isn't fair with the current "winning" model (reaching the final position). Reaching the center of the maze is a nice idea, however I would probably have to limit the number of players (like 4 for starting in the 4 corners). Limiting players is something I was trying to avoid [quote name='Sharpe' timestamp='1320370458' post='4880349'] Lasers that damage or even destroy opponents would be cool, as I'm sure others will suggest. You would re-spawn back at your beginning location, or maybe at the opposing color's start. If you decide to add combat aspects, there could be different contestant types utilizing varying degrees of: [list][*]Top speed;[*]Acceleration;[*]Attack Damage;[*]Attack Range;[*]Armor;[*]"Hit Points."[/list] Of course, attack damage and range could also depend on power-ups or weapons. The player could either chose a character that has different levels of those characteristics, or set them with a pool of points, or whatever. Power-ups then could effect these characteristics. Just some ideas off the top of my head! Keep up updated!!! [/quote] Yeah when I showed an earlier release to some people they were like "so, where are the weapons and explosions?". I'm trying to stay away from combat aspects though. I think adding combat will turn it into "just another fps game". Also it adds too much complexity that would require alot of changes (time). But I really liked your other idea! [quote name='Sharpe' timestamp='1320370458' post='4880349'] Pits of acid/lave that need jumped would be cool, as well as other traps like smashing walls. Even a spring board that shoots a contestant to another part of the maze might work. Different terrain, like water or deep mud that slows down contestants might work -- or even a fast conveyer belt. A random power up that either slows the player down or speeds them up -- who knows? -- would add another player choice. How about transparent air tubes that suck players inside and loops them over the maze quickly to another location? [/quote] That's something that I hadn't thought of really. I'll note that down and I think it really fits what I'm looking for! It does also kinda complicate the robots, but that seems much less intrusive because I can include one obstacle a time. With the addition of these (mainly the teleport tubes), a few power ups (like compasses, maps!) maybe players can start solving big mazes Right now I guess I should at least give it a decent interface. The least fun part, but oh well. Adding a decent menu with a couple buttons for configuring options should do.
  6. [media]http://www.youtube.com/watch?v=EgemhoV42Lo[/media] Hey, My little learning project is called Maze Rush (formerly generically called Labyrinth). Maze Rush is a game where you race against AI robots towards the end of a maze. The maze is automatically generated by the program and a new maze random is generated every time the game is launched. Maze Rush runs on Linux (just not tested anywhere else actually). Maze Rush is open source with source tracked at [url="https://github.com/enunes/mazerush"]https://github.com/enunes/mazerush[/url] Most of the code is homemade and done for own learning purposes. No engine, just a game. Uses libraries for: window/input handling, text rendering, matrix math. I had created a topic on an earlier release of this before, but in a less populated subforum. I thought I'd just give it one more try here in this new release. Most notable functional features accumulated to this release: - A new, size configurable random maze is generated automatically every time a match begins; - You can choose between two algorithms for maze generation (Prim and Kruskal); - You can configure the number of robot enemies, (and their names and colors); - Three types of robot AI: standard DFS, "smart" search (avoids obvious dead-ends) and dumb (totally random movements); - Shows ranking of finished racers with time and difference from first; - Collision handling against walls; - Player is allowed to freely fly in 3D and explore over the maze after reaching the end of the maze; or also camera-follow other robots. Language: C++ ; Runs on: Linux; Uses: OpenGL, OpenAL + alut, glfw (window/input), glm (OpenGL Math, matrix library), ftgl (OpenGL fonts rendering library); Tools used: blender (the robot model), audacity (to make the audio loop that got ripped off on the video), gimp/imagemagick, Linux development environment (vim, make, g++, gdb...), git/github. I'd appreciate some feedback and maybe some ideas on how to make it more fun. Mostly gameplay features and maybe visual effects. I do have plans to enable some multiplayer support but that's not for now as I still have a bit to learn there. Thank you for your attention!
  7. Hey, I thought I'd share about this little game project I have worked on (and sometimes still work on) during free hours. It's called Labyrinth. Labyrinth is a game where you race against AI robots towards the end of a maze. The maze is automatically generated and a new maze is generated every time the game is launched. Labyrinth runs on Linux only (at least it was only tested only on Linux). Labyrinth is open source (link to source below) and most of its code is homemade and done for own learning purposes. [media]http://www.youtube.com/watch?v=17K6b7GrAWk[/media] [size="1"](Video BGM Credits [url="http://www.jamendo.com/en/album/86120"]http://www.jamendo.com/en/album/86120[/url] )[/size] I call the current version 0.6. The previous versions were mostly development versions reaching some sort of milestone. Currently it features: - A different random maze generated automatically every time labyrinth is run; - Maze size is configurable; - You can choose between two algorithms for maze generation (Prim and Kruskal); - You can configure the number of robot enemies, (and their names and colors); - Two types of robot AI: standard DFS and "smart" search (avoids dead-ends); - Shows ranking of finished racers; - Some sort of collision handling against walls (not great visually but does the job so that you don't cheat) I take as goals for a 1.0 version: - Allow players to start a new match without having to launch the game again; - Provide a main menu for game start/quit/basic configuration; - Menu configurations should be number/parameters of enemies, algorithm, size; I know there could be lots of other features but I guess for it to be an at least distributable game this is the least necessary. I also find adding a menu to a game like this much more complicated than creating the whole game. Labyrinth is written in C++ and uses only OpenGL, glut, OpenAL, alut and glm (gl mathematics). The game uses .wav files for music, .obj files for models and .tga files for textures. The loaders are part of the source. Models were made and exported with Blender. Music loop was taken from some free web source and cut with Audacity. Textures were also taken from the web and edited mostly with The Gimp and Imagemagick. The source code is fully available on a git repository at: [url="https://github.com/enunes/labyrinth"]https://github.com/enunes/labyrinth[/url] There is also a readme in on github with some more info. If you happen to watch/test it, I'd really enjoy some feedback! I'm also accepting suggestions and bug reports. My site (with my contacts and a few other stuff) is: [url="https://sites.google.com/site/nuneserico/home"]https://sites.google...nuneserico/home[/url] . I'm also at @nunes_erico . Thank you for your attention!
  8. OpenGL Best openGL resource

    I like this one: http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html It was quite easy to follow, though I had already used some fixed functionality before. I'm not sure if it's easy to catch for a starter, but at least it states no previous OpenGL experience is required...
  9. hmm maybe another option would be scale the world size using the same heightmap? That is, the same map with "larger triangles"...
  10. Worm physics/movement

    [quote name='wqking' timestamp='1308283317' post='4824339'] Greedy snake? 1, Store the head's current position 2, Move the head to new position, only the head 3, Store the first body part's current position, 4, Move the first body part to the stored head position, 5, Repeat for all body parts. In brief, the next part move the previous part's old position. This assume your worm won't be stretched. [/quote] If this is tile based and the body is stored in a list (or deque) considering the head is the first element of the list, I suppose you could just: 1. add a new body tile at the new position, before the beginning of the list; 2. delete the last body position This will make the body work sort like a queue, and will automatically handle all the body tiles moving. Not entirely sure it will work for non tile based though..
  11. what C++ IDE & OS do you use

    Whoa, more arch linux users here then?! Another vim user here As for the poll, I don't like the fact Linux is rightly associated with Ubuntu. Any ditribution other than Ubuntu is a "Linux derivative"?
  12. hash tables vs stl map

    [quote name='frob' timestamp='1302885650' post='4798826'] Being picky: std::map is part of the C++ standard library. As mentioned, it has performance requirements that must meet or exceed a balanced tree. hash_map is NOT part of the c++ standard library, nor is it part of the proposed standard. It is a non-standard extension found in several implementations, and should not be in the std namespace. (The standard specifically states that non-standardized modifications to namespace std are undefined behavior). Performance requirements are not standardized, there are no requirements about a "true hash table", or specific other requirements. What you describe may be true of your hash_map, but there is no assurance about any other implementation, or that the class even exists at all. @OP: Learning C++ means you should have known about the C++ standard library, including the containers. If you don't know about them, I suggest you go learn some books about the language, such as "Accelerated C++" by Koenig and Moo to learn more about the language generally, or if you want to focus on the standard library, "The C++ Standard Library" by Josuttis. [/quote] Theres [url="http://msdn.microsoft.com/en-us/library/bb982522.aspx"]tr1::unordered_map[/url] which, as far as I understand, is part of the proposed standard and implements a hash function to achieve O(1). Not an expert and I don't deeply know the specification, but that's also an alternative
  13. I have a question on this. How strongly does this impact development/graphics programming? Assuming this technology is available in a, say, ten years future, does something like this cause a dramatical change in graphics development or can the current development model still be used? That is, is this change more of a graphics pipeline change (somewhat not affecting much the final developer) or more like needing a total graphics API redesign?
  14. [quote name='Faireth' timestamp='1301927759' post='4794217'] I have read that picking can provide you a 'name' for the selected hexagon. What is an effective method of linking the 'name' with the other information? [/quote] I believe this 'name' you mean is related to the (old) OpenGL picking system. It is based on re-rendering the whole scene when you click but on a 1x1 viewport around the mouse click position, and OpenGL puts the "name" of every object which was clicked on some stack. I don't remember well how you assign a 'name' (which is just a number) for each object though. You could just assign an index for each hexagon and have an array containing all the hexagon informations. When you have detected which hexagon was clicked, get the index and get the information from the array at that index. That's usually how I solve this kind of stuff. It also allows you to get hexagon indexes/references from somewhere else without having to copy all the hexagon information.
  15. Tools/advise for non-artist?

    [quote name='Wan' timestamp='1300376930' post='4787056'] I personally use [url="http://www.wings3d.com/"]Wings3D[/url] a lot for (place holder) models. [/quote] I was just going to recommend that. I use Wings3D too and find it pretty easy