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