• Advertisement

CatmanFS

Member
  • Content count

    34
  • Joined

  • Last visited

Community Reputation

199 Neutral

About CatmanFS

  • Rank
    Member
  1. I know this is a simple question, but one I've always been looking for a solution for.   class MAP {       Scene scene;       void AddedToScene(Scene); };     void SCENE::addedToScene(Scene newScene)     {         scene = newScene;     }    I know it's minor, but I don't like always having to put a scene = newscene statement in the function definition.   Is there any way to make the class function automatically accept a function parameter of the same name as a class variable.   void addedToScene(Scene scene)     {          // scene is automatically accepted as the class variable with the same name     }
  2. Fonts! Suddenly, hundreds of them!
  3. OpenGL Pixel buffer

    So just keep all he graphics operations on the gpu, got it. Is there a good, cross-platform, well documented method that most people use? Are there tutorials or examples of this somewhere?
  4. OpenGL Pixel buffer

    Also, if anyone has any pointers about what operations can be performed the fastest, and any additional information about per-pixel operations would be nice. I'm really just concerned about direct control over gamma, brightness, contrast, that sort of thing. Would also be nice to hear about any useful ideas for maybe having a histogram or something that could help correct over or underexposure for post processed images. I'm sure there's a whole list of websites or pages somewhere that has info on this, but I would like to hear some recomendations, maybe a specific site that focuses on post processing operations.
  5. I'm working with openGL, and I want to know which is the best method of directly accessing information in the frambuffer. I want to be able to read the pixels being displayed onscreen and place them into an array, perform operations, and put them back into the current frame. What is the best method, meaning fastest or most flexible or is there a tradeoff? If you could give me a few ideas or point me in the right direction I would be much appreciative.
  6. password mayhem!
  7. Airlight Engine

    This is a collection of renders and editor screenshots of the Airlight Engine. Being developed for a number of indie projects, this engine plans to be flexible enough to handle multiple 3d game types. These are all in-game screenshots, works in progress, showing various levels of artistry related to game development and the Airlight Engine.
  8. OpenGL Strange lighting issues

    I had started typing that before you had replied. Thanks again for the help. The reinterpret cast thing is new to me. I've been doing all of that manually, and it's been a real pain. Most of the C++  books I have are >10 years old, and they don't go into alot of detail about stuff like that. Mostly strings and array pointers. I'll do a little research into the methods of overloading operators and such. Thanks again for the help.   Got another question. i've got 3 lights, with ambient and diffuse values set around .8 -> .9 and the scene is very dark looking. There's light, but it's not really like the lighting I'm used to. I tried to bump the ambient values up to 10 and it didn't seem to have an effect. Any ideas?
  9. OpenGL Strange lighting issues

    Ahah you saved my life. I'm still a little confused about the matrix multiplying the light positions.   Right now, the UpdateAllLights() happens after the modelview matrix has been established.   Where would you reccomend that this be placed?
  10. OpenGL Strange lighting issues

    I changed the update light code to this:       float amb[] = {5, 5, 5};     glLightfv(light->ID, GL_POSITION, amb );   and excluded this:     //glLightfv(light->ID, GL_POSITION, light->position.pFloat());   and it works. The problem is that I need to pull the info from the *light that the update function uses as input   is there something wrong with using:   UpdateLight( LIGHT *light)   and the pulling the info using:   light->position.pFloat();   // pFloat() returns a pointer to an array of { x, y, z} stored in the vector3   Could be that since it uses a pointer to the light struct, and then a pointer to the vector3 struct that somehow the actual data struct gets lost. I'm still confused as to why the light only works near the origin with this implementation.   Any thoughts?
  11. OpenGL Strange lighting issues

    To help I uploaded a video of this effect.   https://www.youtube.com/watch?v=jqrEJnLIu1M&feature=youtu.be
  12. I was working with a default picker for creating light objects. You would type something like:   LIGHT light0(AMBIENT);   and it would create an ambient light based off of preset values, and handle the rest of the code elsewhere.   The problem is when I was changing up the input variables for the lightfv( GL_AMBIENCE, float* ambience) I ran into a problem.   The scene lighting would only work if the viewing position was somewhere near the origin. It didn't make sence. I messed with attenuation, trying to lower it, raise, it, remove it completely, and it didnt seem to have an effect on this issue.   Light just stops working once the camera moves more than just a few units from the origin.   Now if you know of this to be some sort of aspect of OpenGL and I'm just missing a line of code somewhere, let me know. if we're not so lucky keep reading for a few samples of the code and a the details of when this started happening.     Now the code for the light is something liek this   class LIGHT {   vector3 pos; color ambience; color diffuse; color specular   float shine; float attenuation;   LIGHT(LIGHT_PRESET); void Enable() void Update()   };   I'm using a color code like this:   struct color {       float r, g, b, a;       void Set(float, float, float);       float* pFloat(); // this returns an array of 4 numbers like the ones the light needs as input };   float* color::pFloat() {        float floater[] = {r, g, b, a};       return floater; };   the vector code for light positioning works similarly   struct vector3 {      float x, y, z;      void Set(float, float, float);      float* pFloat(); };   float* color:pFloat() {        float floater[] = {x, y, z};        return floater; };     And the light takes those values as such      glLightfv(ID, GL_POSITION, position.pFloat());    glLightfv(ID, GL_DIFFUSE, diffuse.pFloat());       glLightfv(ID, GL_AMBIENT, ambient.pFloat());    The picker works, there was no problem there, but when I tried to change from setting the color values from this:   color[0] = .5; color[1] = .2; color[2] = .7;   position[0] = 10; position[1] = 15; position[0] = 10;   to something better like this   color.Set(.5, .2, .7); position.Set(10, 15, 10);   The structs for color and position have functions to easily set themselves, and also produce the float* number array that openGl likes to use for it's light and position color values.   I got this working, and I've used this concept many times, but I ran into this other lighting problem that I just don't understand.   At first it seemed like it wasn't getting the correct positional values and just placing the lights at some far distance place, then i noticed that it was placing them directly at the center, inside the test object I'm using to work with the lighting.   I output the values that would be directly sent into the openGl position input, and found them to be fine.   Does anyone have any idea why this is happening?  
  13. Something I've noticed

    You can find out which calls are obsolete and ignore them while seperating the renderer from the majority of the core game functions. The renderer and the hardware will always have to be updated, that's just the nature of the search for photorealism in 3d graphics. I would like to see more games re-made with updated graphics re-implemented on newer systems, like they did with halo. I know it's a complicated and expensive process, but if you really love to do this kind of stuff then it shouldn't be that big of a deal. Alot of people don't enjoy working with the resources and overcomming the obstacles because they're either too difficult or too complex. We shouldn't be spending all kinds of time worrying about rendering package backends, and all the intricacies of modern computer graphics. There are people that do nothing but that kind of stuff, and they've been doing it for years and know all the ins and outs. I don't claim to be a computer graphics genius, I just want to know the basics and be able to take an idea and turn it into a reality without too much of a struggle understanding obfiscated code developed by mad scientists spinning on gerbil wheels. Hey, that even gives me an idea for a game.
  • Advertisement