Zelda 2 on Uzebox

[blue_knight]

*************Update************************************
I've released a teaser demo, for more information see the post near the end of the thread.

This is still a very early work in progress, no enemies or real gameplay yet.
Zelda2.hex

(Edit by Uze) .UZE file

zelda2.uze

(37.53 KiB) Downloaded 673 times

----------------------------------------------------------

I talked about this project in my introductory post already, but I decided to put up a small update and start a progress thread in the proper sub-forum. Some of this is copied from my original post, to keep it all in one place. Below that is my update.

The project - Zelda 2 remake/port on Uzebox. The idea is to mimic the original game as much as possible and then use the engine to build two additional Zelda 2 styles games (basically fan sequels) to form a Zelda 2 "trilogy."

On the NES title, the tiles are 2bpp where index 0 is the background color or transparency (if a sprite). Each tile is then assigned to a "CSet" which is part of a 16 color level palette (there are 5 CSets + 1 background color -> 5x3 colors + 1 background). Different levels can use different palettes and tiles can be assigned to different CSets in order to get a lot of re-use and variety. So in program memory, 512 tiles at 2bpp can be compressed to about 8Kb and each level can store a list of used tiles (and CSets) which can be decompressed into "video memory." So at runtime, the tile engine doesn't have to do paletted lookups but gets compressed at 2bpp in program memory. Since it only decompresses the necessary tiles for a given set of screens then the runtime memory usage is minimized.

Obviously I've just started out (a few hours total at most), so most of this is just planned at the moment. However I do have some stuff working, such as basic input, tile rendering (mode 3) - just decompressed 8 bit tiles right now, and part of the initial palace map built. I got some scrolling working, though I'm still having some issues there. Scrolling right works perfectly but I'm having some issues when scrolling left. Basically when I load columns for the left side, I seem to be loading the wrong data. From what I understand tiles are arranged in "vram" in a fixed 32x32 (or whatever v tiles is set to, 28 in my case I think), and when the scroll value is modified the visible "window" to these tiles is shifted and wraps. The ScrollX value wraps at 256, which is exactly the distance needed for 32 tiles in memory. So when the screen scrolls to the next tile boundary I calculate the column in vram to write to and write the next column of data from the master map array. For scrolling right this works perfectly and scrolling left is still acting funny. Anyway once this works I'll change the monolithic map to multiple maps and eventually include repeating patterns like Platz to save memory. Once scrolling is worked out, the next task will be to get the character to work properly.

Here is some very early test screenshots from the emulator, remember this is very early. On a few tiles have been made so far, I'm making them by hand at the moment. Click on the images to see full size.



After this I worked on getting sprites to work. I downloaded the beta5 code in order to make use of horizontal sprite flipping (a necessity for this project) as well as getting some animations working. So Link can turn left or right and plays a walking animation as he moves. Link takes 8 sprites, which is a lot, but I think I can implement many of the projectiles and enemies using tiles due to simple patterns and backgrounds (kind of like the platforms for Platz). In addition the number of complex multi-tile enemies on screen should be limited, though this will be a challenge to deal with.

Link sprite in action:


Any comments are welcome.

[paul]

On the NES title, the tiles are 2bpp where index 0 is the background color or transparency (if a sprite). Each tile is then assigned to a "CSet" which is part of a 16 color level palette (there are 5 CSets + 1 background color -> 5x3 colors + 1 background). Different levels can use different palettes and tiles can be assigned to different CSets in order to get a lot of re-use and variety. So in program memory, 512 tiles at 2bpp can be compressed to about 8Kb and each level can store a list of used tiles (and CSets) which can be decompressed into "video memory." So at runtime, the tile engine doesn't have to do paletted lookups but gets compressed at 2bpp in program memory. Since it only decompresses the necessary tiles for a given set of screens then the runtime memory usage is minimized.

That looks like an interesting approach. I hope the cycle limitation doesn't ruin your plans.

After this I worked on getting sprites to work. I downloaded the beta5 code in order to make use of horizontal sprite flipping (a necessity for this project) as well as getting some animations working. So Link can turn left or right and plays a walking animation as he moves. Link takes 8 sprites, which is a lot, but I think I can implement many of the projectiles and enemies using tiles due to simple patterns and backgrounds (kind of like the platforms for Platz).

Yes, that sprite flipping was quite a boon for mode 3. I wouldn't mind an option to reduce ram tile requirements by removing sprite overlays in mode 3. There's times when it's either not necessary (B.C. Dash) or when it's better to have more on screen at once. We might claw back a few extra cycles, too. I agree with using tiles for enemies and projectiles. Combining the two can make for very cheap enemies for certain situations (like the rotating cannons in Contra). However, tile-based projectiles have restricted movement patterns (unless you are willing to devote obscene amounts of flash to all possible tile positions), so they do not always suit well. Restricting movement to specific speeds can greatly reduce tile count. For games like space shooters, tile-based projectiles would be ideal (due to the fairly uniform background).

In addition the number of complex multi-tile enemies on screen should be limited, though this will be a challenge to deal with.

I haven't tackled a scrolling game with multiple sprite-based enemies, yet. Handling their positioning as they move on/off screen and when to delete them or run ai for them will likely be a challenge. I would like to see this functionality encapsulated in some kind of function set so that it's solved once and can then be ignored for those who do not wish to roll their own implementation. We will likely see one approach when Uze releases Lode Runner.

There's definitely benefit to reducing tile footprint (unlike carbon footprint - but I won't get into that ), so I hope your solution is workable. I've seen some pretty impressive 12-16 color palettes that really don't compromise very much, if you stick to a theme. However, if the '1284 is released (for cases where people stick to tilesets of size <=256), then this cost is a much smaller portion of available resources. It's still valuable as always, but your ram and cycle trade-off may become less rewarding.

Welcome and keep us posted on your progress. I've just returned from an unexpected holiday, so I'll get back into things.

[blue_knight]

That looks like an interesting approach. I hope the cycle limitation doesn't ruin your plans.

Most of the decompression happens when loading a new set of screens, so cycle count shouldn't be too much of an issue. Hopefully I can keep load times lower then the Famicom disk based version though. Dynamic tiles will require runtime decompression in some cases, but here we're only talking about a couple of tiles per frame at most.

I haven't tackled a scrolling game with multiple sprite-based enemies, yet. Handling their positioning as they move on/off screen and when to delete them or run ai for them will likely be a challenge. I would like to see this functionality encapsulated in some kind of function set so that it's solved once and can then be ignored for those who do not wish to roll their own implementation. We will likely see one approach when Uze releases Lode Runner.

I plan on building a "Zelda 2" engine for the 2 fan based games in the trilogy, I can certainly make this available to others who want to make sidescrolling action-adventure type games with large sprites.

There's definitely benefit to reducing tile footprint (unlike carbon footprint - but I won't get into that ), so I hope your solution is workable. I've seen some pretty impressive 12-16 color palettes that really don't compromise very much, if you stick to a theme. However, if the '1284 is released (for cases where people stick to tilesets of size <=256), then this cost is a much smaller portion of available resources. It's still valuable as always, but your ram and cycle trade-off may become less rewarding.

Fortunately I'm not compromising anything (except load times), this system will give me the same visual quality of the original NES game, which is what I'm after. Perhaps the '1284 will allow for better color depth or lower load times in the next two games though. For now though, half the flash space (or more depending on how much memory tile based enemies/animations take) for tiles - which is what it would take uncompressed - is just too much. And even still, I'd have to swap out colors or duplicate tiles, in which case I'd likely run out of memory just with tiles, to get the different level palettes working. Often times the same tile is used with different CSets and palettes to get a different look.

Welcome and keep us posted on your progress. I've just returned from an unexpected holiday, so I'll get back into things.

Thank you! I'll definitely keep updating this thread as more work is done on this. And thank you for the thoughtful discussion of my ideas, it's always good to have people sanity check your logic. Even if I ultimately disagree, I enjoy thoughtful discussions.

[blue_knight]

I resolved my scrolling issues, now the scrolling works perfectly.

I also implemented all the walking frames as well as the slight "bounce" in the walk. In addition I implemented the HUD using the mode 3 screen overlay. Next up I'll do the 4 way scrolling overworld map, which is the only top-down view in the game. At that point I'll implement collision and simple triggers and then start implementing some other sidescrolling areas with collision and jumping physics.

Anyway, some screenshots showing the hud and a few more tiles.

[nebososo]

I'm looking forward to this and it makes me wanna look at your code, sounds interesting, there might be a lot to learn from there.
I have only one suggestion:
Make the dialogs appear faster, I hate waiting for it when playing the original.

[uze6666]

Cool but...I want a HEX demo file!!!!

Uze

[blue_knight]

I'm looking forward to this and it makes me wanna look at your code, sounds interesting, there might be a lot to learn from there.
I have only one suggestion:
Make the dialogs appear faster, I hate waiting for it when playing the original.

I'll release the code once I'm far enough along. As for the dialog, I will certainly the text appear faster - that was annoying for me too. I'm also going to be fixing some other annoying things as well - critters that steal xp, starting all the way at the start with no xp when losing all your lives - instead it'll restart you at the beginning of the palace or nearest "safe place" (last town) and you'll keep your xp. Basically reduce the frustration factor so people can appreciate the game more.

Cool but...I want a HEX demo file!!!!

I'm going to put together a demo area and release the hex demo at that point. It'll include a few small caves, 1 town and part of the overworld map (and maybe the first palace). Once there is a game to play, that is. The demo will have collision, combat, leveling, a few items and 1 spell.

[paul]

Well, this really is a cool project. It's funny how infectious enthusiasm and results can be within these online communities - thanks for your input!

To frame my feedback: I tend to look at things from a higher level. I consider that Uze approaches things from a lower level due to his better understanding of the theory and kernel. Ultimately, as I devote time to learn more, I would like to approach things from this angle, as it appears far more flexible and rewarding.

Very nice work so far. I think you've captured the Uzebox interest spotlight

[blue_knight]

Before I move on, I've decided to quickly put together a tool to rip sprites from various images (gif, bmp, png, etc.) and build map files. I realized that if I continue to do things manually, this will take way too long. But I don't really want to wrestle with existing tools, especially since I can tune my own tools for this particular engine. Fortunately it won't take long to get the tool to a usable state, I'll save the polishing until later - I don't need too much.

Anyway I got tile ripping in so far, as you can see from these screenshots. The screens look slightly blurry for some reason, but the images are clear and unfiltered in the actual app. The tile colors are automatically converted to the proper color indices. The small rectangle is the 8x8 tile to rip, the zoomed view is that 8x8 region magnified to 256x256 for easy viewing. At some point there will be tools to recolor parts of the tile, such as filling in transparent pixels.



The maps will be made up of "meta-tiles", which are 2x2 tiles in size. These "meta-tiles" have some simple attributes, such as collision. The map then consists of a number of screens (up to 8), where each screen is 32x24 tiles or 16x12 meta-tiles. The map data will then be compressed, using a fast rle row based scheme and storing only unique rows (more on this later). Then on top of this there will be triggers (which may cause damage or be deadly, such as lava), teleports, spawn points for enemies and items.

[blue_knight]

Progress has been made on the editor, I'm almost to the point where I can get back to the game.

Any file can now be loaded to rip from. In addition you can now see the existing tiles and the new tiles being generated. If you hold CNTRL when you move the selection box, it moves from that spot in 8 pixel increments (in the original image space, really 16 since the image is shown at 2x zoom) which makes it really easy to extract tiles. In addition the tile set can be saved and is automatically loaded when running the program. The source data is stored at full color depth, but it'll also save out the code in with the appropriate color indices to be used for the game. You can see this in action here:
(remember you can click on an image to see it at full size)


In addition I started working on the meta-tile editor, since meta-tiles are used for building the maps. Each meta-tile consists of 2x2 tiles. You can see this here:

You'll set collision flags and other meta-tile specific data here. This data will get compressed when saving for the game, but by putting it here it makes building the maps easier for me.

I started on the map editing, I'll get that working next time.