Max Piano

Members
  • Content count

    28
  • Joined

  • Last visited

Community Reputation

136 Neutral

About Max Piano

  • Rank
    Member
  1. How long should I allow for creating the Game Engine? One day for tick tack toe or 10 man-years if, with the generic term "Game Engine", you mean, for example, a 3D game at the level of Quake2 written from scratch (not everyone has John Carmac in the team :lol: ). Obviously today the people expects something at the level of Far Cry or Quake4 (but I think that a good game does not need a great graphic but a great playability... probably is it more difficult? :lol:). More realistic: you may prefer to use a "ready-to-use" 3D Engine (Ogre, Irrlicht, TV3D, ...) or try to write a MOD for an existing game. If the MOD has success you could buy the license (or win it :D... see Red Orchestra mod for UT2004).
  2. Never Delete Old Code

    SteveH your problem is quite simple to resolve. You need two things: the first is a texture class. In this class you store the informations about the texure: the bit-map, the format (RGB, RGBA, ALPHA,...), the OpenGL ID, ... These infos are unique for each texture object. Then, in the same class, you need a static pointer to the texture in use. When you need to use the texture you check this pointer: if it is in use (that is: the static pointer is equal to the address of the texture object) you do nothing, otherwise you "GL reload" the texture (typically with a simple glBindTexture... I'm sure you know it ). In my texture class, for example, I use something like this: Everytime the texture changes (or it is just created) I call this function (I dont post all the details but it is important to deallocate from OpenGL the texture object in the destructor, init the static pointer to NULL, ...) void Texture::Bind(TEXTURE_TYPE type, bool mipmaps){ Delete(); // unload from GL glGenTextures(1, &m_glTObjectID); // m_glTObjectID is the OpenGL ID glBindTexture(GL_TEXTURE_2D, m_glTObjectID); TexImage(type,mipmaps); m_CurTexPtr = this; // this is in use (this is the static pointer) } // deallocate from OpenGL void Texture::Delete(void){ if( m_glTObjectID ){ glDeleteTextures(1, &m_glTObjectID); m_glTObjectID = 0; } if( IsCurrent( ) ) m_CurTexPtr = NULL; // this is in use? now it is no more } When I need the texture again, I simply call this one void Texture::MakeCurrent(bool bforce){ // default: bforce = false if( !IsCurrent() || bforce){ glBindTexture(GL_TEXTURE_2D, m_glTObjectID); // note: if ID==0 -> NOP if( !m_glTObjectID ) TexImage(); // reload without bind m_CurTexPtr = this; // now this is in use } } The second thing you need is a resource manager. A simple resource manager, if you know something about STL, is a std::map. In the map you could store your texture objects; as keys you can use the texture name itself or something more complex (for example the texture name and the filename,...) 1. If you find the texture in the map (by its name) you can "GLbind/GLrebind" it 2. otherwise you create a new texture object, load the bit-map from file, GLinit and insert it in the map and repeat the point (1) :D So you need only a static pointer and a map
  3. Rotate and Resize RGB bitmap

    Emmanuel Deloget: Quote:Now, if you want some ready-to-use implementation, the better is probably to check for an open-source image manipulation library. SourceForge provide some of them (Freeimage, ImageMagick and so on. Feel free to browse sf.net Agree with Emmanuel my favourite is FreeImage (ImageMagick *IS* the most powerfull but I found it too much for my needs)... Devil is also a good alternative but with a previous version I had problem to implement an abstract stream (but it is the simplest to use and very well documented). All these libraries are great and *fast* and allow you to do resamples and rotations without reinvent the wheel and most important let you to forget about the crappy Windows Bitmap :D In particular FreeImage supports free rotation, flip, resample with different filters: box, bicubic, bilinear, 4th order b-spline, Catmull-Rom spline, Lanczos3, ...
  4. Quote:I think the problem here may just be lack of familiarity with the algorithm. :lol: Thanks for the code.
  5. The first thing to do is to use the right data structure. If you have to clear and sort the list every frame you may prefer to use a std::set<your_object> and keep it sorted when you collect the entries (another advantage is that the set automagically removes the duplicates... for example in the case you have inserted your objects in multiple hash cells and collect the same object more than one time) I dont know what kind of sorting criteria you need (probably a z-indexing?) but you can easily implement it via a custom comparator. std::set<your_object, compare>
  6. Rotate and Resize RGB bitmap

    Quote: hi all can anyone post a function on how to rotate and resize 24-bit RGB bitmap data without using any API just plain unsigned char manipulation? In general, if M is your 2D (3x3) transformation matrix then for every pixel P2(x,y) in the target image you will copy the pixel that, in the source image, has coordinates given by P1(x,y) = M-1 P2(x,y) where M-1 is the inverse of M For example if you simply double the width and the height of your image the formula is very simple For every pixel P2(x,y) in the destination you will copy the source pixel P1(x/2, y/2) It's clear that the result P1(x,y) has, in general, non integer coordinates. You can clip them to the nearest point or pick the pixel by interpolating the coordinates (see Bilinear Interpolation or bicubic interpolation). Example of bilinear interpolation Pixel = (1 - b) * (1 - a) * P1(u,v) + (1 - b) * a * P1(u+1,v) + b * (1 - a) * P1(u,v+1) + a * b * P1(u+1,v+1) where a and b are the fractional part of your coordinates and u,v are the integer ones for example if you have (10.5, 37.25) then u=10, v=37, a=0.5 and b=0.25 The nearest point "interpolation" is ugly if you resize but totally crappy if you rotate the images... so it's better to use at least a bilinear interpolation. As you probably know these filters can be implemented via a convolution filter so you can generalize also the filtering process. Years ago, "inspired" by Java 2D, I have implemented a similar approach to image manipulation but the main problem is not get it to work (the formulas are well known and not so difficult to implement) but make the algorithms fast (in fact mines are slooowww :D).
  7. problem with classes (C++).

    It is called forward declaration :D
  8. Quote:So I guess its not generally done in C++ then, damn looks like I may have to learn another language, and just when I was getting the hang of C++ It is possible if you embed a scripting language in your C++ application. Generate code at runtime, load it in a string and pass it to your interpreter. So simple. One of the simplest scripting language to embed in application witten in C++ code is AngelScript. To be precise: you can also use C++ to generate C++ code but this new code cannot be executed before you have compiled it. This can be done automagically if you know where is the compiler but it does not seem a practical and/or efficient solution. :D
  9. jyk: Quote:The point is not that it's difficult to code, but that it's more difficult to code than the SAT. Probably you are right because you seem to know this stuff but I've not yet read an article or a tutorial about a simple implementation of the SAT *determination* algorithm. In fact we know that For objects in 3-space, the Separating Axis Theorem states that two convex shapes can be separated by a plane if and only if they are not intersecting. (wikipedia) but the problem is to *find* this plane: the theorem itself is not usefull for us because it does not say if this plane exists or in which conditions it does exist...in particular the theorem does not suggest a method to build the plane... to be precise: it states that the plane exists only if... the objects are not intersecting: but this is itself our one milion dollars question!!! In practice the theorem answers with a new - and harder! - question! :lol: Moreover searching for a separating plane (the theorem ensures that if the object are not intersecting, this plane exists) could be not necessary; and less necessary is to compute - for a simple yes/no boolean test - the distance between the volumes. However we can try to use simple planes for our test: for example the faces of the volumes so "my" method simply uses 12 planes (faces): if every (8) corners of one box lie behind the same plane we have found the separating axis (SA). The simplest method to test if one box is behind a plane is to test the sign of the distance of its vertices from the plane (it's only one "dot" product per corner). And as a subproduct we can determine also if the volumes contain each other. Quote:It may not be slow, but it's almost certainly slow-er than the SAT. I hope I will agree with you but I have to find a simple, general and - most important - "ready to use" SAT searching algorithm. Quote:Given that it's also more complex and probably less stable If a face is a separating plane I dont think it is not stable or more complex from a computational time point of view (and the code is very very simple). In the (worst) case we have to split the polygons, it is well known that the clipping algorithm *can* be not stable but we can refine the metod with improved versions (see distance tolerance): I can show the one I use if you want... I did not experience this instability and in fact BSPs are widely used in game engines, raytracing applications, ... Quote:what advantage does it have exactly? The main advantage is that if someone has implemented a view frustum clipping algorithm, probably he has not to code anything new but he can reuse the code (because a box, as every convex polyhedra, is itself a frustum). And one can reuse the same code to implement polygon-polygon intersections (with a convex hull we can also improve the stability... in practice we transform the polygons in frusta with "infinitesimal" heights). Another advantage is that I proposed a simple method to implement the boolean (yes/no) test: several authors wrote hundreds of pages about this misterious and legendary Holy Plane but sometimes they forgot to show (or implement!!!) an algorithm. :lol: Quote:I would say that your algorithm is almost certainly slower on average But on average, a plane is sufficient to clip out the second box: I suppose that in a typical scene the collisions (or near collisions) are rare. The clipping algorithm itself, in case there is no collision, does... nothing. On the contrary, in the case there is collision, it ends its job when it finds the first clipped face inside the frustum (typically this is the first or the second face). In other words: the clipping resolves pathological (and rare) cases, not the average ones. Furthermore the collision event is itself an "expensive" scenario because, in general, we have to resolve a lot of problems (collision response, impulses, scene backtracking, ...) Quote:and much more complex to code than the SAT. The only thing I left out from the pseudo-code is the clipping algorithm: but this can be easily grabbed from any BSP tutorial and it is well known and not difficult to code (but it is a must in any serious graphic library ). I dont know if this is the best method, probably not (in particular in 2D the SAT is more simple to implement) but I'm quite sure that it's better than... nothing. :D
  10. You can use blowfish that is a light, fast, decent and "ready to use" algorithm (the source exists in different language and flavour). Simply read your object, decrypt and pass it to the rest of your pipeline. The right choice of the private password is up to you... you could use the name of the texure for example. If you want to implement a ".pack system" you need to add a header in your pack file in which you store the position (offset) and length of every texture or wav file. If you are smart you could also add a compression streaming algorithm (for example with zlib). Again: read your encrypted texture into memory, decrypt, decompress and pass it to your pipeline. However, as everyone said, it is possible to grab your textures using those "hooking" programs: in fact if you can reproduce something, you can copy it.
  11. The method I proposed (that I self-discovered years ago) in practice is not difficult to code. In particular a decent set of math classes (vectors, planes, matrices,... ) is usefull because you can prototype this kind of stuff faster . Moreover I dont think that, in practice, this method is too slow because in the first part we simply search for a separating plane in the set of 6*2 faces. In the average case one plane should clip out every corner of the second box. PS: sorry for the multiple posts (weird password manager! :D)... I removed them!
  12. Quote:I was thinking of doing this, so that all my OOBB can be stored as a AABB plus a transformation matrix. Since I was thinking that most collision/test would be faster using a AABB than a OOBB. But your transformation matrices will be different! :D Why not use your OOBB directly? Think them as a kind of particular frustum in which every plane has a normal that points in direction of the center of the volume. If every corners of the second box lies "outside" one of the six planes of the first OOBB you are sure that there is no intersection. In the case this fast test fails you can repeat it by testing the first against the second. These tests are also usefull because (as a "test subproduct") you can discard the particular situation in which one box is entirely contained in the other (in this case you have intersection): if every corner of one box is in front of every plane of the second, this box is contained. Note that in most cases there is at least a plane of one box that "clips out" every corner of the second (no intersection). But if these tests both fail ( it's rare because it's *probable* that you have an intersection) you can perform a more expensive (and general) test: clip each face of one box against the frustum described by the second. If "something" remains you have an intersection otherwise not. You have not to repeat this test a second time because you know that the two boxes dont contain each other. Probably you are now confused :D OK: this is the pseudo-pseudo code... result test(box1, box2) { result res res = fast_test( box1, box2 ) if(res == NO_INTERSECTION) return NO_INTERSECTION else if(res == CONTAINED) return BOX2_CONTAINS_BOX1 res = fast_test( box2, box1 ) if(res == NO_INTERSECTION) return NO_INTERSECTION else if(res == CONTAINED) return BOX1_CONTAINS_BOX2 for each face F of box1 { for each plane P of box2 { if (F is not empty) F = clip(F, P) } if (F is not empty) return INTERSECTION; // something is in the frustum } return NO_INTERSECTION; // we know that no box is contained } where result fast_test (box1, box2) { bool contained = true; // init flag for each plane P of box1 { bool extern = true; // init flag for each corner C of box2 { if (C is in front of P) extern = false else contained = false; // at least a corner is outside } // if every corner lies outside the same plane... if (extern) return NO_INTERSECTION } // *every* corners is inside *every* plane if (contained) return CONTAINED // we can tell nothing return DONT_KNOW; } polygon clip(polygon F, plane P){ return the part of F in front of P // see some tutorial about BSP } For example here
  13. Create a scripting language is not a simple task. You may prefer to use an existing scripting language and embed it in your C++ code. In this case there are a lot of alternatives: python, LUA, angelscript, ... there are also C scripting libraries (to run interpreted C code ). You can use these script languages as a base and extending them with your own functions (written in C++ and compiled): in general you can pass objects from C++ code to the interpreter and viceversa. Start learning a simple script language (for example angelscript) and embedding it in your application can give you some ideas in the case you decide to create your own.
  14. Multiple keys SDL

    Try something like this while(1) { // "main loop" for( SDL_Event event; SDL_PollEvent( &event ); ) { // event dispatch loop if( event.type==SDL_QUIT ) exit(1); else if( event.type==SDL_KEYDOWN ) keypressed( event.key.keysym.sym, true ); // pressed else if( event.type==SDL_KEYUP ) keypressed( event.key.keysym.sym, false ); // released } } void keypressed( int vkey, bool b ){ if( vkey==SDLK_UP ) key_up = b; else if( vkey==SDLK_LEFT ) key_left = b; else if( vkey==SDLK_RIGHT ) key_right = b; else if( vkey==SDLK_SPACE ) key_space = b; }
  15. 2D OpenGL SDL Engine Help

    Have you linked (inserted in the project) the cpp files?