Actual progress today. This time I used the render of the rally car as a base to get the correct proportions when drawing the sprites by hand.
After working out the general shape I then worked on getting a decent paint job / livery on it. At this resolution it doesn’t look too bad.
It took me all day to get two angles done. I want 16 directions. Doing the up/down/left/right angles won’t be too bad as they’re flat but the in-between angles will probably kill me. It’s hard to get the sprites looking consistent in different angles.
In progress shots:
No AI here! All hand drawn pixels lovingly painted.
Today was my second attempt at trying to figure out a way to help create isometric sprites that can go in 360 degrees. After yesterday’s lack of success, I thought I’d just create the sprites by hand using images as reference. I couldn’t decide what type of rally car to go with so I went with the Lancia Delta because it’s pretty boxy. Boxy obviously meant it was going to be easier. But as you can see from my test attempts it wasn’t working. I couldn’t get the shaping right just doing it by eye. The spoiler wasn’t done too badly, though!
I was using the Enduro Racer bike sprite to get a feel of what the size of the sprite should be. Last night’s test cars were way too big. I think a sprite that’s six sprites across should be fine for all angles, and it leaves me room for effects sprites like dust and exhaust flames. I’d use a sprite flicker strategy to keep the car always visible.
With the manual method obviously not working I went back to using a 3D model but this time with the intention of using it as a base, not as the final result. I found this model of a Delta and took test isometric screenshots. Next time I’ll be drawing over it while hopefully keeping the shape correct.
Today was cleaning up the GSLib example code to remove the bits I didn’t need and to make the camera handling and sprite drawing more streamlined. Also added the background asset generation for GSLib as part of the build process.
But the big thing was experimenting with Blender to make pre-renderedisometric (actually dimetric) sprites. It’s been a while since I’ve used Blender and I have to admit I’ve never really liked using it. But hey, it’s free. I downloaded the latest version and setup a basic orthogonal camera and messed with its settings until the rendered shapes fit the tileset I drew.
I first rendered a cube and then a rectangular prism. The top of the rendered shapes fit the background tiles perfectly but the bottom didn’t, which was annoying.
But it was good enough. I figure I’ll have to manually fix things anyway. As long as I get a guideline.
The next step was to get an actual 3d model of something. I am not a 3D artist so I got nice nice rally car from SketchFab.
I rendered it in my test scene and got a reminder that I’m not a lighting artist either.
The colors came out super flat and it wasn’t any better when I imported it into a Graphics Gale imagine using the Sega Master System palette.
Yeah, I don’t think this is gonna work. I want vibrant colors and sharp lines. Pre-rendered graphics are too muddy and will require too much work from me. But maybe I be able to use it as a guide to draw overtop.
Only had a bit of time tonight (after updating the latest Downland article a million times) but I figured out why the player wasn’t moving around. There’s a metatilesMetaLUT table in the code that determines whether a given 16×16 pixel metatile is walkable or not. The table didn’t match the new background’s set of metatiles so I just changed all the entries in the table from 0 to 1 and now the player can go anywhere on the map.
Today I used GSLib’s UGT to export a new background and integrated it into my project. Baby steps!
At first UGT couldn’t run. The version of the tool packed in the original GSLib release uses JavaFX, which isn’t included in recent releases of Java. Fortunately there’s a fixed version by thatawesomeguy on smspower that uses Java Swing. Its GitHub page is found here. It worked out of the box and that’s the version I’m using. It also has a handy export all feature so you don’t have to export all the parts manually.
After I got that settled, I generated a large map, exported binary data from the tool, converted the data to banks and imported it into the project. When I ran it the first time I thought it wasn’t working correctly.
But it turns out I was trying to draw an area outside of the map I made. Whoops! The original demo map was 1024 x 1024 pixels and my test was about a quarter of the size. The game was originally configured to start from the bottom right corner and the new map didn’t have any data in that area. So it was using random yet repeating data from somewhere.
Now that I got that to work, I should try a bigger map! Let me try that right quick.
[…time passes…]
Does it work? The answer is… maybe. I tried a 2048 x 1152 map. The UGT export worked fine but converting to binary with devkitsms‘ assets2banks.exe tool gave me multiple banks of 16k data and I wasn’t ready to start messing around with managing multiple banks yet. Created a 1088 x 1152 map which fit into one bank and that ran successfully.
“Successfully” in the sense that yes the game ran, but it doesn’t actually scroll yet. The new map data doesn’t have the terrain collision setup for the player to walk on. Right now, everything is a solid impassible block.
Fixing that will be for next time.
Ps: You know, I think what’s likely is that the maximum size of the map is whatever that can fit into a 16k bank.
A light day today because I had to work late. With the GSLib example finally running I started looking up how to bring new data in. There’s a UGT tool that does just that. It doesn’t look bad at all. It even has support for the Tiled map editor, which is real nice. I still don’t know what the max limits a map can be, though. The example’s source bitmap is 1024 by 1024 pixels which is pretty impressive (*) but I wonder if it can go bigger.
Since getting the GSLib example running I’ve been trying to set up a project in my own style. I’m fussy and I’ve developed my way of working so whenever I try to adapt a project I always break it down to how I like it. It has the benefit of forcing me to learn how the project actually builds.
It wasn’t entirely smooth sailing because I kept hitting linker errors again. This time, it looked like this:
?ASlink-Warning-Undefined Global 'GSL_TileLookup' referenced by module 'GSLib' ?ASlink-Warning-Undefined Global 'GSL_PositionWindow' referenced by module 'GSLib' ?ASlink-Warning-Undefined Global 'GSL_ActiveDisplayRoutine' referenced by module 'GSLib' [...]
The linker couldn’t find labels inside the asm blocks of the functions inside GSLib.c. It was essentially complaining about GSLib.c not finding things in GSLib.c.
Turns out I had a --peep-asm flag in the makefile’s CFLAGS for the SDCC compiler and it didn’t gel well with GSLib.c. I couldn’t tell you where the flag came from. It was probably something I wanted to test a million years ago and the flag just hung around everytime I made a copy of the makefile.
As soon as I got that sorted setting up the rest of the project was straightforward. So now I’ve got the GSLib project building and running again, exactly the same as before except different.
Next step is to figure out how to get new assets into the example.
I kept hitting linker errors due to differences in calling conventions between the pre-built SMSLib and PSGLib libraries from devkitSMS and the GSLib code. A SMSPower forum user suggested building the libraries locally. Turns out that worked. So now I have a building and running GSLib example I can play around with.
I didn’t want to write my own scrolling code as my previous attempt wasn’t performant enough, so I’m looking forward to experimenting with it.
