Sprite

[552020]

https://en.wikipedia.org/wiki/Sprite_(computer_graphics)

The term was derived from the fact that sprites "float" on top of the background image without overwriting it, much like a ghost or mythological sprite.
Sprite ideas:

• A butterfly flying around
• A sprite can rolling around or flying (redbull-like) around

[lmangall]

You want to add some ?

[552020]

Eventually one sprite for bonus’ sake, they say just 'animated sprite'. It would be funny to have just an animated sprite completely off of the 'rules' of the map. 'Off' in the sense that it is expected that the sprite 'behaves' in a meaningful way in our cub3D world, respecting perspective and moving only in the empty spaces. But if they are too lazy to specify this as requirement, we can also be lazy in our implementation. I did a quick research in the internet, since I was remembering that the principle stating to avoid overengineering and adhere to the specifications has a precise name. I could find only this: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it. Funny thing, in the article there is also a citation by John Carmack. So it would be a design choice.

What do you think?

Bonus list:
• Wall collisions.
• A minimap system.
• Doors which can open and close.
• animated sprite.
• Rotate the point of view with the mouse.

[lmangall]

Haha, finding the article about YAGNI is great, the John Carmack citation is the cherry on top.

Honnestly I don't fully understand how we would implement it.
If we want to :
have a series of transparent background png that put one after the other would create an animation
I think it is doable.

[552020]

Yes a series of transparent background pngs put after one other sa you said. I've never done a real animation (in so_long I was changing the png of the player depending on the direction) so I don't know exactly how to do it. But I imagine it will be a loop with some counter or usleep going on cause you don't want the pngs to change for every frame, which would be too fast chanding the pngs. For every direction there should be more than 1 pngs and this sprite could move randomly. For me also without scaling and caring about the walls ...

[lmangall]

That's my point, if it's just changing the image then is it a sprite ?

I found that:
https://pulgamecanica.herokuapp.com/posts/mlx-animations

also from here

for the sprite animation, I alternate between two images at a given frequency. This frequency is determined using a gameloop-count and a speed variable. Every loop, I check if the result of gameloop-count % speed is over or under half the speed. One image or the other is shown respectively

In the MLX official documentation they call "sprite" a texture ...

[552020]

1. Question

That's my point, if it's just changing the image then is it a sprite ?

This is what Wikipedia says:

In computer graphics, a sprite is a two-dimensional bitmap that is integrated into a larger scene, most often in a 2D video game. Originally, the term sprite referred to fixed-sized objects composited together, by hardware, with a background.[1] Use of the term has since become more general.

So a sprite is a something as a part of a scene. What do you mean exactly if it's just 'changing' the image is it a sprite? A normal sprite is like a bunny of a field, or the coins a player needs to collect. I guess it is something like a entity in graphical environment.

2. Pulgamecanica

"A sprite is an image which contains a collection of other images, which all together compose an animation. [...] Sprites might contain one or more animation."

There is a lot of code in this tutorial. It could be interesting, maybe to let it run with MLX42. I opened an issue for myself.

3. The so_long tutorial is interesting but he uses images in this strange format, but yes we can use it as an inspiration. So it's a loop with some counter, it could have been another way.

4. MLX42

Besides the right interpretation of what a real sprite is, and the German Wiki article makes interesting distinctions about it (https://de.wikipedia.org/wiki/Sprite_(Computergrafik)) I guess that it's clear what they want: some kind of 'moving' object in the 'game'. A sprite in the maze could be just a coin on the floor, an animated sprite, a constantly flipping coin.

[lmangall]

What I mean is I don't know if we have to use a special kind of sprite/image which, as one file, contains several images that together constitute the sprtite/animation OR just a few images that we show in a sequence.

he uses images in this strange format

indeed : https://github.com/liz753/so_long/blob/main/assets/pi_e.xpm42
That's crazy, it seems like he uses some kind of parser really similar to our map, with color codes for each pixel given in the map

I think that in our case the most important thing is that the orientation of the sprite follows the player and that the background is transparent. As you wrote it probably doesn't even needs to be animated.

So it's only about the orientation, do you agree ?

[552020]

What I mean is I don't know if we have to use a special kind of sprite/image which, as one file, contains several images that together constitute the sprtite/animation OR just a few images that we show in a sequence.

You can do it the way you pr

efer, it doesn't matter. You can have like just 1 sheet with multiple images and just render a part of this sheet, like moving around the sheet. Let me think through: you would import your sprite sheet as png as texture, and then you need to know for sure how many pixels is the image of the single sprite, and how many pixel is the padding between one image in the next and then you would render, i.e. copy to the image only the part of the texture you are interested in. I mean. From the texture with the whole sprite sheet you can create an image with the all the sprites on the sprite sheet or I guess already divide the texture in multiple images. But I'm not sure if we can selectively transform a texture in an image.

That's crazy, it seems like he uses some kind of parser really similar to our map, with color codes for each pixel given in the map

A lot of projects use this format. With MinLibX is the only allowed format I guess.

I think that in our case the most important thing is that the orientation of the sprite follows the player and that the background is transparent. As you wrote it probably doesn't even needs to be animated.

That it doesn't need to be animated is the only thing I didn't wrote. I mean if this sprite needs to get us the bonus it needs to be animated. This is the bonus list:

Bonus list:
• Wall collisions.
• A minimap system.
• Doors which can open and close.
• animated sprite.
• Rotate the point of view with the mouse.

What do you mean by saying that the orientation of the sprite follows the player? You probably mean that the player needs to see it always 'frontally' right? In Wolfenstein 3D the charecters, like the enemy I guess comes always frontally, they are not 3D but like a wall, they have just two dimensions. So if you mean this then yes. To have side views of a sprite, we would need extra sprites for these side view. Like if you think of a butterfly which could not only flap the wings but also rotate on itself then we would need extra sprites I guess for this 3/4 or later view. But I don't know. We always have the frontal view the image we have is always the frontal view and our problem is more to fake the perspective. I don't know if this answer your question cause I have also a lot of doubts ...

[lmangall]

Alright for the animation

Yes, I meant that the player sees the front of the sprite, therefore the sprite orientation "follows" the player.

[lmangall]

I started working on it in leo/sprite, I didn't do much before getting stuck with MLX basics...

• hardcoded a "2" in the map (after parsing)
• made a blue square representation of the "2"
• failed attempts to use load_sprite
  (ended up using load_textures)
• failed attempts at putting a texture at a fixed distance
  (failed with mlx_put_pixel and mlx_texture_to_image)

It helped me understood that the difficulties will be how to hide it "behind" walls. WIll we be able to use the existing code to do so ?

it will have to be :

• (partially) hidden by walls
  so rendered ray by ray in the raycasting loop or after the loop, on top
• scaled depending on distance with "on the floor" appearance

I think the animation is a second separated step that will be easier to implement (some kind of counter that replace the texture)

If you want to take it over go ahead

[552020]

What is your idea exactly? Which kind of sprite do you want to create? And do you want that the sprite 'behaves' in the the cub3D world, following perspective and appearing only on empty spaces?

I'll first finish the refactoring of the refactor draw_pixel #164 . I don't know how much time it will take.

[lmangall]

What is your idea exactly? Which kind of sprite do you want to create?

The graphic part is not a problem so I didn't thought aout it yet

And do you want that the sprite 'behaves' in the the cub3D world, following perspective and appearing only on empty spaces?

Yes I think this is the mandatory

[552020]

Yes I think this is the mandatory

And why did you think that? It seems to me as you didn't remember that we discussed already yesterday about this quite extensively.

But I can copy (again) the requirements in the subject about the bonus. This is exactly what is written in the bonus part of the subject. It's not my summarization of it. I can make also a screenshot so you don't need to look at the file.

Bonus list:
• Wall collisions.
• A minimap system.
• Doors which can open and close.
• animated sprite.
• Rotate the point of view with the mouse.

[lmangall]

Then I don't know what do you mean, how could it not Follow perspective ? By having a fixed size ?
And how could it not appear only in empty space : "space" is either a wall or an empty space, isn't it ?

[552020]

Then I don't know what do you mean, how could it not Follow perspective ? By having a fixed size ?

Yes. It would be a sprite and it would be animated.

And how could it not appear only in empty space : "space" is either a wall or an empty space, isn't it ?

The sprite would just not care. You can just let it move randomly through the image/window 'more than through the map'. It doesn't need to be something on the map.

[lmangall]

Ah, I think we misunderstood on one thing: movement an animation.
I did not thought about making it move, but just animating it (rendering several textures in place)

[552020]

Ah, ok. This would be also an animation. Therefore I was asking what you have in mind as animation. Having something animated in place would me simpler. I could be a vase of flowers swaying in the wind or a flag (a white flag) maybe, since we have this 'states' theme.

Coming to the technical realization if you don't want to use the 'cheat' card the-subject-is-vague, this extra object could be considered like a wall, but if the ray encounters it, it should first continue, render the wall behind and then render the object on the top, so that the sprite would be rendered on the top of the wall. If a ray encounters a wall before (if the sprite is behind a wall) it doesn't continue and render the wall which is fine. This technique would be also interesting to show multiple layer of walls if we have transparent textures like the ones with the ok woman.

A problem I noticed in other cub3d rendering animated textures is that they are going 'into the walls', like half visible and half not visible, being the sprite not behind the wall but only near the wall. This is probably caused by the frontal representation of the sprite, made without adjustment. But I'm still fuzzy on it.

[lmangall]

his extra object could be considered like a wall, but if the ray encounters it, it should first continue, render the wall behind and then render the object on the top, so that the sprite would be rendered on the top of the wall.

It seems like a really good approach, also it could use the functions we already have or a lightly modified version of it

[552020]

Do you/we want to add these animated sprites? I mean for the eval?

[lmangall]

Tbh I am still undecided, on my side it is:
Rather no, unless it's easy and fast (24h?)