Always remember that a reproducable test case is worth a lot more than a bug report alone, but any report is better than nothing.
To the same place you extracted zenilib. Please see the Start Guide for details.
Please make sure that you have correctly set up the SDKs as described in the Development Environment installation guide. Then, be sure to extract the supporting files as described in the Start Guide.
It is possible that you need to add paths for the Windows SDK. If you installed the Windows SDK 6.1, you may also need Include/Lib paths from 'C:\Program Files\Microsoft SDKs\Windows\v6.1'.
Ensure that you have '#include'ed <zenilib.h> at the top of all your source files. If you have and are still getting the error, it is likely that you are missing function definition.
<!-- Make sure you didn't add it inside of a comment block. -->
Writing a game using zenilib is not like writing a game to use a text console. Zenilib has to load a number of images into memory, convert them into a format usable by the graphics card, and then send them out to graphics card memory. It has to follow similarly stressful steps in loading the other databases, and in initializing all the services underlying your game. Some of these steps are inherently done in the background after you are given control of the application. Your game must allow for a short grace period before you can expect good performance from the system. A title screen often does the job nicely, but just keep this in mind.
Heap Corruption often implies that Visual Studio needed to rebuild something, but wasn't smart enough to figure it out. Doing a clean+rebuild often solves that problem. You are most likely to encounter this error when exiting a Game_State.
There is also a chance that you need to add a virtual destructor to at least one of your base classes -- especially if derived classes contain Chronometers, Vertex_Buffers, or Models.
Open the image file in the GIMP (or in
GIMP Portable).

If you don't see a strange checkered background, you failed to create your image
correctly, or you failed to export it correctly.
Be sure not to flatten your image as you export it.
And remember, always use .PNG.
Set 'tile' to '1' in textures.xml and use texture coordinates outside the range [0,1].
// In render() Quadrilateral<Vertex2f_Texture> quad( Vertex2f_Texture(Point2f(x , y ), Point2f(-1.0f, 0.0f)), Vertex2f_Texture(Point2f(x , y + h), Point2f(-1.0f, 2.0f)), Vertex2f_Texture(Point2f(x + w, y + h), Point2f( 3.0f, 2.0f)), Vertex2f_Texture(Point2f(x + w, y ), Point2f( 3.0f, 0.0f))); Material material("texture"); quad.lend_Material(&material); get_Video().render(quad);
Make sure the width and height of the image being loaded are both powers of 2. Make sure you disabled tiling of the particular texture in 'zenilib/config/textures.xml' (see zenilib/HOWTO.txt). Finally, be precise in your texture coordinates.
The only way to be absolutely sure is to use a fixed time step. So long as all changes to game state are made in 'perform_logic', you can accumulate the amount of time that has passed, and whenever it gets above a certain threshold, subtract off that fixed amount of time and perform a game step.
However, this isn't optimal for smoothness or performance, generally speaking. It is usually good enough to multiply all changes in motion by the amount of time that has passed since the previous frame. (e.g. position = time_step * velocity) The one caveat is that you probably need a bound on the size of a step to ensure stability, or you might just find yourself able to jump though a wall one time in a hundred.
Try storing Quadrilaterals and rendering them manually:
// Possibly in a constructor Vertex2f_Texture ul(Point2f(x , y ), Point2f(0.0f, 0.0f)); Vertex2f_Texture ll(Point2f(x , y + h), Point2f(0.0f, 1.0f)); Vertex2f_Texture lr(Point2f(x + w, y + h), Point2f(1.0f, 1.0f)); Vertex2f_Texture ur(Point2f(x + w, y ), Point2f(1.0f, 0.0f)); Material material("texture"); Quadrilateral<Vertex2f_Texture> quad(ul, ll, lr, ur); quad.fax_Material(&material); // In render() get_Video().render(quad);
Time to learn how to use Vertex Buffer Objects (VBOs). class Vertex_Buffer allows you to insert Triangle and Quadrilateral objects. After you give it all the Triangles and Quadrilaterals that you want it to be able to render, the Vertex_Buffer will be ready to render. Note that there will be no performance boost if the number of triangles in a Vertex_Buffers is very small. Note also that building a Vertex_Buffer is expensive, and should not be done every frame. (Recreating a Vertex_Buffer every frame defeats the purpose of using one.)
// Possibly in a constructor Vertex_Buffer *vbo_ptr = new Vertex_Buffer; vbo_ptr->give_quadrilateral(quad_ptr); // this pointer is dead to you vbo_ptr->fax_quadrilateral(quad_ptr); // you can keep the pointer // In render() vbo_ptr->render();
Rendering a VBO is much faster than rendering a number of Triangles or Quadrilaterals individually. However, you can't change values within a VBO after it is created. So, if you want to move one around, the correct approach is to use Model/World matrix transformations.
Video &vr = get_Video(); vr.push_world_stack(); //vr.translate_scene(...); //vr.rotate_scene(...); //vr.scale_scene(...); vbo_ptr->render(); vr.pop_world_stack();
You don't. Once a Vertex_Buffer is rendered, it becomes fixed. You must delete the old one and make a new one if you need to change the contents.
The Chronometer<Time> class is helpful.
// Possibly in a constructor m_seconds_passed = 0.0f; m_chrono.start(); // In perform_logic() const float seconds_passed = m_chrono.seconds(); const float time_step = seconds_passed - m_seconds_passed; m_seconds_passed = seconds_passed;
Additionally, the Time values from Timer can be used directly when convenient, or when you want to keep your values from being affected when the user pauses the game.
The first parameter of get_Video().set_2d(...) is an std::pair of 'Point2f's. By default, the first is (0, 0) and the second is (screen_width, screen_height). However, you can them to arbitrary coordinates in your 2D world.
Alternatively, the scene transformations described above can have the same effect.
Pass in the upper left corner as the first parameter. For the next two parameters, pass in Vector3f(width, 0.0f, 0.0f) and Vector3f(0.0f, height, 0.0f). Finally, pass in Vector3f(0.0f, 0.0f, 1.0f) for the fourth and final parameter. Without specifying a height, the Parallelepipeds are degenerate and will give erroneous intersection/distance values. Of course, if your Parallelepipeds are not axis-aligned, you will have to do some extra work manipulating the parameters.
At least one of your header files or source files probably has a file modification time that is in the future. This can happen if you edit files on different computers that disagree about how to keep time. The solution is to update the modification times of all your header and source files. (This can be done by opening all of them, modifying them, and resaving them.)
3DS files seem to refer to textures by all caps file names. (At least this is the result when exporting from 3ds Max.) zenilib blindly looks in the Textures database to find the corresponding textures.
e.g. Applying car.jpg to part of a model in 3ds Max will result in a reference to CAR.JPG in the 3DS file. CAR.JPG can refer to whatever you like in the Textures database. (It could be an image loaded from car.png. It could just as easily be a Sprite.)
If your program throws an Error when you try to render the Model, you can check zenilib/stderr.txt for an error message telling you what Texture it was looking for.