Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / I need your opinion on sprites!

Author
Message
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 16th Nov 2013 23:07 Edited at: 16th Nov 2013 23:43
Link
Hi, fellows! I need your opinion on sprites!

Let's take the Super Mario game as an example:


The world and characters are generated from sprites.
I can make an image file for every sprite (1 coin, 1 brick etc...).
The usage is common:

Or I can make one "atlas" image file for all sprites.
Then the following pseudo code will handle the sprites creation:


So, what way is better? Multiple files or one atlas with image handling? And why?

edit: added code examples

Back to top
Profile PM
basjak
15
Years of Service
User Offline
Joined: 16th Apr 2010
Location: feel like signing up for mars
Posted: 16th Nov 2013 23:51
Link
Making world with single sprite would save you plenty of time , memory, coding, speed.

Back to top
Profile PM Email Website
BatVink
Moderator
22
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 17th Nov 2013 00:50
Link
VanB has lots of experience in this field, and he often talks about an image atlas, using UV offsets for each sprite.

ten-net consulting limited
Back to top
Profile PM Email
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 17th Nov 2013 09:50 Edited at: 17th Nov 2013 09:56
Link
Hm. I don't understand the sprites clearly - if I make 64 sprites from one 1024x1024 atlas, they will share the source or copy it into themselves?

P.S. I realized that I can delete image from which sprite has been made, so it copies image, so the memory usage will be high. Or I am wrong?

Back to top
Profile PM
Rudolpho
19
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 17th Nov 2013 11:41
Link
Quote: "if I make 64 sprites from one 1024x1024 atlas, they will share the source or copy it into themselves?"

They will (at least they definitively should) share the same texture, just like objects do.
I don't think it is necessarily faster to access one large texture rather than several small ones on modern graphics cards though; that was probably more the case back when textures had to be powers of two and the images you needed stored weren't quadratic. Of course I may be wrong, but for example using 255 separate images representing bitmap font characters doesn't seem noticyable slower to use than using an offset for one single font sheet. It is possible that changin referenced texture takes some time on the GPU or similar though, someone with more experience would have to chime in there.


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 17th Nov 2013 11:53 Edited at: 17th Nov 2013 11:56
Link
Quote: "doesn't seem noticyable slower to use than using an offset for one single font sheet"

I thought that sprite atlas would be slower...

Quote: "just like objects do."

But objects use real texture, when sprites use a copy that stores somewhere else as I can delete source image. That's odd moment.

Quote: "someone with more experience would have to chime in there"

That would be great!

Back to top
Profile PM
Rudolpho
19
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 17th Nov 2013 15:00
Link
Quote: "But objects use real texture, when sprites use a copy that stores somewhere else as I can delete source image. That's odd moment."

If that is truly the case (I'm not in a position where I can try it) I would guess the images are reference counted and only actually deleted once all sprites referencing them has either been deleted too or changed their referred image.


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
BatVink
Moderator
22
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 17th Nov 2013 16:14
Link
The way I believe it works with modern graphics cards is the image is copied to the card, and all the sprites reference the one image.

Even if you have one sprite using the full image it uses the exact same process. So by using an atlas image you are making things more efficient by having just one image to reference, rather than a bank of many images to work through.

4 sprites, 1 image:

sprite1 texture = image 1 0.0,0.0 -> 0.5,0.5
sprite2 texture = image 1 0.5,0.0 -> 1.0,0.5
sprite3 texture = image 1 0.0,0.5 -> 0.5,1.0
sprite4 texture = image 1 0.5,0.5 -> 1.0,1.0

1 sprite, 1 image:
sprite1 texture = image 1 0.0,0.0 -> 1.0,1.0

4 sprites, 4 images:
sprite1 texture = image 1 0.0,0.0 -> 1.0,1.0
sprite2 texture = image 2 0.0,0.0 -> 1.0,1.0
sprite3 texture = image 3 0.0,0.0 -> 1.0,1.0
sprite4 texture = image 4 0.0,0.0 -> 1.0,1.0

The difference in the third example is having to locate multiple images in different locations.

ten-net consulting limited
Back to top
Profile PM Email
Le Verdier
13
Years of Service
User Offline
Joined: 10th Jan 2012
Location: In the mosh-pit
Posted: 17th Nov 2013 17:23 Edited at: 17th Nov 2013 17:24
Link
I'm not experienced in 2D, but I would use a texture atlas, a grid mesh and an ortho projection.
For exemple, if the screen size is 640*480, a block size of 16, the grid size will be 41*31, the extra block in order to allow scrolling.
The scrolling is done by changing camera pos and the block shift is done by changing the UVs vertexdata for each corner of the quads.
Not forgetting to disable texture filtering, mipmapping... (this dont work with texture atlas) and backdrop..
But maybe this looks too much complicated or there is other techniques I dont know...?

Back to top
Profile PM
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 18th Nov 2013 00:00
Link
@BatVink
Quote: "The way I believe it works with modern graphics cards is the image is copied to the card, and all the sprites reference the one image."

Hope it so! Also yes, few atlases is a better way to organize sprites.

@Le Verdier
What about depth? I mean z-fight.

Back to top
Profile PM
Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 18th Nov 2013 03:24
Link
Here's an option that allows you to create a single atlas texture (tilemap) but break it into individual tiles.

http://forum.thegamecreators.com/?m=forum_view&t=164293&b=6

http://zimnox.com
Back to top
Profile PM Email Website
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 18th Nov 2013 12:23
Link
Hey, that is neat! Do you recommend to tear apart sprite atlas?

Back to top
Profile PM
Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 18th Nov 2013 19:34
Link
I think it would be a lot less complicated than configuring UV coordinates. If you do go that route though, in regards to your example I'd use clone sprite.

If I recall, a few of us did some timing across various tilemapping methods years back and I don't think there was any significant difference. So I'd go with whatever is easier. My function above is what I've used many times. In AppGameKit, I use an atlas method instead because the animation commands make it much easier.

http://zimnox.com
Back to top
Profile PM Email Website
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 18th Nov 2013 23:18
Link
Oh, I forgot about animations! Then we need to use hybrid way.

Back to top
Profile PM
Sasuke
19
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 19th Nov 2013 12:36 Edited at: 19th Nov 2013 12:37
Link
Quote: "What about depth? I mean z-fight."


Depending on how you've got it set up you can just use Disable Object Zbias which the next object will overlap the last. What I use is an Orthogonal Camera, object will remain the same size and for depth you can just z position to whatever, which makes layering simple.

Example of Orthogonal Camera I use... just look like 2d sprite but it's all objects and different z positions (actually started my 2d engine yesterday).


One major advantage is using shaders especially for lighting, post processing effects and etc... and more control using objects.

"Get in the Van!" - Van B

Attachments

Login to view attachments
Back to top
Profile PM Email
Sph!nx
16
Years of Service
User Offline
Joined: 3rd Dec 2008
Location: The Netherlands
Posted: 19th Nov 2013 13:53
Link
Looks good, Sasuke!

Regards Sph!nx
www.mental-image.net
Back to top
Profile PM
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 20th Nov 2013 12:12
Link
Sasuke, I believe that all your decorations are scrolling together? In that case i'd prefer non-ortogonal camera as you have neat decorations and i'd like to see them in a 2D perspective.

Back to top
Profile PM
Sasuke
19
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 20th Nov 2013 12:58 Edited at: 20th Nov 2013 12:58
Link
Quote: "Sasuke, I believe that all your decorations are scrolling together? In that case i'd prefer non-ortogonal camera as you have neat decorations and i'd like to see them in a 2D perspective."


In 2d, things are positing by an offset of world position. By scaling the world position you can give it a 2d perspective or parallax. No different for orthogonal cam!

So like this just for the x axis:

Layer 0 = worldPosX
Layer 1 = worldPosX * 0.75
Layer 2 = worldPosX * 0.5

With this Layer 0 will stay with the camera, but others layers will move 25% less than the previous layer giving the illusion that some things on different layers are really far away.

"Get in the Van!" - Van B
Back to top
Profile PM Email
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 20th Nov 2013 14:48
Link
Oh. I did not thought

Back to top
Profile PM
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 20th Nov 2013 16:40 Edited at: 20th Nov 2013 17:03
Link
The best method for the way I work is always to have an atlas image and sprites that all use the same image. Really, it's more a tile sheet than an atlas, because there might be, say 64 images at 32x32, so no sub-image file, just an image then frame numbers.

So, for the map layout I'd just clone a sprite, set the frame, set the position (by offset), then let the viewport handle scrolling. That would let you just place the sprites and forget about them (maybe based on a map stored in a 2D array), and animated sprites could be set there and then, and I'd try my best to handle any actions based on collision, like the player hits one of those sprites, then decide what to do based on the sprite itself. That way, there would be no need for a recursive check. I mean usually you'd have to scan the sprites that are on the screen, check for collision, then decide what to do - what I suggest is just waiting on the player hitting a sprite then decide what to do, step through all the collisions and deal with it that way. I think this is a decent way to handle the physics stuff as well - because the sprites don't get shuffled around, they are created and put in place and left there until the next level - so off screen collisions would work fine with this, but a more froogle system might have problems.

Anyway, the main benefit is performance, even if your blistering fast PC can do it all and then some, well it won't be the same case on a tablet, or netbook, or anything else that you end up running your game on. For example, if you need 64 tiles for your game, and don't use an atlas/tilesheet - then every tile would be pretty much drawn separately - each individual image would be an individual draw call, the more draw calls the slower things are. By just having 2 images instead of 1, you end up using 2 draw calls, with 64 tiles you end up with up to 64 draw calls, and that doesn't take enemy sprites into consideration.

But, if you use a tile sheet, and set the sprites frame rather than it's image - animation is much easier, all the map sprites would draw with a single draw call, and no matter which way you look at it - 1 draw call is a lot better than 64 draw calls, but that might not be apparent on a high powered PC.


EDIT: Duh! - didn't realize this was DBPro... so the performance thing might not make a big difference, but it's still good practice I think - I much prefer to edit sprites all at the same time on the same image. I'm not 100% sure if there's a performance benefit with this in DBPro... I guess you might want to plan ahead, maybe try and gear yourself towards AppGameKit with new projects - because you might end up porting your stuff across to target other platforms.

I am the one who knocks...
Back to top
Profile PM Email
Sasuke
19
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 20th Nov 2013 17:44
Link
I wonder if you could use hlsl point sprites... hmm... testing must be done!

"Get in the Van!" - Van B
Back to top
Profile PM Email
mr Handy
17
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 20th Nov 2013 23:07 Edited at: 20th Nov 2013 23:11
Link
@Van B
Thanks!!! I have never thought that sprites with different images causing more draw calls!

Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2025-05-16 09:52:39
Your offset time is: 2025-05-16 09:52:39