It's time to continue by revealing the little map editing tool I started creating, just for the purpose of testing textures and designing the first map. Of course it's a crude tool I made just for the occasion, I once made to give to the artist so that he can try a texture loaded as a PNG (designed with CPC palette in mind), size 32*32 or less. It was never planned to be the level editor then, just a testing tool, but it can be expanded in the future in a way so that I can add monsters/items near blocks and additional metadata per block for scripting events.
Right now, you can draw/erase with left/right button on the down left side on the map, while seeing the blocks appearing in realtime on the upper window where you move with arrows (it's a simulation of what you expect to see and play on the real CPC, but on an SDL window in Windows). On the down right side there is the texture, the mouse scroll wheel will go through four textures atm. These are stored in a folder named texture1/2/3/4.PNG. It's just not complete atm, no menu to edit the mirroring of the door (which is hard coded for one of the textures), but there is also a rule. If you upload a texture that is something like 16*16, it will tile normally over 32*32. If you upload something bigger, it will just use the upper left 32*32 block of the graphics. Also,. there is a simple search through colors for palettes closest to the CPC palette. If your PNG uses colors very similar to the CPC palette, it will use those. But throw an arbitrary texture inside the folder (like some 32*32 Minecraft textures I tried) and it will automatically try to do it's best to match CPC colors, although usually it will look like crap.
Btw,. in the screenshot you see the unused two frame bat enemy sprite plastered on the wall. I might try to use this one (but maybe with dark blue instead of black) for my sprite enemies. Some other good news is that I am finally investigating some code for zooming sprites so that we can finally have some meaningful items/enemies in the game (a lot of work has to be done for that, not just zooming sprites, but clipping and calculation of position and zoom factor based on the camera visibility). I was trying some bruteforce slow C code and while you will get 2-3fps when sprite is filling fullscreen (something that will not happen with most sprites, I had to zoom by 8 to get this) this is very slow C code and I am already thinking of a nifty assembly solution, with very small unroll codes, that by calculating cycles doesn't eat more than 1VBL for 3-4 partially zoomed entities. And usually there will be less on screen and smaller items that I will not allow very close zoom in an RPG style game (you will be blocked by such so you won't get too near). And I am already thinking of transparent texture walls (like iron bars and doors) in a way that they can be drawn correctly with sprites and rest of the walls. I have some good ways to solve these problems, I just need to finish coding them first and test.
There are more stuff I want to do writeups for:
- Texture repeat/packing/column offset engine and the cool things you can do with that.
- Raycasting math, optimizations and interpolation tricks.
- Wall rendering unroll codes explained.
- My ideas for zooming sprite and transparent walls.
The thing is, most of these stuff need more intricate shapes to be prepared and careful write up. So, I am not sure when the next one will be (but I want to cover some of these bigger cool stuff). Meanwhile I might write smaller stuff or little news of progress. And even if I don't for few weeks, this means I might have focused more time on working on the engine rather than writing about it. So, don't expect anything, maybe it will take one or two weeks for the next update. But things are going good and I am motivating myself and planning things ahead.