Changes

Libwiisprite/tutorial (view source)

Revision as of 18:11, 10 August 2009

97 bytes removed , 18:11, 10 August 2009

m

Robot: Cosmetic changes

Line 44: Line 44:

BUILD := build

SOURCES := source

−

DATA := data

+

DATA := data

INCLUDES :=

Line 172: Line 172:

# Next, open devkitPro/libogc/include ( \ slashes for windows) and paste the includes there.

# Go back to libwiisprite and open the libwiisprite folder in libwiisprite. Then open lib and copy the one .a file there and paste it in devkitPro/libogc/lib/wii.

−

# Again, go back to the root of libwiisprite and open libpng, copy the contents to the same place as the other .h files and then open.

+

# Again, go back to the root of libwiisprite and open libpng, copy the contents to the same place as the other .h files and then open.

# Open libwiisprite/libpng/lib and copy libpng.a and paste it in devkitPro/libogc/wii.

Now you are set up to start programming.

−

- [[~~user~~:WiiPhlex|WiiPhlex]]

+

- [[User:WiiPhlex|WiiPhlex]]

== Setting up the Video display. ==

Line 220: Line 220:

most people use std namespace a lot and may be wondering what wsp could mean, if you don’t know about namespaces I won’t tell you here as it is related to C++ programming, if you wish to learn about namespaces visit one of the many C++ programming sites.

All of the Libwiisprite classes work in the wsp namespace, so this little declaration saves us typing the namespace followed by scope resolution operators followed by more tedious typing that we can’t be bothered doing.

−

Now that we have all of our classes included into our program, we need to be able to use them. For the purpose we will just use one of these classes, GameWindow. We create an instance of the GameWindow in the main loop called gwd. The first function we call from the GameWindow class is InitVideo(), the Libwiisprite documentation defines the InitVideo function as follows

+

Now that we have all of our classes included into our program, we need to be able to use them. For the purpose we will just use one of these classes, GameWindow. We create an instance of the GameWindow in the main loop called gwd. The first function we call from the GameWindow class is InitVideo(), the Libwiisprite documentation defines the InitVideo function as follows

Line 248: Line 248:

Upon entering the loop 2 more ‘wiiMote’ related functions are called, and ask if the user is pressing the home button, if so break the loop, return 0 and exit the program. If however the user isn’t pressing the home button, the program executes the Flush() function, another function found in the GameWindow class we used at the start of the program. This function is defined as follows in the documentation

−

<source lang = "cpp">void Flush () Finishes rendering.</source>

+

<source lang = "cpp">void Flush () Finishes rendering.</source>

Not a huge amount of information I know, and I am not allowed to release the source for I’ll explain what it does. It copy’s the back buffer to the front buffer, waits for the vertical synchronisation then renders the image to the screen and deletes the back buffer, ready for a new image to be produced (even though it will look the same all the time in our small program here).

Line 275: Line 275: −

- [[~~user~~:WiiPhlex|WiiPhlex]]

+

- [[User:WiiPhlex|WiiPhlex]]

== Loading and printing images. ==

Line 304: Line 304:

An error code based on loading status.

−

Before you can load your image, you need to create an instance of the a class that will allow you to use your image or sprite in the way you wish, for example, for a static background (I refer to static to mean a still image not a member that exists for an entire class) you may consider using the Image class, but if you wanted to create a sprite you would use the Sprite class. I will be using snippets from Libwiisprite/examples/spritetest and explaining the code from that, I cannot add all of the code as one file contains raw data for an image which is 545 lines long. If you want to see this file it is Libwiisprite/examples/spritetest/source/libwiisprite.cpp.

+

Before you can load your image, you need to create an instance of the a class that will allow you to use your image or sprite in the way you wish, for example, for a static background (I refer to static to mean a still image not a member that exists for an entire class) you may consider using the Image class, but if you wanted to create a sprite you would use the Sprite class. I will be using snippets from Libwiisprite/examples/spritetest and explaining the code from that, I cannot add all of the code as one file contains raw data for an image which is 545 lines long. If you want to see this file it is Libwiisprite/examples/spritetest/source/libwiisprite.cpp.

Open the source file at Libwiisprite/examples/spritetest/source/spritetest.cpp. The first line of interest to us is this

Line 330: Line 330:

<source lang = "cpp">if(image.LoadImage("libwiisprite.png") != IMG_LOAD_ERROR_NONE)exit(0);</source>

−

This function is one of the ones that reads from the SD card. If the image isn’t at found at the location specified in the quotation marks, the function will return false and the program will automatically exit, otherwise it will return an address in memory where the image has been loaded and assign a value to our Image object, image. The next line is very similar but differs substantially in the details:

+

This function is one of the ones that reads from the SD card. If the image isn’t at found at the location specified in the quotation marks, the function will return false and the program will automatically exit, otherwise it will return an address in memory where the image has been loaded and assign a value to our Image object, image. The next line is very similar but differs substantially in the details:

<source lang = "cpp">if(image2.LoadImage(libwiisprite) != IMG_LOAD_ERROR_NONE)exit(0);</source>

−

libwiisprite (the one between the bracts in the above line) is defined in libwiisprite as a huge, fat array of constant, unsigned char’s. It’s been generated so that it can be loaded directly into memory on runtime which is what happens as soon as the program sees this chunky piece of code. So the above code segment attempts to find it in memory, if the image isn’t in memory, the program will exit, otherwise the value of libwiisprite is assigned to image2, and has been loaded from the buffer rather than the SD card. Easy!

+

libwiisprite (the one between the bracts in the above line) is defined in libwiisprite as a huge, fat array of constant, unsigned char’s. It’s been generated so that it can be loaded directly into memory on runtime which is what happens as soon as the program sees this chunky piece of code. So the above code segment attempts to find it in memory, if the image isn’t in memory, the program will exit, otherwise the value of libwiisprite is assigned to image2, and has been loaded from the buffer rather than the SD card. Easy!

Next we make use of our two sprite objects, sprite and sprite2 (imaginative names aren’t they?), with these two lines:

Line 391: Line 391:

−

It’s just a 2D coordinate system with an inverted vertical (or y) axis. With the origin (0,0) at the top left hand corner, x increases moving right of the screen and y increases moving down. A note on depth and z is that in computers it usually increases going into the screen and decreases coming out. The reason that the coordinate system works this way is because of the way that the back buffer prints to the front buffer (front buffer is a fancy name for screen), it starts printing from the top left corner at (0,0) then moves one pixel across the x axis to (1,0). Once a top line has been rendered to the front buffer, it will start printing at the next line and do it all over again until the entire image is drawn. This happens so fast that you can’t actually see each pixel being drawn. So when we use this call:

+

It’s just a 2D coordinate system with an inverted vertical (or y) axis. With the origin (0,0) at the top left hand corner, x increases moving right of the screen and y increases moving down. A note on depth and z is that in computers it usually increases going into the screen and decreases coming out. The reason that the coordinate system works this way is because of the way that the back buffer prints to the front buffer (front buffer is a fancy name for screen), it starts printing from the top left corner at (0,0) then moves one pixel across the x axis to (1,0). Once a top line has been rendered to the front buffer, it will start printing at the next line and do it all over again until the entire image is drawn. This happens so fast that you can’t actually see each pixel being drawn. So when we use this call:

Line 406: Line 406:

That’s it for this lesson now that you know how to load an image from the buffer or from the SD card and print them to the screen. One thing to note is that your images resolution must be a multiple of four otherwise your program will not be happy with you, in the next we will look at some more interesting stuff, specifically, manipulating images using Libwiisprite for more interesting effects.

−

- [[~~user~~:WiiPhlex|WiiPhlex]]

+

- [[User:WiiPhlex|WiiPhlex]]

== Basic Image Manipulation ==

−

I will still use spritetest.cpp for the purpose of this lesson. Now that we have a couple of images loaded and on screen, we want to be able to play around with them. There are several functions in Libwiisprite that allow you to manipulate images in various ways. Specifically, we will look at transformations to our images through SetStretchHeight(), SetStretchWidth, SetZoom and SetTransparency as well as a few other ‘Get’ functions.

+

I will still use spritetest.cpp for the purpose of this lesson. Now that we have a couple of images loaded and on screen, we want to be able to play around with them. There are several functions in Libwiisprite that allow you to manipulate images in various ways. Specifically, we will look at transformations to our images through SetStretchHeight(), SetStretchWidth, SetZoom and SetTransparency as well as a few other ‘Get’ functions.

We will start this lesson at line 99 and 100 of spritetest.cpp

Line 566: Line 566:

<source lang = "cpp">sprite.Move(-((f32)sprite.GetWidth()/2), -((f32)sprite.GetHeight()/2));</source>

−

calculates -((f32)sprite.GetWidth()/2), in other words, the inverse of the width of sprite divided by 2, and the second line does the same thing but uses GetHeight() instead of GetWidth(). This is a particularly useful function if you want to, well, move your images around, look at your average 2D side scroller, everything moves in some or other way, the character, the enemy’s, and of course the background. Say you wanted to make your image move right when you press the right button and move it left when you pressed the left button, your code might look something like this:

+

calculates -((f32)sprite.GetWidth()/2), in other words, the inverse of the width of sprite divided by 2, and the second line does the same thing but uses GetHeight() instead of GetWidth(). This is a particularly useful function if you want to, well, move your images around, look at your average 2D side scroller, everything moves in some or other way, the character, the enemy’s, and of course the background. Say you wanted to make your image move right when you press the right button and move it left when you pressed the left button, your code might look something like this:

Line 628: Line 628:

These two functions require the inclusion LayerManager.h and GameWindow.h as well as an instance of the classes. The first of these two functions, Draw() is used to determine off set and the second one does the rest of the rendering work but don’t worry about these too much I’ll explain them later, so that’s it for this lesson, a long lesson with lots of handy functions that are easy to use. Till next time,

−

- [[~~user~~:WiiPhlex|WiiPhlex]]

+

- [[User:WiiPhlex|WiiPhlex]]

== Layer Management. ==

Layers are a key element to using the Libwiisprite effectively and efficiently. They decide what you see, where you see it and everything in between. I’ll still by using the trusty file, spritetest.cpp by taking examples from it and how they work.

−

First thing we need to use layers is to include LayerManager.h, this is done in our program by including libwiisprite.h, which if you remember includes everything else in the library. Now look further down the source at line 42;

+

First thing we need to use layers is to include LayerManager.h, this is done in our program by including libwiisprite.h, which if you remember includes everything else in the library. Now look further down the source at line 42;

<source lang = "cpp">LayerManager manager(3);</source>

Line 754: Line 754:

[object1][object2][object3]

−

Then we call Remove() like this: manager.Remove(&object1);

+

Then we call Remove() like this: manager.Remove(&object1);

Now our list will look like this:

Line 801: Line 801:

There’s only one other function in the LayerManager class and that is SetViewWindow(), I won’t go over this yet though as it can be rather daunting (by Libwiistandards). Until then...

−

- [[~~user~~:WiiPhlex|WiiPhlex]]

+

- [[User:WiiPhlex|WiiPhlex]]

== Quad. ==

Line 853: Line 853:

Now I’ll go through a series of Get/Set Functions that are in the Quad class, explaining what they are and how to use em.

−

===SetRotation and GetRotation===

+

=== SetRotation and GetRotation ===

<source lang="cpp">void wsp::Quad::SetRotation ( f32 rotation )

Line 890: Line 890:

That’s about it for that function, now we are able to move on to the rest of the Get, Set functions.

−

===SetBorderWidth and GetBorderWidth===

+

=== SetBorderWidth and GetBorderWidth ===

<source lang="cpp">void wsp::Quad::SetBorderWidth ( u16 width )

Line 898: Line 898: −

- [[~~user~~:WiiPhlex|WiiPhlex]]

+

- [[User:WiiPhlex|WiiPhlex]]

== Basic Animation ==

−

A key element of Libwiisprite is creating an animated player that can move around the screen. This increases interactivity between the player and the program, it’s much more interesting to have your player appear to be running or what not rather than just standing there and sliding around (unless that’s the intention of your program). Imagine playing one of the ten thousand Mario bro’s games, and Mario didn’t have any animation, nor the enemies! This wouldn’t look very nice at all, so we need a system for animating our players, enemies etc.

+

A key element of Libwiisprite is creating an animated player that can move around the screen. This increases interactivity between the player and the program, it’s much more interesting to have your player appear to be running or what not rather than just standing there and sliding around (unless that’s the intention of your program). Imagine playing one of the ten thousand Mario bro’s games, and Mario didn’t have any animation, nor the enemies! This wouldn’t look very nice at all, so we need a system for animating our players, enemies etc.

−

There are literally hundreds of ways of for animating something on screen, and they all have their differences, but they all have one thing in common: They all follow the same process. There are several steps in producing an animation. The following steps must be complete:

+

There are literally hundreds of ways of for animating something on screen, and they all have their differences, but they all have one thing in common: They all follow the same process. There are several steps in producing an animation. The following steps must be complete:

1. Load the animation images into memory.

Line 917: Line 917:

Sprite Frame1, Frame2, Frame3, Frame4;

Image image1, image2, image3, image4;

−

Quad backGroundQuad;

+

Quad backGroundQuad;

</source>

Line 1,160: Line 1,160:

This will be the element of the array passed to SetFrameSequence(). And that’s about it for this lesson, till next time...

−

- [[~~user~~:WiiPhlex|WiiPhlex]]

+

- [[User:WiiPhlex|WiiPhlex]]

== Collision Detection ==

Line 1,166: Line 1,166:

Most games these days will have some form of collision detection weather you know it or not, in fact every game I can think of has some form of collision detection weather it stops you moving off the screen or Unreal Tournament 3’s complete physics engine, it all has some form of detecting collision. I will go over the collision detection functions that Libwiisprite supports and how to use them, along with a method of optimizing your collisions using a node based system.

−

An introduction to what collision detection is: say you’ve just made your game with some pretty graphics, for example, a wall and a box. You know that in real life when your box hits the wall it will stop, sadly though, your game is not real life, therefore you will simply move through (under or over if it’s 2D) your wall that you worked so hard to put there. So now we need a system that will tell use when our box is touching the wall then we act on it to stop it moving.

+

An introduction to what collision detection is: say you’ve just made your game with some pretty graphics, for example, a wall and a box. You know that in real life when your box hits the wall it will stop, sadly though, your game is not real life, therefore you will simply move through (under or over if it’s 2D) your wall that you worked so hard to put there. So now we need a system that will tell use when our box is touching the wall then we act on it to stop it moving.

This would require some math and a lot of GetWidth() calls, but, Libwiisprite has brought us a bunch of functions that will allow us to check collision without having to even know what math is. First function regarding collision is CollidesWith(), if you have looked at the documentation, you will see 3 different definitions for CollidesWith(), we will first look at the second which looks like this:

Line 1,189: Line 1,189:

Figure 1: Returns false; Figure 2: Returns true

−

[[~~Image~~:Flexfig1.png‎]] [[~~Image~~:Flexfig2.png‎]]

+

[[File:Flexfig1.png‎]] [[File:Flexfig2.png‎]]

Figure 1 would return false as they aren’t colliding. Whereas, figure 2 would return true because they are colliding.

Line 1,195: Line 1,195:

Ok, so now we know weather or not they are colliding, but that doesn’t automatically stop them from moving through the object. Usually you will want to stop the image once it is touching the border of the other image, but not overlapping at all that would mean stopping the sprite2 from moving further right in any of the given situations:

−

[[~~Image~~:Flexfig3.png]]

+

[[File:Flexfig3.png]]

Figure 3: sprite2 will be unable to move any further right without moving above sprite

Line 1,221: Line 1,221: −

oldX will be assigned the value of Player.x (100), further, we are pressing left so when it gets the input Player.x is decreased by, say 2, now Player.x = 98. Next thing that happens is that we check for collision, collision returns true therefore we don’t want Player.x to equal 98, so because collision is true Player.x is now assigned the value of oldX which is 100, so now we are moved back to the x location, 100, therefore, stopping the player from moving left even though we are pressing left. Some people have troubles, when collision is true and they try to move away, they become locked onto the image and are unable to move, due to collision being tested after the input this is avoided and works fine for being able to move away.

+

oldX will be assigned the value of Player.x (100), further, we are pressing left so when it gets the input Player.x is decreased by, say 2, now Player.x = 98. Next thing that happens is that we check for collision, collision returns true therefore we don’t want Player.x to equal 98, so because collision is true Player.x is now assigned the value of oldX which is 100, so now we are moved back to the x location, 100, therefore, stopping the player from moving left even though we are pressing left. Some people have troubles, when collision is true and they try to move away, they become locked onto the image and are unable to move, due to collision being tested after the input this is avoided and works fine for being able to move away.

Now, you may have noticed all of the calls CollidesWith() have only used the first parameter, I’ve stayed away completely from it. So now I shall reveal its functionality. Due to the nature of the collision we’ve been using, it will only work for images at their native resolution and not rotated (amongst other things) so that’s why we have the second parameter. Set it true if you want to add collision detection for objects that are rotated or zoomed, if you aren’t sure how to go about this:

Line 1,233: Line 1,233:

Chances are, most of those checks will return false, so we’ve just wasted a whole lot of cycles, so now we need a method of limiting the number of collision detections. A simple way of doing this is separating the ‘screen’ into a series of squares, known as nodes. You can’t see these squares on the screen though, consider them imaginary. Say we split our screen into 4 equal nodes, the nodes may look like figure 4.

−

[[~~Image~~:Flexfig4.png]]

+

[[File:Flexfig4.png]]

The numbering system is simply there so I can explain things easier, so from now on I will refer to the top right node as Node1, the top right Node2 and so on.

Line 1,261: Line 1,261:

Basic data for a rectangle.</source>

−

Now we need to fill these attributes. To simplify things, let’s say our screen resolution is 800x600, now we need to separate 800x600 into 4 equal squares like in figure 4. So we take the resolution and divided it by square root of n number of nodes, so square root of 4 is 2, 800 x 600 divided by 2 = 400 x 300, this is the size of each of our nodes and will be filled in as follows:

+

Now we need to fill these attributes. To simplify things, let’s say our screen resolution is 800x600, now we need to separate 800x600 into 4 equal squares like in figure 4. So we take the resolution and divided it by square root of n number of nodes, so square root of 4 is 2, 800 x 600 divided by 2 = 400 x 300, this is the size of each of our nodes and will be filled in as follows:

<source lang="cpp">Node1.height = 300; Node1.width = 400;</source>

Line 1,267: Line 1,267:

And continue on for the rest of the nodes filling in the same values. Next we need the x and y values of the nodes so the program knows where they are on the screen. This is easily done considering the top left of the screen to be (0,0) and x increases moving left with y increasing moving down the screen, look at figure 5 for a visual representation of all coordinates.

−

[[~~Image~~:Flexfig5.png]]

+

[[File:Flexfig5.png]]

If you recall, all coordinates for images (and objects alike) are for the top left corner of the image/object, so our x and y values would look like this:

Line 1,280: Line 1,280:

Next we check collision against each of the nodes, not the objects that we are actually colliding with within the nodes, we don’t care about weather or not we are colliding with them (note, some additional coding may be required dependant on how your program is set up), so we would do it like this:

−

<source lang="cpp">If (Player.CollidesWith(&Node1)) { // check node1

+

<source lang="cpp">If (Player.CollidesWith(&Node1)) { // check node1

// other stuff here }

Line 1,296: Line 1,296:

What this does is check what nodes we are in, each will return true if we are in that node and execute ‘other stuff’ (I’ll get to what the other stuff is in just a moment) otherwise it will check the next node. Now we will get into that other stuff. Now that we know which node(s) the player is in, we know what we don’t have to check. If you don’t get what I mean look at figure 6:

−

[[~~Image~~:Flexfig6.png]]

+

[[File:Flexfig6.png]]

First our program will check Node1, because Player isn’t colliding with or ‘in’ Node1, this will return false and it will move to Node2, Node’s 2 and 3 will return false, but Node4 will return true and execute other stuff, this other stuff is the collision checks that are within that node so let’s replace other stuff with the other collision checks for the objects that are in Node4:

Line 1,315: Line 1,315:

See now, we have cut 100 checks (25 objects in each node was the example), down to just 29, 4 for the nodes and 25 for the objects in the node, that’s 71 less checks and exactly the same result as 100 checks! Now consider the following figure (7)

−

[[~~Image~~:Flexfig7.png]]

+

[[File:Flexfig7.png]]

First it will check Node1, this will return true as Player is inside Node1, it will then proceed to check all of the objects in Node1 against player, once this has finished, it will check Node2, which again will return true and check collision for the objects in Node2. Then it will check Nodes 3 and 4 which will both return false. This is now 54 checks rather than 100.

Line 1,321: Line 1,321:

This hasn’t been the best way of implementing a Node based collision system, it would have been better to create a node class then instance it for easier use, although I don’t have the time. This system is similar to one called a quad tree, although it may be overkill to implement such a sophisticated system in what will mostly be 2D programs, the basics are that it will split your plane into 4 equal sized nodes just like figure 4, then check collision against those nodes, this is where it gets a little more complicated. Once it knows which nodes you are in, it will then split that node into another 4 nodes like in figure 8:

−

[[~~Image~~:Flexfig8.png]]

+

[[File:Flexfig8.png]]

It will subdivide further to a specified level, but first it will check again which ‘leaf’ nodes you are in (leaf nodes are simply the nodes that are farthest down the tree). If all this talk of tree’s and leafs is confusing you, you best learn it as these are the proper terms, the parent is a node that has n number of leaf nodes, once a leaf node gets another node attached to it further along it becomes a parent node and the new node is the leaf. Back to our program now, after another check this happens:

−

[[~~Image~~:Flexfig9.png]]

+

[[File:Flexfig9.png]]

Another split would look like this:

−

[[~~Image~~:Flexfig10.png]]

+

[[File:Flexfig10.png]]

It will only subdivide a certain number of times as specified by the programmer, as you can see, it gets rather messy, but once the quadtree has reached the leaf nodes, it will check collision against the objects in each of the leave nodes. The more levels you add to your quad tree the more precise the checks will be but as I said, it gets to a point where you will lose performance rather than gain any. This method wouldn’t be at all difficult using Libwiisprite, just create a Node class and a QuadTree class, if you wish to know more, there are many resources related to computer science and large terrain rendering that feature quad trees as they are widely used for collision detection in large terrains and also sometimes for optimizing graphics rendering engines.

Line 1,370: Line 1,370:

That’s about as much patience as I have for collision detection, till next time...

−

- [[~~user~~:WiiPhlex|WiiPhlex]]

+

- [[User:WiiPhlex|WiiPhlex]]

== Tiled Layers ==

Line 1,376: Line 1,376:

Say you have an animation that requires 12 different frames for moving left, right looking up etc, it’s not very practical to load all of those 12 images individually, so many programmers opt for using a ‘sprite sheet’, this is a single image that is made up of a whole series of frames, an example of a sprite sheet:

−

[[~~Image~~:Flexfig11.png]]

+

[[File:Flexfig11.png]]

As you can see, it’s easier to load this than the 96 individual images on that sheet. If we were to load that using the LoadImage() function it would just load the entire thing and assume it to be a single object, so that’s where Libwiisprite makes life easier again. With the TiledLayer class, we are now able to load an image then pass it to the functions that will split it up for us (given a few numbers) and then we have a nice animation we can play around with.

Line 1,385: Line 1,385:

For this example, imagine this is our sprite sheet that we will be using throughout the program:

−

[[~~Image~~:Flexfig12.png]]

+

[[File:Flexfig12.png]]

Obviously, this is demonstration purposes only, you would consider things like deleting all pixels that you don’t need, white pixels and invisible, they are white... So deleting them will make your image smaller and look much better when copied to the front buffer.

Line 1,391: Line 1,391:

Now imagine a grid system on this, where the there are a total of 4 tiles vertically and 2 horizontally, like this:

−

[[~~Image~~:Flexfig13.png]]

+

[[File:Flexfig13.png]]

Line 1,446: Line 1,446:

Animated tiles are created using the CreateAnimatedTile () function, which returns the index to be used for the new animated tile. The animated tile indices are always negative and consecutive, beginning with -1. Once created, the static tile associated with an animated tile can be changed using the SetAnimatedTile () function.

−

[[~~Image~~:Flexfig14.png]]

+

[[File:Flexfig14.png]]

The TiledLayer's grid is made up of equally sized cells; the number of rows and columns in the grid are specified in the constructor, and the physical size of the cells is defined by the size of the tiles.

Line 1,452: Line 1,452:

The contents of each cell is specified by means of a tile index; a positive tile index refers to a static tile, and a negative tile index refers to an animated tile. A tile index of 0 indicates that the cell is empty; an empty cell is fully transparent and nothing is drawn in that area by the TiledLayer. By default, all cells contain tile index 0.

−

The contents of cells may be changed using SetCell () and FillCells() Several cells may contain the same tile; however, a single cell cannot contain more than one tile. The following example illustrates how a simple background can be created using a TiledLayer.

+

The contents of cells may be changed using SetCell () and FillCells() Several cells may contain the same tile; however, a single cell cannot contain more than one tile. The following example illustrates how a simple background can be created using a TiledLayer.

−

[[~~Image~~:Flexfig15.png]]

+

[[File:Flexfig15.png]]

In this example, the area of water is filled with an animated tile having an index of -1, which is initially associated with static tile 5. The entire area of water may be animated by simply changing the associated static tile using setAnimatedTile(-1, 7).

−

[[~~Image~~:Flexfig16.png]]

+

[[File:Flexfig16.png]]

−

===Rendering a TiledLayer===

+

=== Rendering a TiledLayer ===

A TiledLayer can be rendered by manually calling its paint method; it can also be rendered automatically using a LayerManager object.

Line 1,521: Line 1,521:

Moving along quickly, we will now look at the last function regarding the TiledLayer class, Draw()

−

<source lang="cpp">void Draw (f32 offsetX=0, f32 offsetY=0) const

+

<source lang="cpp">void Draw (f32 offsetX=0, f32 offsetY=0) const

Draws the tiledlayer to the current viewport.</source>

Line 1,530: Line 1,530:

Simple! And that brings us to the end of the Tiled Layer section of this guide. Note: some of this was taken from http://java.sun.com/ I thank the people at Sun for allowing the use of their material in this section. Until next time,

−

- [[~~user~~:WiiPhlex|WiiPhlex]]

+

- [[User:WiiPhlex|WiiPhlex]]

== Pixel Referencing and Offset ==

−

You may have read up to this point and have been thinking along the way, “dammit stop saying ignore offset!”, well today you become a man, erm, I mean you learn what offset and pixel referencing is, sorry I often get the two mixed up... Anyway, I’ll start with the offset first of all as it is the easiest to understand.

+

You may have read up to this point and have been thinking along the way, “dammit stop saying ignore offset!”, well today you become a man, erm, I mean you learn what offset and pixel referencing is, sorry I often get the two mixed up... Anyway, I’ll start with the offset first of all as it is the easiest to understand.

In plain terms, offset means not set correctly. Think about your screen, it’s a grid made up of tens of thousands of dots, each of these dots has a ‘default’ location, top left pixel is (0,0), when you change the offset, you move where these locations are. For example, when you go to print an image at location (100, 100), then it will print with its top left corner at the coordinate (0,0) and print the rest of the pixels based on that.

Line 1,540: Line 1,540:

If however, you were to print that image at location (100,100) with an offset of (10,10) then you would print that image at location (110,110). You can calculate the offset by adding the coordinates, this goes for negatives as well, a few examples.

−

<source lang="cpp">Coordinates OffSet PrintLocation

+

<source lang="cpp">Coordinates OffSet PrintLocation

−

(10, 40) (-20, 4) (-10, 44)

+

(10, 40) (-20, 4) (-10, 44)

−

(300, 0) (0, 0) (300, 0)

+

(300, 0) (0, 0) (300, 0)

Etc</source>

−

That’s about all there is to offset, so let’s look at the slightly more complex, Pixel Referencing. The easiest way to understand pixel references is an example. In sprite.cpp we looked at the following SetPosition() function:

+

That’s about all there is to offset, so let’s look at the slightly more complex, Pixel Referencing. The easiest way to understand pixel references is an example. In sprite.cpp we looked at the following SetPosition() function:

<source lang="cpp">sprite2.SetPosition(320, 240);</source>

Line 1,559: Line 1,559:

Usually when you print an image to the screen, it, by default, prints to the top left (wsp::REFPIXEL_POSITIONING, default parameter in the emuneration is REFPIXEL_POS_TOPLEFT), but what we have done here, is instead pass it a different parameter that lets you customize where your image will print by default. We pass the function REFPIXEL_POS_PIXEL, which in is defined in the enum section:

−

REFPIXEL_POS_PIXEL The reference pixel is placed at the X and Y coordinates.

+

REFPIXEL_POS_PIXEL The reference pixel is placed at the X and Y coordinates.

This is just another method of setting where you want to print your image, the x any y coordinates move the reference pixel to the coordinate specified and when SetPosition() is called and the image is printed at the centre of the screen.

Line 1,565: Line 1,565:

What this does is effectively cut out part of the image. Say we have an image that has a resolution of 150 x 150 pixels and we print it at location (0,0) then it may look something like this:

−

[[~~Image~~:Flexfig17.png]]

+

[[File:Flexfig17.png]]

−

Now say that we have set the pixel reference to (10,10) then it will find the pixel on the image that is at location (10,10) which would be where the black dot is on the below image:

+

Now say that we have set the pixel reference to (10,10) then it will find the pixel on the image that is at location (10,10) which would be where the black dot is on the below image:

−

[[~~Image~~:Flexfig18.png]]

+

[[File:Flexfig18.png]]

The image will be printed like this at location (0,0)

−

[[~~Image~~:Flexfig19.png]]

+

[[File:Flexfig19.png]]

If you look closely you can see that some of the image has been cut off, 10 pixels starting at the right side and 10 pixels starting from the top have been cut off and the image is printed at the coordinate (0,0) just as it would if it had no pixel referencing. You essentially crop the image from the top left corner using whatever values you have assigned the parameters. So looking at the call in sprite.cpp to the refpixel function you can see that the image is still being printed but is also passed the enumeration REFPIXEL_POS_PIXEL. That brings me to the end of another (but short) lesson on the Libwiisprite, hope you learned something.

Line 1,579: Line 1,579:

If you wish to contact me drop me an email at phlex.wii@gmail.com

−

== EXAMPLE PROGRAMS ==

+

== EXAMPLE PROGRAMS ==

−

===Lesson 1: Setting up Libwiisprite for use.===

+

=== Lesson 1: Setting up Libwiisprite for use. ===

−

Description: This is the same code encountered in chapter 1, to build, make sure to have to include the correct lib’s (as shown in chapter 1) in your make file. For a template make file, refer to lesson 1.

+

Description: This is the same code encountered in chapter 1, to build, make sure to have to include the correct lib’s (as shown in chapter 1) in your make file. For a template make file, refer to lesson 1.

−

===Lesson 2: Setting up the Video display. ===

+

=== Lesson 2: Setting up the Video display. ===

Description: basic template for using Libwiisprite, in order to build make sure you have included the correct lib’s as stated above. The following program will set up the wii and render the background with the colour white.

Line 1,620: Line 1,620:

</source>

−

===Lesson 3: Loading and printing images.===

+

=== Lesson 3: Loading and printing images. ===

Description: a simple program that loads an image from SD card and prints it to the screen, see Lesson3 for more information.

Line 1,672: Line 1,672:

</source>

−

===Lesson 4: Basic Image Manipulation ===

+

=== Lesson 4: Basic Image Manipulation ===

Description: Shows some examples of manipulation images with some of the basic public functions in Libwiisprite, this was taken from sprite.cpp in the Libwiisprite examples release. This assumes you have two images on the SD card called libwiisprite.png and libwiisprite2.png..

Line 1,791: Line 1,791:

</source>

−

===Lesson 5: Layer Management.===

+

=== Lesson 5: Layer Management. ===

Description: A small program that shows how to use function in the LayerManager class. By then end of the series of calls, Quad is at location 0 and sprite is at 1.

Line 1,858: Line 1,858:

</source>

−

===Lesson 6: Quad.===

+

=== Lesson 6: Quad. ===

Description: Shows examples of how you might call functions in the quad class as well as how to create one.

Line 1,918: Line 1,918:

}</source>

−

===Lesson 7: Basic Animation===

+

=== Lesson 7: Basic Animation ===

None Yet, if you have a sample to submit for this section email me at phlex.wii@gmail.com

−

===Lesson 8: Collision Detection===

+

=== Lesson 8: Collision Detection ===

Description: Shows how to test for collision between various objects, does not contain an example for node based collision detection (yet).

Line 2,030: Line 2,030:

}</source>

−

===Lesson 9: Tiled Layers.===

+

=== Lesson 9: Tiled Layers. ===

None Yet, if you have a sample to submit for this section email me at phlex.wii@gmail.com

−

===Lesson 10: Pixel Referencing and Offset.===

+

=== Lesson 10: Pixel Referencing and Offset. ===

None Yet, if you have a sample to submit for this section email me at phlex.wii@gmail.com

Line 2,040: Line 2,040:

(WiiPlex can put this in when he can ;))

−

- [[~~user~~:WiiPhlex|WiiPhlex]]

+

- [[User:WiiPhlex|WiiPhlex]]

For helping putting the guide up on the Wiki; specifically the images but other parts too.

−

- [[~~user~~:LOLDSFAN|LOLDSFAN]]

+

- [[User:LOLDSFAN|LOLDSFAN]]

[[Category:Development]]

WiibrewBot

Bots

1,189

edits

Changes

Libwiisprite/tutorial (view source)

Revision as of 18:11, 10 August 2009

Navigation menu

Search