Jump to content
  • Advertisement

kaysik

Member
  • Content Count

    401
  • Joined

  • Last visited

Community Reputation

382 Neutral

About kaysik

  • Rank
    Member
  1. kaysik

    gluOrtho2D() and textures

    I think you'll find that your polygon is upside down and hence backwards, so its getting back face culled. It turns out that with OpenGL and Ortho2D() the bottom left corner of the screen is (0,0), with y going up the screen, and x to the right. As such if you've planed your polygon with top-left as the origin your winding order is probably backwards and hence pointing away from the screen at a guess.
  2. The way we've done it is by useing imposters. The idea is that you really only draw the front couple of objects, and for anything further away all you draw are particles, textured to look like the object. So you render your oject to a texture, then for anything too far away, or after say the firstly 100 objects then you just render quads with the texture. It'll break any fancy shadow algorithms or special shaders, but if they're far away then they probably don't need that stuff to begin with. If you have animating objects then you can have a couple of different frames rendered out, then pick the closest one. As long as you update the objects closer to the camera properly, you can get away with only updating the objects far away pretty rarly! Like once or twice a second. If you have 20k objects update say 1k per frame. The closest 500 objects every frame, then the next 500 objects out of the queue based on how close they are and how long since last update. Everyone gets updated sometime, but the further away they are the less it happens. Edit: Its important to note that if you impliment this, the objects that don't update often will stand out to *YOU* really badly. Ask someone else to look at it and they won't notice a thing ... we wasted alot of time worrying about the back objects only updating once/twice a second when nobody but us ever even looked at them!
  3. kaysik

    Shaders slower than FFP

    Firstly - that drop is nothing! Think about what FPS means - its not a linear scale. Useing FPS is actually a pretty bad way to measure performance. Try useing miliseconds per render or something as a better alternative. Think of this: FPS = 1700, means 0.6ms render time FPX = 350, means 2.8ms render time So with a fps drop of 1350fps you add 2.2ms to your render time. Now consider this: FPS = 60, means 16.6ms render time FPS = 50, means 20.0ms render time So with a fps drop of 10, you now add 3.6ms to your render time. See why FPS is a bad measure of performance? A 10 fps drop from 60 to 50 means double the difference in render times between 1700 and 350. Honestly any change when your fps is higher than 120 means practically nothing!
  4. kaysik

    .bmp Backgrouds

    OpenGL doesn't work like that. Its not a window - its a graphics API. What you need todo is setup an OpenGL texture like normal, then draw a quad that fills your window with the texture on it. There are heaps of tutorials on how to draw textured quad's so google is your friend :P Also look into gluOrtho2D(), because that'll let you draw an image in 2D very easily, without having to try to draw a 3D quad then line it up with your camera (which is a pain).
  5. kaysik

    Project Ideas

    If you know c++ at all then Try This!. Even if you don't know C++ that gives a pretty good explantion of the technique and theory behind it so you can impliment it yourself in some other language. Other than that - google is your best option.
  6. kaysik

    OOP class problems

    Help us out by telling us whats wrong :P You have failed ... but at what? You get compiler errors? You don't know how to create the classes themselves? Your #include errors? So on and so forth. Ask a specific question and I'm sure someone can help. Just say you failed and there are so many possible answers its hard to know what you actually want.
  7. kaysik

    Project Management noob

    Two things: 1) Are these questions of the "Lets make a FPS? ... No i want an RTS?" style? Or more a "Health packs should give you 100health! Nah thats too much, try 90hp!" type? The first type need to be solved now, the 2nd type need to be solved later! So if you know your making a FPS, and you know generally what the final game will play like then by all means start coding. If you still in the "FPS vs RTS" stage, then solve that now :P 2) Even if you do actually start making things now at some point you will need to end up agree'ing on the aspects of the game. When that happens the best way todo it is to get a list of questions, and then ask your team to get them answered by the end of the meeting, day, week! If your face to face its easier as you can just go down the list and write your answers on the spot. If you think up any new questions along the way just add them to the list. This is the best way I've ever found for directing discussion and finalising things - even if you yourself don't activly participate in the discussion. Ask the questions and get a definite answer. The answer might change in 2 weeks, but thats fine at least you've got something to aim at, even if your target moves every so often!
  8. kaysik

    Music In Mobile Games?

    5 years ago, mobile games were snake. The best sound you ever got was tone beeps. These days you can get full 3D games on mobile complete with sound effects and music all properly mixed etc. Checkout some of the high end games on Brew/Symbian and you'll find their simplified ports of most hit games. Things like Need For speed: Most wanted, Splinter Cell and Madden are good examples of hit games that have mobile ports. High end phones now pump out graphis in the Quake, Quake 2 area of quality ... some of them even have proper 3D chips inside with many more planned for the future. So the trend is to psp/ds style of games and beyond. And that definatly includes sound/music.
  9. kaysik

    iPhone : closed ?

    Quote:Original post by serg3d Rumors have it that iPhone will not be open to third party developers. What a pity. Looks like a perfect gaming platform. Hope I wrong. Anyone have any information about it ? Considering how closed the IPod video development is I'm going to say it'll definatly be closed. I know people working on an I-Pod game and they don't even get a dev kit or libs really. They have to send their source to apple, who builds it, tests it, then tells you what happened. So for ipod even an official developer never see's the device ... its crazy :P If apple is like that with the i-pod no reason they won't be like it with their iphone.
  10. kaysik

    Float vs Double performance

    Quote:Original post by Wavesonics Is this true and if so something to really worry about? For instance, should all the 3D math for a 3D engine be converted from float to double and would there be a boost in speed? On your standard PC floats are 4 bytes (32bits), and doubles are 8byte (64bits). So unless your running a new 64bit machine it means that a float fits nicely its 1 CPU register of 32bits. This makes it faster to work with than a double, which uses 2 registers so needs a bit of trickery to get working. How much faster/slower I don't know, but unless you NEED the extra precision of double its probably worth keeping your stuff as floats. Then again the biggest every speedups will always come from changing your algorithms rather than this kind of thing. So if your struggling for speed its probably worth your while looking at the collision detection and rendering algorithms rather than this ... but if you know those are the fastest you'll ever get then float on a 32bit machine is faster than double (in theory, i've never tested it).
  11. kaysik

    Is OpenGL the way to go?

    Many people (and myself most of all) find OpenGL easier than DirectX. So if your struggling with OpenGL then turning to DirectX probably won't help you out much. It might, so feel free to look, but the general feeling is that OpenGL is sleightly easier. And as for good games made with OpenGL ... try Doom3? Quake 3? The Unreal Tournament 2k4 used OpenGL and SDL for its linux port too I believe. There are quite a few out there. Its true most A+++ games are DirectX, but there are definatly quality OpenGL games out there. Trust me its not OpenGL that makes a crap game - its the people making the game that make it crap :P As for the fact its hard. Hell yeah its hard :D If anyone could do it then it wouldn't be that fun. I did computer science at uni for 3 years, and now I've been programming profeshinally for another 3 years and I still have to learn new stuff all the time - its why its FUN. Most of the joy of programming comes from getting hard stuff to work. So while it IS tricky, and it'll bend your mind for ages, when you get it, then you'll feel awsome. Being 12 is a only little drawback because you just haven't done all the highschool maths yet like trig and vectors which is really helpfull for 3D apps. You can learn it no worries, but just be aware that you might need to learn a few extra things that most people are assumed to have. Just remember 3D is pretty mind bending the first time out, so if you haven't already make a complete 2D game first. That will teach you heaps without your brain exploding ... as much :P
  12. Try to USE your code for something. If you can't, or if its hard then its badly designed :P There's no way to actually tell. Its like asking "is this picture nice?", the only way to know is to look at it and see if you like it. The best you'll get is to ask some questions like the ones below, if you say yes to most of them then its good! Is it easy to use? Is it easy to re-use on another project? Is it easy to customize for future use? Is it split into nice manageable chunks? Is it clearly written, with at least some comments and proper var names? etc
  13. The way I do it is this: Input gets parsed by my input function and transformed from real keys (w,s,a,d etc) into game-codes (PLAYER_MOVE_FORWARD, PLAYER_MOVE_BACK .... etc). These are bit flags which get OR'ed together, but you could easily use an array of bools if thats more your style. The input function then sets these in the player entities controles variable. Then the generic entity class uses them on its next update. The beauty of this is two fold: 1) I can map any keys to be PLAYER_MOVE_FORWARD and no game code will need to be re-written. Only thing that changes is which keys my input function looks for to set those game codes. Makes it easy to let the user customize their keys. 2) I've written my AI off that. My AI is based on looking at an entities position and direction, then it sets those keys for each entity, and my entity class uses those to move around exactly the same as a player. This way I only have 1 entity class, which just has a set of attributes and a really simple update like: if ((controls & PLAYER_MOVE_FORWARD) != 0) ... vPos += vForward * entSpeed * nDT; Then i have an AIControler which just pretends to be a player. The keyboard sets the controls for the player entitity, and my AIControlers set the controls for all the other ones. Have a few different AI controler's for each enemy type and bham - your done.
  14. kaysik

    Getter/setters and constants

    Quote:Original post by Crazyfool And if so, shouldn't this work int xarray[getX()]; No it shouldn't work. When declaring something like "int array[size];", the size must be determined at compile time. Useing a const int works because its known at compile time what the value of that int will be. However returning a const value from a function just means you can't change that value. It does NOT mean its known at compile time. You can do something like this: const int myFunc() { return timeGameHasBeenRunning; } Each time you call that function it'll return something different. So there is no way at compile time to know what the value will be, hence you can use this to create an array on the stack. The compiler needs to know how much stack space a function will take when it compiles, so an array declared on the stack must have a constant size that is known at compile time. Edit: Beaten.
  15. Quote:Original post by IKG Why didn't anyone ever mention GLUT? I didn't know much about it until now. Is it harder to use than SDL? I looked through the documentation real quick and it looks pretty simple. Also as a side question: Couldn't I theoretically use OpenGL to do the rendering (draw textures) for a ray casting engine? I know that would kind of ruin the purpose since OGL can be used for 3D and ray casting is for using hardware only, but would it work? If yes, would it be faster? Nobody mentioned glut because its a dead library. I think the last time glut was updated was in 1998, and thats ALONG time ago - its old, and it really shows its age. It is pretty good for learning (I learnt OpenGL useing it) but practically everyone who uses glut moves onto SDL in the end. Glut has some very handy functions but in the end SDL is more flexible and in my oppinion better organised. Glut is still good, but most people (myself included) would agree SDL is way better. And yes you can use openGL to render your raytraced image. But the raytracing to get your image will be very slow. OpenGL might actually blit the image to the screen faster that pure SDL or Win32 call, but if it takes you 10 seconds to raytrace your image, the few microseconds you'll gain from useing OpenGL to render the output won't make that much difference. Besides - if your doing this for technical reasons because you like a challenge then make a demo. Something that'll draw cool colours in pretty patterns to the screen. If your going to be making a game, trust me that setting up a window is the least of your problems. Useing Allegro, SDL or Win32 won't make the sleightest bit of difference after the first two weeks because the hard bit is actually organising your game logic, collision detection, physics and all that. The bit your worried about is the bit you'll only ever write once then cut+paste into every other project. Much better use of your time is to worry about your game being fun!
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!