4/30/2024 0 Comments Sdl load png textureYou can enable RLE acceleration on the surface afterwards by calling: SDL_SetColorKey(image, SDL_RLEACCEL, image->format->colorkey) If the image format supports a transparent pixel, SDL will set the colorkey for the surface. You can inspect an SDL_Surface for its specifics, and use SDL_ConvertSurface to then migrate to any supported format. There are no guarantees about what format the new SDL_Surface data will be in many cases, SDL_image will attempt to supply a surface that exactly matches the provided image, but in others it might have to convert (either because the image is in a format that SDL doesn't directly support or because it's compressed data that could reasonably uncompress to various formats and SDL_image had to pick one). Use this if you plan to hand the data to something else or manipulate it further in code. RemarksĪn SDL_Surface is a buffer of pixels in memory accessible by the CPU. Returns a new SDL surface, or NULL on error. I'm sure I'm just making a silly Rust mistake here.SDL_Surface * IMG_Load( const char *file) Function Parameters fileĪ path on the filesystem to load an image from. This is exactly where I'm stuck - I don't seem to be able to. The TextureCreator methods take &self, so you can create multiple textures using it. What would the best, most idiomatic way of implementing something like this in Rust be? I'm sure there's a simple solution here, as I cannot imagine the rust-sdl2 crate is intended to work in this way, and as someone new to Rust I'm probably just missing something incredibly obvious. But this is not appropriate for my application - the rendering logic needs to be abstracted and encapsulated, both for architectural reasons and because SDL is unlikely to be the only rendering back-end. This seems to be the approach used in a lot of the examples online, which get away with being simple imperative programs. I appreciate this may be avoidable if the TextureCreator (and the entire SDL context) was created in main(), and was passed by itself rather than as part of a struct. Result.insert(String::from(name), texture) If this weren't here, the Renderer would be kidnapped by the HashMap Let texture = renderer.texture_creator.load_texture(path).expect("Could not load texture.") Here's a simplified version of the relevant code (which exists inside of a function that borrows renderer): let mut result = HashMap::new() I am able to work around this by using std::mem::transmute() in an unsafe block to create a new, unblocked Texture, but I appreciate I'm deliberately breaking the Rust ownership model in doing so. I assume the Renderer gets handed to the Texture and used to make the reference that the Texture needs to hold to the TextureCreator. Therefore, creating any single Texture takes ownership / borrows the Renderer, and locks rendering completely. However, the issue I run into is that when I load the first Texture into TextureHolder, it borrows the Renderer struct so it can use the TextureCreator contained therein, but it doesn't give it back. (I may, in the future, try using std::pin to work around this.) I understand I cannot have them in the same struct, as each Texture holds a reference to the TextureCreator, and having struct members refer to other parts of the same struct is not allowed in Rust. My current implementation is to have separate TextureHolder and Renderer structs, where the Renderer holds the SDL context itself (including the TextureCreator), and TextureHolder holds each Texture. A Texture is dropped if the TextureCreator goes out of scope. In rust-sdl2, a Texture is created using a TextureCreator, and must hold a reference to it. What I want is to have a struct to hold my textures. I've been able to kludge around it with some unsafe code, but I am hoping to learn the proper Rust way of dealing with this. I'm using the SDL2 bindings ( rust-sdl2) for a project in Rust, and being fairly new to Rust I've run into a bit of an ownership / borrow checker problem.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |