Last week, I reported that I have a nicely animating set of walls that I can maneuver through.
I worked on the floor this past week.
Sprint 14: Pre-production and initialization
Planned and incomplete:
- Move player in dungeon view
I had one of my least productive weeks according to my records, at least in terms of hours put into game development. One of the hazards of being a very, very part-time indie game developer is that there are going to be times when my business can’t take priority and my time needs to be dedicated elsewhere.
That said, I made slow and steady progress on rendering the floor. I wish I had more to show for it by now, but unfortunately I don’t.
My code is based on libSDL2, and for the most part I have been able to make games by loading textures from existing images. For raycasting the floor, I wanted to create a blank texture and populate it each frame with pixel data based on the angle the player’s party would be facing.
I quickly added the wrapper code for the relevant SDL2 functions, such as SDL_CreateTexture() and SDL_LockTexture().
And then, since I have never used SDL_LockTexture() and SDL_UnlockTexture() before, I spent time trying to understand it.
In fact, I originally was trying to use SDL_UpdateTexture(), but the documentation made it clear that I shouldn’t use in my use case:
This is a fairly slow function, intended for use with static textures that do not change often.
If the texture is intended to be updated often, it is preferred to create the texture as streaming and use the locking functions referenced below.
Now SDL_LockTexture()’s signature threw me off. I’m not a C programmer, so there are some C idioms that I am not used to.
int SDL_LockTexture(SDL_Texture * texture, const SDL_Rect * rect, void **pixels, int *pitch);
I’ve seen void pointers before, but a pointer to void pointers? Weird.
The docs say that it is the pointer to the locked pixels. It also says it is write-only access, and it says you can’t rely on those pixels pointing to old pixel data.
It took me a bit to wrap my head around what all this means, especially because there was no example provided in the docs, but also because I rarely use functions with arguments that get populated as a side-effect and so I didn’t recognize how this function was supposed to be used.
Basically if you treat the concept of pixel data as an array of data, then the way you would use this function is to pass in a void ** pointer, and the function will set it to point to some pixel data. You can then manipulate that data however you want (most likely with memset), and then you can call SDL_UnlockTexture() when you’re done.
So conceptually I get it, but I wanted to test-drive its integration into my codebase, and unfortunately I ran into problems getting my HardwareLayer to use the SDL wrapper for SDL_LockTexture() due to Google Mock’s SetArgPointee() not really working well with pointers to void pointers.
I got compiler errors initially as tried to figure out how I should be calling it and with what arguments in my unit test, but I ended the week with runtime seg faults when I ran my tests, mainly due to SetArgPointee() according to the stack trace.
I imagine that if I was working on this project full-time that this issue would have been solved within a day or two of concentrated effort. I assume I’ll figure it out this week.
For now, enjoy this rendering of the floor using an uninitialized texture, which I think is kind of neat and surprisingly less noisy than I thought it would be:
Thanks for reading!
—
Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!