Puffweet dot com

RSS

Contact

Tag: sega

  • SMS Experiment, Day 18

    Since the last update, I’ve tried coming up with solutions on how to fix the glitchy sprite tiles when changing direction. The problem stems from me trying to copy too many tiles to VDP memory during vblank. The VDP tries to render the graphics while I’m still trying to copy memory and that causes conflicts. The friendly smspower folks suggested a “double buffered” solution where I’d copy the car’s tiles over two game frames. Copy half-ish of the car’s tiles on the first frame, then the rest on the second frame. When copying, put the tiles into a “back buffer”, i.e. an unused area of VDP memory while the active sprites use a different area. When the copy is done, make the sprite use the newly copied area and then next frame copy the tiles into the “old” area.

    Went with an ugly but working solution. In the gif above you can see the two areas in the VDP memory getting updated in alternate steps.

    The disadvantage of updating over two frames is that the animation will be updated at 30fps while the rest of the game runs at 60fps. But the physics can still run at 60fps and the new direction even if the sprite doesn’t reflect it exactly for one frame.

    Now that I think the prototype is in a decent working shape, I do believe I’ll be taking a break on this project for a bit.

  • SMS Experiment, Days 14 & 15

    Worked on importing the sprite graphics into the game prototype. Reused a lot of the animation/drawing code from my old Ninja Girl project.

    Once the graphics were imported, started on the actual driving around. It doesn’t feel like 16 directions is smooth enough. Rom space isn’t an issue so I can definitely try 32 directions.

    I don’t understand the sprite glitching at certain angles. I’ll have to investigate. Tomorrow, maybe.

    I’m easily hitting the map scrolling limits, which is expected. For racing to happen, tracks will have to be pretty long. I still haven’t thought about how I’ll pull that off. I want actual twists and turns, not like Enduro Racer where it just scrolls in one diagonal direction.

    Programmer art rendition:

    More pondering is needed.

  • SMS Experiment, Day 13

    Finished drawing the basic sixteen directions for the car. I put them all together in a rotating animation and it… doesn’t look that great.

    The car looks inconsistent from frame to frame which is wonderful. The car changes size and height. When I started was drawing the sprites by eyeballing them against the prerendered car but at the end I just started drawing overtop them.

    But version 1 is done so now I can start working on code. But I think a version 2 will be in order once I get some gameplay going. Next time I’ll stick much closer to the prerendered version.

  • SMS Experiment, Day 11

    (Man, I don’t even know where day 10 went)

    Not a big update. Created more graphics in Graphics Gale for the different directions of the main car sprite. Ten down, six to go. It’s slow going because the work is tedious and I’m lazy, but I’m starting to get more confidence in the car sprite making process. Hopefully I’ll have all sixteen directions done this week.

    The fun (read: not fun) thing about the Sega Master System is that it doesn’t have sprite mirroring like the NES does. So the game will need graphics for all sixteen directions. It does mean that I can make the graphics unique for all angles, though. So I can keep the #1 on the car door facing the right way.

  • SMS Experiment, Day 9

    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.

  • SMS Experiment, Day 8

    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.

  • SMS Experiment, Day 7


    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-rendered isometric (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.

    Experimentation continues!

  • SMS Experiment, Day 6

    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.

  • SMS Experiment, Day 5

    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.

    Pss: Hmm, I wonder if the maps can be compressed.

    (*)

  • SMS Experiment, Day 4

    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.

    (*) That’s what SHE said. (**)

    (**) sorry