NQ

Members
  • Content count

    233
  • Joined

  • Last visited

Community Reputation

328 Neutral

About NQ

  • Rank
    Member
  1. Normally, if you want a really good toolbox, then you're not looking for a SINGLE tool which has all things in it. You're looking for several tools to use in combination. Well it's hard to determine how experienced you are, so i'm going to make two suggestions: If you're not very experienced; Download SDL and code all the really cool physics yourself. I'm talking about 2D here. Because it's easier in so many ways. There ARE 2d physics libs which you can download and use with SDL, BUT if you're really into problem solving then I suggest you code it yourself. 2D physics is easily within reach of the lone programmer. If you're more experienced; Download Ogre3D engine, and learn how to couple it up with a real physics engine. There are a few which works better with Ogre than the rest, and I think PhysX is the best and i also think it's the one that bundles best with Ogre, but that's up to you. There's several more engines. Have a look here: http://en.wikipedia.org/wiki/Physics_engine#Real-time_physics_engines Hope that helps!
  2. Ogre3D Scene node position

    I am a Ogre noob myself, but it appears to me that all the things you said are correct, except for the Scene Graph thing which I don't know if it's true or not. Why lights have a position and entities do not, I don't know, but it is that way. All positions are relative to their parent. So first you make a node the child of something, then you set the childs coordinates to zero, which centers the child onto the parent. All movement which you do to the parent, always also happens to the child. All nodes which are children of the "root" sceneNode are sortof in global space, and move in their own. So to say. I advice you to ask further questions in the Ogre forum at ogre3d.org, since there's way much more people around to answer your questions quickly.
  3. Element: Space-Trees (addition) = Due to zero-gravity, they don't grow in straight columns, but rather as clumps originating from a central point, sprouting out in all directions. Often they clump together due to their up to twenty meters long roots getting tangled up. In this manner they might even form kilometre-long chains of trees, if they don't tangle up completely. Some small lifeforms inhabit these floating forests.
  4. Posting a summary so far....... ---Place Holder for all the Elements for quick reference---- Genral Information - Title: Genre: Action Role Playing Game Story Information - Characters: Main Character = one element of the main character's internal conflict is their attraction to the villain and uncertainty over whether to act on this or not. The attraction comes from a combination of feeling sympathetic for the bad treatment the villain receives, and admiration for the villain's cleverness, creativity, sense of humor, and/or admirable goals. The player's choices determine whether the main character does or does not pursue this attraction. Secondary Character = The grandfather of the main character. The common aloof grandfather that seems to not pay attention or not care about what is happening around him, but more often than not shows great wisdom when things get serious. He seems to have more knowledge about the events that are happening around the main character, and possesses many powerful techniques that he employs over the course of the main character's adventure, but ultimately disappears when he feels like the main character doesn't need him any more and might start using him as a crutch. Monsters: Orks = They continually attack the human villages and caravans. They sometimes lie in ambush along paths through the space-forests of space-trees. Space Trees = Using advanced space-age technology, Tree's took to the star's to escape decades of persecution on their homeworld. They now control a vast empire spanning the galaxy, roaming from place to place in dense "forests". When threatened they crush aggressors in a falling motion, strangely while not making a sound. Battle System Information - Abilities/Spells: Rune Shot = This is a combat technique cooperatively used by an Archer and a Caster. Magical rune is attached to arrows. The rune is activated when the arrow defeats an enemy. When a triangle is formed by three activated runes, the runes deal massive damage to enemies inside the triangle. World Information - The Paddle Transport System = After centuries of using paddles for combat and for rowing boats, the orks finally perfected their invention. A massive hundred-metre-tall wooden paddle, powered by an intricate system of pulleys and springs, can launch any passenger into orbit. By throwing them in a catapult manner. The orks got far with this, and now a complete paddle transport network is arranged between the planets of most solar systems. Humans and other races pay toll to the orks for using the paddles. Human history of space travel = Humans that are launched by the Ork paddle settled in space and continued their lives as space cowboys. Item Information - Weapon: Ork Paddle = A giant two-handed recreational paddle used by a notorious Ork/Gremlin robberer team to stop caravans and to drive resisting humans out of sight.
  5. Element: World Information: The Paddle Transport System = After centuries of using paddles for combat and for rowing boats, the orks finally perfected their invention. A massive hundred-metre-tall wooden paddle, powered by an intricate system of pulleys and springs, can launch any passenger into orbit. By throwing them in a catapult manner. The orks got far with this, and now a complete paddle transport network is arranged between the planets of most solar systems. Humans and other races pay toll to the orks for using the paddles.
  6. I am not sure why this happens, but if you insert the changes I suggested in the other thread about the other problem, this problem should vanish too.
  7. SDL - Getting slow framerate

    Okay, generally it is a very bad idea to require your game to run at a fix speed. This is because it works very strange on different computers, which you noticed. The only time it is okay to set a fix speed is if you're making a game for a console. In that case you know you will always run the game on the same hardware, every time. All other times: bad idea. I see that Box2D is made in a peculiar way. It suggests that once you decide the timestep you do not change it because this makes the simulation worse. This is very odd for a physics engine, which most of the time is simply tied to the regular game loop. All other physics engine I've come across EXPECT to be passed the actual specific timestep for the actual specific frame, every frame. So this is strange. Since games generally do not need to run at 60 FPS, I don't suggest you focus on blitting your graphics faster. As I see it, there are two ways for you to solve this problem; 1. Simplest solution; Simply treat Box2D like all other physics engines, and pass it a new timestep for each and every frame. The engine will have to deal with it. 2. Almost as simple solution; At the beginning of the program, perform simple test to see how fast the current computer is, and set a constant timestep based on that. The above is my real suggestion. BUT if you instead REALLY WANT to make the FPS go faster, I suggest you start using a time diagnostics tool of some sort (sorry I dont have a link at the moment) so that you can find out what specific parts of the game loop that is taking the most time. It's just like this: long startTime = getTime(); doFunctionA(); long endTime = getTime(); cout << "doFunctionA took " << endTime-StartTime << " milliseconds to finish."<< endl; And do that with each and every function. But I suggest that you do it in a more elegant way rather than doing it exactly as I said. Maybe calculate sum of all parts so that when you stop the program it prints out a report of how long it took to complete each part. That would be better.
  8. SDL Beginner Help!

    Oh! I just read the tutorial you intended. You linked to the wrong page! I had to click around to find the thing about the speed and stuff. Now I better understand exactly what you asked for. First do the modifications I mentioned in the above post. This gives you a variable speed. But it is FRAME RATE DEPENDENT. That means if you run the same code on some other computer that is twice as fast, your character will move twice as fast, because the game loop ticks twice as fast. You do not want this. You want all players who download the game to have the same experiences, no matter how fast computers (frame rate) they got. We accomplish this by multiplying the TimeSinceLastFrame with the speed! Notice that all your position variables must now be doubles. SDL_Rect gubbeposition; // this is bad because SDL_rect structure only has integers in it. You need to make your own class, so we can have all positions as doubles. This will be useful in the future. Like this: class Cgubbe { double x; double y; double speed; string name; }; Cgubbe gubbe; gubbe.x=100; gubbe.y=100; gubbe.speed=2.7; gubbe.name="Bosse Svensson"; And in the beginning of each frame: long beginTime = SDL_GetTicks(); long timeSinceLastFrame = 0; while(gamerunning) { timeSinceLastFrame = SDL_GetTicks() - beginTime; beginTime = SDL_GetTicks(); // ... main code ... } And FINALLY your gubbeposition.x += gubbeSpeed; commands need to change into gubbe.x += gubbe.speed*TimeSinceLastFrame; That's all. So if we got a fast computer, the TimeSinceLast number will be very small, and that will make the gubbe make small jumps between each frame. If we got a slow computer the TimeSincelast number will be large and the gubbe will make bigger jumps. Now we have FRAME RATE INDEPENDENT movement. Now he moves with the same speed on all computers. You will have to figure out how to draw the image where you want it to go yourself. You'll have to round off the position to an integer somehow, and then somehow pass the right values to the SDL_BlitSurface() function. I recommend creating a helper function which makes things easier in the future. Something like: void DrawImage(surface, atSurface, atLocationX, atLocationY); Good luck!
  9. SDL Beginner Help!

    First of all, welcome to the GameDev forums =) I'm going to answer your questions, but first let me advice you on how you should do from now on if you want help from people on GameDev ;) 1. Please post long code within code-blocks. This makes posts that contain code much easier to read. Please make posts easy to read if you want help. Many people will not answer posts if they are too difficult to read. See the forum FAQ for info on how to do that. 2. If you post short code, it doesn't matter if it's in code blocks. 3. If you post code: make sure it is commented. In ENGLISH. Not swedish ;) You're lucky I happened to be swedish, so I could read them without getting upset. :P Even though I'm swedish I always write code and comments in english so that I can quickly ask anybody for help without having to translate everything first. Okay, so let's get on to the solutions! Yay! Your game loop (and most other game loops as well) updates like this: * First do game logic and draw stuff to screen buffer (5 milliseconds) * Then sit and wait for the next flicker of the screen (lots of milliseconds) * Instantly swap the old screen image for the new one (0 milliseconds) * Start loop all over again (0 milliseconds) One pass through all that is called a frame. Or a tick. As you can see, the whole process takes 5 + lots + 0 + 0 milliseconds in total. The wait-for-screen part is done within the SDL_Flip(screen); command. All this makes the game loop run with a constant framerate. So your game loop is normally executed some 100 times per second (this may vary depending on the system). You want it to always be like this. In order to make your character move around faster, you DON'T want to make the game loop run faster. That speed is mostly constant. Instead you want the character to move further for every frame. You do this by changing all lines that look like this: gubbeposition.x -= 1; into lines that look like this: gubbeposition.x -= gubbeSpeed; And to be able to do this we must of course have a variable called gubbeSpeed: bool gamerunning = true; bool keysHeld[323] = {false}; // everything will be initialized to false int level = 1; int gubbeSpeed = 2; Ta-daaaaaaaa! I just made your "gubbe" move two pixels every frame instead of just one! Try playing around with that value, just for fun. You will find that he does no longer wrap around the edges when he moves. That's because of this; if (gubbeposition.x == screen->w) { ... } Which now MIGHT not happen, because of the bigger jumps we just made him do. Instead you should have: if (gubbeposition.x >= screen->w) Good luck!
  10. Networking concept

    I think I understand your problem, even though it was loosely defined. But I recommend that you search these forums for the answers you seek. Just choose some likely search terms. Here's some things I found that might provide partial answers to your question: Link 1 Link 2 Those, and other you find if you search, might provide further clues to the solution to your problem.
  11. Education

    I also believe that most good game developers/programmers got good not because they went to some education and got a degree. They're good because they spent hundreds and hundreds of hours in their spare time, cranking out code and miscellaneous designs, because they felt it to be soo much fun. I know of roughly 15 programmers. ~12 of them are real good. ~10 of those who are real good have spent hundreds of hours in their spare time doing this for fun. Myself, I estimate I must have invested far over 1000 hours of spare time over the 10 years since I was 15, maybe as much as 4000 hours. Just doing hobby fun stuff and learning new things. As for which education is most sought-after I cannot answer because I do not know. I got my current job as an AI-programmer based solely on the things I've done in my spare time. Not once did they ask me what education I got. They just asked me what do I know, and what can I do. Other employers are probably different.
  12. How to start game designing

    Dhaher, here's a perhaps better suggestion. First of all, from how you asked the question it seems you are not quite clear about what to specifically ask. So therefore I suggest you first read the things you need to know on this page: The Beginner FAQ There you will find the differences between "designer" and "programmer". You will also find a good (but brief) comparison between all the available programming languages. You will also find a description of all the basic things you need to be familiar with, such as: Compiler, Library, Engine, API, SDK, IDE.... and so on. After that, I suggest you read through almost everything on this page: How do I get started? There's alot of good advice in there, which will save you many hours of time if you apply them. That should give you a good starting position, and give you a clue about where you'd want to move from there. Good luck!
  13. Title Screen

    I think Kest covered mostly all of the advice I could have given. I'm just posting to say that I agree with all of Kests points.
  14. I see. It's kindof nice to find out that it is plain and simple impossible, because that allows me to move on and think about other stuff. Solution: I have currently flattened the whole map, and I'm working on other things. Hopefully that'll lead to finishing the game sometime soon... Once that is done, I will convert the game to 3D. The modular structure should allow me to do that without too much effort.
  15. Well, truthfully I DO have the freedom, but it would take so much work it just wouldnt be worth it.