Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

140 Neutral

About minamur

  • Rank
  1. minamur

    3D objects toward a flat 2D tiled scene.

    i know in maya you can load a picture that will display in the background, then you could load all you're models and do whatever until they look right, then you could render the scene and cut out the individual objects as sprites and plop them into you're game, or you could make them part of the tile set if you like. i'm not an animator or anything though, that's just how i'd go about it.
  2. minamur

    3D objects toward a flat 2D tiled scene.

    do these objects need to rotate during the game, or do you just want to rotate them around to get the right look for you scene? if its the latter then you just need to render your building and use the rendered image as a sprite.
  3. Quote:Original post by Darkstrike v-2*n*(n.v) is correct as long as n is normalized. If it isn't, v - 2*n*(n.v)/(n.n) is the way to go. v doesn't need to be normalized in either case. quoted for truth. sorry, i didn't think before posting.
  4. edit: -2.0f * n * (n*normalize(v)) + v where n is the surface normal and v is the direction vector you want to reflect since you aren't normalizeing v i think you're over estimateing the projection of v onto n which would fuck up your results.
  5. minamur

    #define and const

    Quote:Original post by jyk What advantage does the #define have over a constant? Why would you choose to use the former rather than the latter in this case? none, but i'd use it in this case simply because i'm more used to it, you could also say you're saveing eight bytes by #define-ing it, but thats just silly. i was just saying that if you encode the literal with type information using the proper suffix you can gain some degree of type safety, and that #define isn't the pure evil that you dare not speak its name. i think with most things, if someone says that something should never be used, thats probably an exageration. for example, i hate macros, mostly because i can't debug them, but i've written a whole slew of macros to make my life easier while programming on the gba. now of course i could have written functions for this sort of thing, but these macros where for set a bit at 0x4000010 and that sort of thing. really it made no difference to me weather it was "good programming practice" or not, since, like i said the worst part of macros is how impossible they are to debug, and the debugger never worked anyway :). so my point really is everything is a tool, if you know the limitations of the tool and what you need done, you can make a choice of how you go about doing things. you don't need to disregaurd something out of hand like that.
  6. minamur


    Quote:Original post by gparali Thanks for the answer. He has already thought of the solutions you have given. The plan he has right now is for every electron to be affected by the electrons that are very near and then treat the other electrons as groops as you have suggested. If you find that there faults with this or there are better methods please post. i'm working on something that sounds actually kind of similar right now. my solution is to have each particle (in your case electron) store they're position and they're position divided by some number. this way i only need to check if each particle is in the same grid cell (or a neighboring cell), which saves me from haveing to compute the distance or even the squared distance between the particles. the draw back is that it involves a divide for updateing the particles, but you may be able to factor that out some. here's my abridged implimentation. /////////////////////////////////////////////////////// //particles update /////////////////////////////////////////////////////// this->position += this->velocity * ellapsed_seconds; //grid_x and grid_y are both longs this->grid_x = (long)this->position.x >> 6; //using a right shift to avoid full divide this->grid_y = (long)this->position.y >> 6; //depending on what you're doing this may not be do-able . . . //////////////////////////////////////////////////////// //particle systems updat //////////////////////////////////////////////////////// for(all the particles i) { i->update(elapsed_seconds); . . . for(all the particles j != i) { if(j->grid_x >= i->grid_x-1 && j->grid_x <= i->grid_x+1 && j->grid_y >= i->grid_y-1 && j->grid_y <= i->grid_y+1 ) { //find actual distance //if distance is less then some threshold, they're interacting //do stuff } } }
  7. minamur

    #define and const

    speaking of pi whats wrong with: #define pi 3.14159265 i don't see how that is unsafe. float temp = 180/pi; this will give a truncation from double to float warning. if you want pi to be a float then just use the right suffix. so if you're defining a simple value and you just use the right suffix on the number you have type safety. #define isn't so evil, but large macros are imposible to debug and so should be avoided.
  8. minamur

    Cannot get average of three variables.

    Quote:Original post by Sarxous Thanks for the help guys. Steamers modified code worked perfectly, as did Danikar's "double cin.get()" in the sake of simplicity I went with Danikar's method. in general the way to clear the input stream is (although i haven't used cin in a while ;)): cin.clear(); //clears the fail flags while(cin.get() != '\n') {} //clears the input stream up to the newline
  9. Quote:Original post by Incogito I've checked, and it turns out I'm allowed to use any free engine, but for whatever reason they still wont let me change compiler.. I've got 8 weeks to finish this thing, apparently.. Thanks for your suggestions so far, though are you working alone?
  10. minamur

    OpenGL with SDL = crash

    Quote:Original post by BradDaBug All you're doing, as far as OpenGL is concerned, is clearing the same color and depth buffers every time insead of flipping to the next one. Why would that cause a problem? Am I missing something? since your clearing the back buffer but not flipping the buffers what should be rendering? chode thats what.
  11. minamur

    alternative power function

    a bit off topic but... it seems that for a faster power function for a floating point type you could make long* buffer pointing to the float, copy the value stored at that long* into a long, then copy the new exponent into the exponant field, then cast that back to a float and return it. never tried that, just a random thought. [edit] maybe it isn't a bit off topic since the above would preserve the sign of the number.
  12. minamur

    SDL window positioning

    Quote:Original post by basement Not in any SDL version so far. However I think in SDL 1.3 this will finally be fixed. Best thing you can do for now is using native functions for your platform, for example use this to center the window: #include <SDL_syswm.h> void CenterWindow(int w, int h) { int x,y; SDL_SysWMinfo info; SDL_VERSION(&info.version); if(SDL_GetWMInfo(&info) > 0) { # if defined(WIN32) x = GetSystemMetrics(SM_CXSCREEN) / 2 - w / 2; y = GetSystemMetrics(SM_CYSCREEN) / 2 - h / 2; MoveWindow(info.window, x, y, w, h, TRUE); #else /* other platforms */ #endif } } nice, i wasn't aware of SDL_GetWMInfo. thanks.
  13. minamur


    Quote:Original post by Uphoreum EDIT: Come to think of it, SDL_WM_ToggleFullScreen doesn't work either... in the sdl doc it says that SDL_WM_ToggleFullScreen is only implimented in xwin i believe. you could probably do it yourself though.
  14. when you create a window in sdl, is there any way to set the position at wich it will be created?
  15. minamur

    2d per pixel collision

    well thats good to know. thanks.
  • Advertisement

Important Information

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

GameDev.net 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!