World Coordinates with GameView

[sterlingy]

I've made a lot of progress on a game, thanks to the help of many people in this forum. Many of the mechanics are in place, but I'm now grappling with world coordinates, screen coordinates and object coordinates.

I've read a few threads on this, and I know the theory to employ, but I'm stumped on something.

If an object's world coordinates are outside of the screen coordinates, then it shouldn't be drawn. However, moving objects still need to have their coordinates updated, and this is done in the SpriteAnimator, by modifying the DestRect for each object, and it seems that all objects are always drawn, even if they are off the screen.

How does one go about updating the positions and velocities, without wasting time to draw the object's sprite?


-Sterling

 

[Informatix]

If an object's world coordinates are outside of the screen coordinates, then it shouldn't be drawn. However, moving objects still need to have their coordinates updated, and this is done in the SpriteAnimator, by modifying the DestRect for each object, and it seems that all objects are always drawn, even if they are off the screen.

I don't think you should worry about the time spent to draw a few sprites off screen. That becomes only a concern when there are a lot of sprites to draw, or very big sprites moving.

 

[sterlingy]

Hmmm... I guessing that I don't need to compute the world coordinates. I think it's best to store them in variables associated with the object's CLASS.

I'm assuming that DestRect will allow negative numbers and numbers outside of the screen's borders. If this is the case, then just moving the screen's upper left corner around world coordinates should take care of the rest.

I think I'm missing a key part to this.

-Sterling

 

[basil99]

As for me, I don't recommend to use spritesheets, because sprites may have a different width/height depending on character behaviour ( see attachments ).

It may be a waste of memory to handle excesivly big spritesheets and later hard to position/move game character.

Example: if your character is a walking guy, what coordinate you need to update ? Answer is - use "middle x" as character "main position" coordinate, so for each sprite in animation sequence

XspriteLeft = Xmiddle - SprireWidth/2
XspriteRight = Xmiddle + SprireWidth/2

This brings you smooth moving for walking/running/sneaking etc

With spritesheets you need to make sort of trim to get rid of useless transparent space around the sprite

 

[Informatix]

As for me, I don't recommend to use spritesheets, because sprites may have a different width/height depending on character behaviour ( see attachments ).

It may be a waste of memory to handle excesivly big spritesheets and later hard to position/move game character.

I don't use the GameView library and I can't say whether it's a problem with this library, but I'm a bit surprised.
I can't see why you waste memory by loading spritesheets. If you load individual images, you will occupy the same place in memory at the end (recycling and reloading bitmaps continuously to save memory would strongly impact the performance).
In the OpenGL world, it is highly recommended to use texture atlas (all your sprites or textures in the same file loaded in memory) but I'm not sure it is so important with the canvas since we don't bind textures.

With spritesheets you need to make sort of trim to get rid of useless transparent space around the sprite

It depends on how you select the images to display. If you define a source rectangle and pass it to the draw method, you don't need any space around your sprite. If you use a function that animates automatically your spritesheet, then you need to create a space around each sprite to fit the required size (identical for all sprites).

If the sprites in a spritesheet have been created with basic animation techniques (with all images aligned on the same axis), there should be no problem to animate them. You can use their top left coordinates if they share the same size, or use their center coordinates. What's "hard" here?

 

[basil99]

I don't use the GameView library and I can't say whether it's a problem with this library, but I'm a bit surprised.
I can't see why you waste memory by loading spritesheets. If you load individual images, you will occupy the same place in memory at the end (recycling and reloading bitmaps continuously to save memory would strongly impact the performance).

Can't agree. 2 sprites i posted above are 320x319 and 188x292, so 627904 bytes total ( 4 bytes per pixel ). And a corresponding spritesheet must be 320x319x2 minimum that gives 816640. Pretty selfexplaining

In the OpenGL world, it is highly recommended to use texture atlas (all your sprites or textures in the same file loaded in memory) but I'm not sure it is so important with the canvas since we don't bind textures.

Really ? I don't know that, what the reason ?

It depends on how you select the images to display. If you define a source rectangle and pass it to the draw method, you don't need any space around your sprite. If you use a function that animates automatically your spritesheet, then you need to create a space around each sprite to fit the required size (identical for all sprites).

Yes, correct, but you need to calculate this rectangles coordinates in a spritesheet space, may be a very boring job for game designer

 

[Informatix]

Can't agree. 2 sprites i posted above are 320x319 and 188x292, so 627904 bytes total ( 4 bytes per pixel ). And a corresponding spritesheet must be 320x319x2 minimum that gives 816640. Pretty selfexplaining

Ah ok ! If the sprites have different sizes, I completely agree. But what's called a "spritesheet" is usually a sequence of frames having all the same size, like a movie strip.

Texture atlas, on the contrary, combine images with different sizes (as much as you can for objects being drawn together) and, to optimize the space, it exists tools named "texture packers". Example. I didn't try to use these tools to create SpriteSheets but that deserves a try.

Really ? I don't know that, what the reason ?

Wikipedia

Yes, correct, but you need to calculate this rectangles coordinates in a spritesheet space, may be a very boring job for game designer

Hum... Writing thousands of lines of code for a game is really boring anyway. Only the result is funny.

 

[basil99]

Texture atlas, on the contrary, combine images with different sizes (as much as you can for objects being drawn together) and, to optimize the space, it exists tools named "texture packers". Example. I didn't try to use these tools to create SpriteSheets but that deserves a try.

This utility looks interesting, wonder is it capable to calculate and output images coordinates.

Hum... Writing thousands of lines of code for a game is really boring anyway. Only the result is funny.

)

 

[Informatix]

This utility looks interesting, wonder is it capable to calculate and output images coordinates.

I don't use this tool in particular but I presume it works as all others. It creates a big image file with the packed textures and another file (a texture index) that lists sizes and offsets of each texture inside the file.
This set of tools may also interest you: ShoeBox.

 

[basil99]

Thanks for the link

 

[sterlingy]

You both bring up some interesting points. For my purposes, sprites work just fine. I don't know much about openGL, but I suppose when I finish this game, I'll look into it. I assume there are some good examples in this forum that show it's implementation.

-Sterling

 

[Informatix]

You both bring up some interesting points. For my purposes, sprites work just fine. I don't know much about openGL, but I suppose when I finish this game, I'll look into it. I assume there are some good examples in this forum that show it's implementation.

I try to learn OpenGL since a few weeks and it's tough. I'm able now to do most basic things and a few advanced things but the learning curve is really steep. To be honest, I'm not convinced it's worth the time spent for 2D or 2.5D (isometric) applications. My AcceleratedSurface lib, or the GameView lib, is able to compete with OpenGL in 2D. If you use some tricks and techniques, you can do better with OpenGL than any Canvas-based library but you write so many lines of code to simply draw a sprite or a text! Devices are more and more powerful, so the need for OpenGL is less and less obvious in most cases. That being said, in 3D, OpenGL is the only solution currently. The Canvas 3D functions are still too slow and some of them do no benefit yet from the hardware acceleration.

 

[sterlingy]

My AcceleratedSurface lib, or the GameView lib, ...

What is AccelerateSurface lib? Is that available to everyone or is it your lib for yourself?

-Sterling

 

[Informatix]

What is AccelerateSurface lib? Is that available to everyone or is it your lib for yourself?

-Sterling

It's here.

 

[sterlingy]

This lib looks interesting. Just ONE MORE thing for me to learn. It's endless. Sometimes I wish there weren't so many choices.

-Sterling