{"assets":[],"author_link":"author\/fyberoptic\/","author_name":"FyberOptic","cat":"MiniLD","categories":["MiniLD"],"comments":[],"epoch":1403609580,"event":"","likes":7,"metadata":{"p_key":"82241","p_author":"FyberOptic","p_authorkey":"0","p_urlkey":"292973","p_title":"Little Hardware, Big Challenge","p_cat":"MiniLD","p_event":"LD29","p_time":"1403609580","p_likes":"7","p_comments":"0","p_status":"WAYBACK","us_key":null,"us_name":null,"us_username":null,"event_start":"1398384000","event_key":"22","event_name":"LD29"},"source_url":"2014\/06\/24\/little-hardware-big-challenge\/","text":"

This Mini-LD hasn\u2019t turned up as many entries so far as I expected, but given the challenge that it can be to program anything for some of these old platforms, I guess I can\u2019t be too surprised. \u00a0It actually makes me wonder how many people\u00a0thought<\/strong> they were going to participate, and then just gave up along the way. \u00a0I even hit one of those points myself.<\/p>\n

My game started out as something different altogether. \u00a0I had no idea what I was going to make before it started, I\u2019d only practiced blitting some tiles on the screen and trying to get a feel for the VGA hardware. \u00a0After the competition started, though, I got it into my head that I was going to do a Minecraft-ish style of game, since I\u00a0make mods for the real Minecraft, and have even experimented with my own voxel engine. \u00a0I could quickly envision what I had in mind, so I whipped up some simple graphics, and after a day or two I managed to have code together that could render tile-based cubes drawn in an oblique perspective.<\/p>\n

\u00a0<\/p>\n

\"\"<\/a>

Scrapped Mini-LD52 attempt<\/p><\/div>\n

\u00a0<\/p>\n

That mouse cursor you see could in fact click blocks and remove them from the grid, and the arrow keys panned all around. \u00a0But, there were a couple of problems.<\/p>\n

The first is the issue of depth. \u00a0You can already see in that picture, particularly around the bottom left, how when you delete blocks from the front-most rows that they tend to bleed right into the rows farther behind. \u00a0I tried to combat this by giving blocks a defined edge, but this actually didn\u2019t help; it just made the perceived depth bleed together two rows apart instead of one.<\/p>\n

The other problem was performance. \u00a0Each cube is four tiles. \u00a0The order that the tiles are drawn is also very important. \u00a0You have to draw the grid from back to front, bottom to top. \u00a0You can skip drawing tiles for blocks which have blocks around them, which does help performance. \u00a0But the issue is what to do when you change the structure. \u00a0If you delete just one block, then the entire thing has to be redrawn. \u00a0I tried to think of ways to avoid this, like making special tiles to represent blocks beside one another with already-connected surfaces drawn on them, so that I could potentially only draw onto the screen the parts that were changed (maybe). \u00a0But if I was to have multiple kinds of blocks, then I was going to need combination tiles of every possible combination. \u00a0And even if I had tiles like that, it wouldn\u2019t necessarily help at all if I were deleting blocks from deeper inside the structure.<\/p>\n

In other words, deleting a block caused a noticeable hiccup until the grid drew back in, and I\u2019m not really smart or patient enough to solve it!<\/p>\n

Eventually I decided it just wasn\u2019t practical. \u00a0And it was more of just a gimmick than an actual game, since I could have never had sprites moving through the terrain without more problems of dealing with depth and redrawing,\u00a0so I scrapped it. \u00a0Which sucked, because suddenly I had no ideas.<\/p>\n

On a side note, that mouse cursor is completely software-based. \u00a0When running in unchained VGA mode 13h, the standard mouse cursor is all messed up, still expecting a non-planar video memory arrangement. \u00a0So I\u2019m having to capture what\u2019s behind the cursor, draw it, then on the next frame, draw back the captured area to erase the cursor, capture the area of where the cursor moved to, then draw the cursor on the screen again. \u00a0So much work and processing just for something simple that we take for granted today!<\/p>\n

And in case you\u2019re wondering what I mean when I say \u201cunchained\u201d VGA, it basically means you\u2019re tweaking registers in the card, turning VGA mode 13h (320x200x256) from a nice mode where video memory is one byte per pixel and linear into a more difficult to program mode where each byte is every fourth pixel, forcing you to switch between planes of video memory to write to the ones in between. \u00a0 But this allows you to access all of the card\u2019s video memory for things like panning, scrolling, double-buffering, etc, as well as doing some tricks like fast blitting from the vram using the card\u2019s latches.<\/p>\n

I was going to write about how I did my final game, too, but perhaps I should save that for another post at this point!<\/p>\n

\u00a0<\/p>","time":"June 24th, 2014 11:33 am","title":"Little Hardware, Big Challenge","title_was_empty":false}