While I've resumed working w/ Weeble on this in his original thread, I'm keeping this thread updated as well as I make changes.
Also with V2.1 I've moved the various data tables needed outside of the sprite sheet, copied up from page 3 which is the one tiles are rendered into in-game, so all of the first two sprite pages are available for graphics as is the first two rows and change of page #2.
With V2.2 I've added the initial code for clipping regions, to avoid redrawing the entire screen every frame. This is a MASSIVE speedup, pushing CPU usage outside of screen-transition periods down to 5% CPU at 60fps in most cases. I'm working on a '16x16 bitfield' based solution that will instead re-render the screen in regions as small as 8x8 pixels per frame, allowing for multiple moving objects that way.
I've also cut the CPU used for baking the tile graphics in half from ~2.5 frames at 60fps to ~1.3 frames at 60fps with this release, while the token count and overall codesize has actually gone down.
Finally, the game picks a random room in the entire 16x16 grid to start you in, so you get different areas of the maze each time you restart the cart. So hit Ctrl+R a few times to see all the various biomes.
As a caveat I have removed the 'biome viewer' in this version for now, as I'm redesigning the interface to be a general-purpose editor for the maze itself, including setting biomes on the maze and editing individual biomes directly.
As of V2.3 I've integrated newer 'cavern generation' code that weeble came up with, to avoid blocking paths and allowing for much denser 'crazyness' to occur, as well as my 'context sensitive dithering' code which makes the transition tiles look much more alive and distinct now.
I'm working on some additional cavern smoothing functions to retain the 'crowded' feel without having quite so many dead side-passages at times, and adding a caching layer for the more expensive parts of the room-generation, to allow much of it to be generated in the background as you walk around a room to get to the next exit.
V2.4 adds a fourth unique room design for some biomes, one with much deeper, winding passages and a crowded feel.
V2.5 adds a MASSIVE speedup to the bake_tiles function by calculating the 'masked' tiles a full 32-bit row of 8 pixels at a time. So one fourth as many calculations in exchange for a bit of bit-shifting to load/save the values, but overall it's a HUGE win, including on token-count! Only 2814 tokens current! :D As a note, the masking colors are now 2/3, 4, 5, and 6/7, with values 0, 1, and all those above 7 MUST be avoided in the masks now.
As an interim release, V2.5-caching includes a further sped up tile-rendering codebase which is also moving some data from peek/poke memory to lua memory, taking up roughly 128k of the 1MB available with pre-rendering graphics tiles organized for faster rendering. This transition is freeing up enough speed that I am preparing to remove the 'biome' approach and allow direct per-maze-room assignment of walls, floors, and borders (including palettes) to simplify world painting. The trade-off is worlds will take ~768 bytes of sprite/map memory to store instead of ~512 bytes as they are now.
With V3.0 I've completely removed the concept of 'biomes' from the codebase; the walls, floors, borders, and their respective palette choice can be assigned fully independently per-room now. I've not yet modified the map to show off this feature, though as a side-effect screen-transitions are even faster now as the engine only generates those tiles which are absolutely required.
Also new is a full fledged built-in editor allowing you to modify the maze design with a realtime view of the room in question when customizing the palette/textures for each component. Note that editing the actual palettes used by the tiles is done by editing the lower-left corner (sprite tiles 240 and 241) with the upper row being palettes 0-15 and the lower row being palettes 16-31.
To access the editor go into the in-cartridge menu (P by default) and select the appropriate menu item; likewise to exit the editor choose to either discard or save changes in the menu.
I'm still working to improve the rendering system, but felt releasing this version with a fully functional editor built-in is a valid point where games could easily be made with this engine.
Impressive stuff! I feel pretty guilty for leaving you to puzzle out the code on its own. I'd vaguely intended to write a blog post explaining various little bits and pieces, like the "jigsaw-piece" technique that ensures that no room needs to have more than three biomes while still making sure that there's always a transition between adjacent biomes. (Basically, every room is like a jigsaw piece with a notch on two opposite sides and a peg on each remaining side. Each jigsaw piece is filled with its own biome, and since no piece ever has more than two notches, only two of the adjacent biomes can protrude into it.) Looks like you did impressively well on your own!
With all the space and CPU you've freed up and the fact you can edit the maze by hand I imagine you could make some pretty cool spaces by combining prefab rooms/room-pieces and more furniture/decoration. I really wanted to have a leaf-canopy/crystal overhangs/mesh-ceiling in some areas but didn't think it was possible, but it probably is now. My goal was always to try to make a simultaneously large but interesting space. I think you've opened up all sort of possibilities here.
BTW I know you've replaced most of the code now, but nevertheless let me know if you would like me to release my code under an MIT license. I like the CC BY-NC-SA 4.0 for experimenting and collaboration, but since you're actually making an engine for people to use I wouldn't have a problem with people selling their games on itch.io and stuff like that.
And just to answer your very valid questions here, I think once we have a solid engine and are done collaborating here on the forum, yes, I would very much like to relicense the resulting meta-cartridge under an MIT license, as while I'm good at engine design I know I'm middling at best at designing a full game world, especially when an engine such as this allows for something Zelda-sized so easily which is a LOT to design. :)
Yeah, last paragraph has it right.
//edit: Frankly I've thought you did something more clever like storing map data as strings so you can use the entirety of spritesheet, including shared areas and use top map data for static screens such as menus, etc.
Well you could easily convert the map data to a string stored in the game, the issue then is 'does it compress well?' though. I've found it's too easy to run out of string space; sometimes it's better to keep some data in the sprite/map regions instead.
The underlying game engine uses the normal 'map' based rendering for the playfield, including flags on the correct sprites to simplify collision handling.
The 'unique feature' list is actually:
- Generate lots of distinct mixtures of tiles including unique blends between the mixtures so things don't look as rigidly tied to the grid
- The shadowing effect to add further visual depth to the playfield.
- Map and tile-components are stored in a way that's very amenable to utilizing multiple carts to allow larger/multiple game worlds or more tiles/graphics.
It would be pretty trivial to move the 'maze' data up into pure-map space honestly, and yes you could actually render things from Lua memory instead of using map() calls as it does now if you wanted to keep 100% of the sprite graphics available for some reason.
This isn't meant to be 'showing off' like ElectricGryphon's various tech-demos do, this is meant to be a functional, usable (albeit basic) game engine for building games similar to Zelda 1, handling the hardest part (IMHO) of dealing with the large overworld map. With more room types (there's room for up to 64 unique right now, I'm only using 4) you could easily hard-code specific obstacle layouts inside that way.
Log in to post a comment