Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

244 Neutral

About Daishim

  • Rank
    Advanced Member
  1. I'm working on implementing a file system object to handle file requests. There are three types of files that I might request: text files, data files, image files. Text files are simply text files and only store text that does not contain data, data files are key based lookup files (key value pair files or xml), and image files are read and converted to raw format (for now). I'm trying to create an object hierarchy for these files while providing interfaces to the users of the file system object. When working only with data files, my hierarchy was as follows: Key_Value_File->Data_File->File_Base->File File was the interface object returned by the file system, it contained the pure virtual functions for token reading, writing, creating, and deleting tokens plus some basic functions for getting filename and size and such. File_Base was the intermediary object that contains the filename and such and is what the file system object tracked and managed. Data file was an interface to all data files, providing pure virtual functions that were required to be implemented by all data files. Key_Value_File was the object that actually handled data retrieval from disk, putting it into a map, and implementing the token functions. Now that I'm trying to implement the other types of files, I'm running into an organizational issue. I can implement the text files and image files similar to how I have done the key value files, as follows: Image_File->File_Base->File Text_File->File_Base->File However, this means that the interface, File, would need to expose functions for reading text, reading data files, and reading image files. This is not really needed and introduces problems with the user trying to use the functions that don't belong to the top level object. Another idea I had was to implement separate interfaces off each type of file object, like so: Data_File ^ | Key_Value_File->File_Base->File Where Data_File and File are interfaces. However, if you just give the user the File interface object, they don't have access to the needed data retrieval methods. If you give the user the Data_File object they don't have access to methods provided in the File interface. I can also have Data_File be derived from File, however, this creates the diamond problem, which can be solved with virtual inheritance. Though, this makes proper order of destruction a little tricky. Another option is to eliminate File_Base, and replace it with the different file type's base object and just implement everything 3 fold and track all of them separately. Is there a better way than these three solutions? Each one has it's annoying drawbacks.
  2. Daishim

    Reducing load times

    You won't find a whole lot on this topic, because most of it is beyond your control at the OS and hardware levels. As long as your data files are in a sane format and can be easily/sequentially read, there isn't much you can do. You want your data in as close to the engine's run-time format, if not exactly, as possible while maintaining easy edit ability. Having to do a lot of text parsing and conversion of data on the CPU can add up to a good bit of time as well. Compression can speed things up, but depending on the type of compression and how you time/synch everything up, it could be slower. Using container files can help with speed as well, since they are seen by the OS as a single file, which is then cached sequentially as you're reading it. If you place your files in the container sequentially and the file is not too fragmented on the disk, your pull from disk time can drop a little. Something to also consider, as you mentioned a threaded approach, is to asynchronously load your data. In places where you can, load your data bit by bit in the background before it is needed. You won't get anything amazing as far as speed, but the effect of remaining interactive while loading what you need is better than a slightly reduced load time where everything stops. You should be able to find a bit on this topic, as it's becoming quite popular, especially in console games.
  3. The allocated memory actually does exist beyond the doStuff function, however, a little pointer explanation is in order. What you are passing to doStuff is a memory address, which it copies to your pointer that becomes the argument. The argument variable is then assigned new memory, and then points to a new memory location, while your original variable is untouched. To correct this, you want to pass a pointer reference, like so: void doStuff(float *&Kalle) { Kalle = new float[100]; } int main(void) { float *My_Stuff = NULL; doStuff(My_Stuff); ... }
  4. Daishim

    Alpha component

    Yes, I'm requesting an RGBA window, and ALPHA_TEST is disabled.
  5. I'm performing a render operation, using GLSL, that stores unique values into an RGBA texture to be downloaded from the graphics memory and used in system memory. To store the values into a texture I'm using a framebuffer object, with attached RGBA color buffers. The problem I'm having is that, no matter what, the stored alpha component is max (1.0 -- all alpha component bits are 1). I try rendering to the main framebuffer, with the same result. I can use an empty GLSL program except for "gl_FragColor = vec4(0.0, 0.0, 0.0, 0.0)" and the alpha component is still max. The rgb components, however, do retain the correct values in the actual, and test, shader program. I'm not trying to do any blending, just store unique values in each of the four components for use later. From what I understand, it should be possible to store a value into the alpha component of gl_FragColor, without blending. I have asked this question before, but have done a lot more digging, revising, and tinkering, but have had no luck. Hopefully someone can see the error my ways or has an idea what I'm doing wrong. So, in short, is there a reason I would not be able to store a specified value into the alpha component of an output fragment?
  6. Daishim

    GLSL and alpha problems

    Yes. I'm trying to retain the actual alpha value, and not blend.
  7. Daishim

    GLSL and alpha problems

    No blending is enabled.
  8. I'm having trouble with the alpha channel. I'm using GLSL and framebuffer objects for rendering to texture with alpha components. Whenever I read back the data, the highest order 8-bits (alpha component) are all 1s, however the other components are correct.. This occurs when rendering to a framebuffer object as well as the main framebuffer. Using any GLSL fragement program, even as simple as just an empty function with "gl_FragColor = vec4(0.0, 0.0, 0.0, 0.0);" will yield all 0s except for the alpha component's bits which are all 1s. The textures (color buffers) for the framebuffer object are RGBA, as well as the main framebuffer being RGBA. Anyone have any idea what I may have done, or not done, to cause this?
  9. Daishim

    Terrain woes

    I recommend looking into quadtrees. There are some articles here on GameDev that deal with it, and you'll find quite a few just with a google search.
  10. Quote:Original post by adam_o Quote:Original post by Ravuya Sounds like an off-by-one error. Remember that C++ arrays start at 0 and go to n-1. I don't think it's off-by-one, because that kicks up the debugger... I had that happen between Problem 2 and Problem 3, but I was able to get the help on that one... nice try... Not quite. Off-by-one errors are simply miscalculations of location by one, because you forgot to compensate for a starting point or such. First, this is not guaranteed to cause an error, if you overrun an array, so it may or may not crash/invoke debugging. This is not something you can rely on. Second, the off-by-one error may not even be causing you to overrun the array, which would not even generate a potential for an overrun, so a crash/debug wouldn't even happen. It is merely a logic off-by-one. If you're code is removing a line above the one you want to remove, you probably do, in fact, have an off-by-one error. Check you're code for calculating which row to remove. In a C++ array, the second item is index 1.
  11. Daishim

    Most Used 3D Modeling software?

    Another consideration, while not free, is Milkshape 3D. It is only $25, and supports a lot of formats right out of the box. I haven't used it too extensively, but the interface is a little more standard than Blender.
  12. Daishim

    DLL linking

    I was attempting to runtime DLL loading simply as an exercise and not a concrete design implementation quite yet. Linking the .lib doesn't seem to help linking dependencies on classes at all. It appears that I can now call directly to functions inside the DLL, however, I still cannot call methods that are members of non-abstract/interface objects. Should I be able to call methods of classes without an interface object if I use the DLL with the .lib linking instead of runtime linking?
  13. Daishim

    DLL linking

    I am using C++. I'm including, in the executable code, the headers defining the renderer objects, which are the textures, vertex buffers, lights, and the interface object for the renderer itself. The renderer object, which has an interface, generates instances of these objects for use outside of the renderer. I am not linking the .lib with the DLL, I'm performing the link at runtime, via LoadLibrary(). By interface, I mean an interface object, containing pure virtual methods to be overloaded the real object. As I've been toying with this, I've noticed that the only objects that I was using during the test compiles were objects that had a base interface object (textures and vertex arrays/buffers). Which is why I asked whether any class that is implemented within a DLL, needs to have an interface object, so that it can be used in code outside of the DLL.
  14. I've been diving into the land of DLLs and I'm coming up somewhat confused with a certain scenario. Say I have a renderer object (with interface) that is a factory for textures, vertex buffers, etc... and I compile it to a DLL. I include the headers for the renderer interface and the generated objects in the executable compile and link the DLL at runtime and I'm able to use the generated objects, and call their members from the executable code. So I follow this same idea with a loader object that generates some file objects, and compile that to a DLL. However, now when I attempt to compile the executable and use any of the file object's member methods, I get a linking error. A file object is generated by the loader object, which has an interface as well. I'm still trying to figure out the whole linking structure and do's/dont's of DLLs, so I guess my question is: Should this method even really work? Is the factory implementation of the renderer just a lucky "works, but shouldn't", and so thus the factory implementation of the loader in a DLL is failing? Does every object in the DLL that is referenced by the linking code need to have an interface? [Edited by - Daishim on May 29, 2007 12:27:52 AM]
  15. Daishim

    obj files and textures

    Yea, that's how its supposed to work. But I've gotten a few, mostly from GamasutraExchange, that don't come with a material file, nor reference the material file in the obj, but just include a texture file. I don't know what program is exporting them that way, or if they're just twiddling with it, but that's how they're coming. I just assumed that was his scenario.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!