Hi everyone,
I want to share my point of view about new funcs in SDL2_image API.
I am thinking that everything is almost sweet, but I think there is a
missing thing in IMG_LoadTexture() and maybe sister funcs.
If the philosophy of this func is all about convenience (type
autodetection, file auto opening/closing), I think it should take an
extra arg of type SDL_Rect* to return the texture width and height…
because it is useful to know that almost every time.
I think that because I use many animated sprites (all frames stored in 1
texture) and, in this context, I am not passing NULL to SDL_RenderCopy()
src_rect argument. When we were talking about surfaces, we have direct
access to w&h information. Now, with textures, we have only
SDL_QueryTexture() with 2 int* args.
An example of load and render animated sprite with current API :
1 […]
2 int res;
3 SDL_Texture t1;
4 SDL_Rect sprite1_size;
5
6 t1=IMG_LoadTexture(renderer, “some_animated_sprite.png”);
7 if (t1==NULL) { / error handling and return / }
8 res=SDL_QueryTexture(t1,NULL,NULL,&(sprite1_size.w),&(sprite1_size.h));
9 if (res!=0) { / error handling and return / }
10 sprite1_size.x = 0; / This is boring 
/
11 sprite1_size.y = 0;
12
13 sprite1_frames = 8; / This value should came from resource file /
14 sprite1_size.h /= sprite1_frames; / All images are on 1 column in the texture file /
15
16 […]
17
18 int sprite1_currframe=0;
19 while(!mainloop_end) {
20 […]
21 SDL_Rect src,dst;
22 src = dst = sprite1_size; / This is handy /
23 / per-frame alterations */
24 src.y = sprite1_currframe * src.h;
25 dst.x = 10;
26 dst.y = 15;
27
28 SDL_RenderCopy(renderer, t1, &t1_src, &t1_dst);
29 […]
30 sprite1_currframe = (sprite1_currframe + 1) % sprite1_frames;
31 }
This code is minimalist and a real game have to use more data structures
and code modularity but, the concepts remains I think.
sprite1_size is usefull and handy at line 22. If the sprite1_size could
be used to receive the texture size directly from IMG_LoadTexture(), we
could remove lines from 8 to 12 in this example.
This is not big gain nor big API change, but maybe those sort of things
that are “smoothable” now will not be improvable for years when 2.0.0
will be released. (I hope it is not too late).
If this idea sounds good for this ML readers, I can fill a bug request.
Regards,
Ludovic Pouzenc