Jump to content
IGNORED

The Legend of Tilda


PeteE

Recommended Posts

Yes, SpritersResource is a valuable site, but it doesn't have all the information. For example the Octorok has two sprite patterns of animation and switches between them every 6 frames. The fast Octorok moves 1 pixel every frame, while the slow Octorok moves 1 pixel every other frame.

Link to comment
Share on other sites

Are you thinking of staying in Graphics 1 mode for the entire game?

 

I'm actually thinking that may be a good idea... while the attraction of bitmap mode and full color graphics are there, there's some serious hurdles to solve.

 

Hybrid bitmap modes have the issue that they can only have eight sprites. (A seriously ANNOYING limitation.) This wasn't an issue for me with my CRPG, because I didn't intend on using more than 4-5 sprites at a time anyway. But this game makes heavy use of sprites. Sprite rotation into the top 8 positions could solve that but it would definitely make it flicker-heavy.

 

Full bitmap mode gives you full sprite usage, but it means you may have to juggle your onscreen graphics and sprite graphics together in a tight space, rather than have a free 2K of space for sprites. You may have to keep 99% of your graphics in ROM memory and re-load them to VDP each time. Instead of having all the monster frames in VDP, you'd just have "Monster #1" in this slot, and upload a full 32 bytes of graphics data to change his animation frame at a time.

Link to comment
Share on other sites

Graphics mode 1 is working out pretty well so far, I don't see a need to change it. Full bitmap mode would dedicate too much VDP ram to character patterns I think.

 

Having only 8 sprites available in hybrid bitmap mode would be too limiting. Currently I'm using 2 sprites for the hero, 4 sprites in the status bar (map dot, two items, half-heart), 2 for the sword, and the remaining are dynamically allocated to enemies, pick-ups and projectiles.

 

The pattern table is also pretty tight. Since 16x16 sprite mode is active, there are 64 sprite pattern slots available. I'm already juggling patterns in the pattern table: the first 8 are the hero sprites for walking and attack and are reloaded when the hero changes direction. The next 20 patterns are available to enemies, which are dynamically loaded from a pool of 48 based on which type of enemies are present on the current screen. The rest are items, or projectiles that can be used by either the hero or enemies. Actually here's the comments from the code:

; Sprite patterns (16x16 pixels, total of 64) (four per line, 4*8 bytes per sprite)
; 0x Link (fg and outline, 2 frame animation)  (replaced when changing direction)
; 1x Link Attack (fg and outline)   Wand (same direction), Stepladder/Raft(as needed)
; 2x reserved for enemies (moblin 1-4, pulsing ground 1-2, peahat 1-2, ghini 1-4
; 3x reserved for enemies (moblin 5-8, leever 1-3, tektite 1-2, rock 1-2
; 4x reserved for enemies (octorok 1-4, lynel 1-4,
; 5x reserved for enemies (octorok 5-8, lynel 5-8,
; 6x reserved for enemies (octorok bullet, zora 1-2, zora bullet, armos 1-4
; 7x Sword N,S,E,W
; 8x Sword projectile pop
; 9x Boomerang N,S,E,W
; Ax Arrow N,S,E,W
; Bx Magic N,S,E,W
; Cx rupee, bomb, heart, key
; Dx cloud puff (3 frames), spark (arrow hitting edge of screen)
; Ex map dot, half-heart (status bar), disappearing enemy (2 frames)
; Fx Flame (1 frame pattern-animated) Fairy (1 frame pattern-animated), secondary item, clock
Link to comment
Share on other sites

Yeah, the only way bitmap would work is to overlay the sprite patterns over the character table. Or have them completely overlap the top of VDP RAM, from >3800 on. That means you would have to restore file buffer space if you need to use the disk drive.

 

Actually... that isn't a bad idea. If you aren't using disk files with a cartridge format, you can use the top 2K for sprite patterns! :) If you NEED to use it to, for example, save a game file, you could temporarily use the area and just restore the file buffer's data at that point.

 

The biggest pain points with bitmap are:

 

1) Storing color data along with pattern data. Fortunately, memory isn't as much of an issue

2) Doing rapid color changes (like flashes) is harder. It can be done but it's likely you'll see the wipe effect on screen

3) Assuming you just want the 256 patterns, you'd have to replicate the data in three places when you swap out sets

Link to comment
Share on other sites

I had a private message asking how certain things in Tilda work. Since it doesn't use the 32k expansion, assembly code and graphics data exist in the ROM and data gets copied to/from the VDP RAM as needed. The cartridge ROM uses 4 banks:
Bank 0 is for the main program (initialization, hero control, enemy AI, hero and item sprite patterns, etc)
Bank 1 is for music, sounds, and enemy sprite patterns
Bank 2 is for the overworld (decompress level data, scroll in directions, get door locations, spawn enemies)
Bank 3 will be for dungeons

Each bank has some common code at the start: the cartridge header, bank-switching function, useful functions for VDP read and write, vsync function, and music playing function. The cartridge header needs to be in each bank since the cart may start up with a random bank selected, so the very first thing done is a switch to bank 0. Bank 0 has code that initializes the VDP registers, loads the character patterns, color table, sprite patterns, and then switches to bank 1 to load the music. Bank 1 copies the music bytes to VDP RAM, and then goes back to bank 0. Bank 0 switches to bank 2 to load the screen. The bank 2 code looks at the location on the map, draws the specified screen in the VDP RAM and then scrolls it into view. Each screen has a list of enemies, and an object array is filled with the correct number of type of each enemy. Bank 2 always returns to bank 0. The bank 0 main loop goes through the array of moving objects, and calls a unique function for its type which modifies its sprite. The hero is controlled by reading the keyboard or joystick and moves the hero sprites around. The character patterns are arranged so that passable tiles are less than >80, otherwise they are solid tiles. As the hero reaches the screen edge, the map location is updated, switching to bank 2 to load the next screen, and return to bank 0. Next the main loop waits for the VSync interrupt so that the frame rate is locked to 60Hz (or 50Hz on PAL) and finally plays some music bytes before going back to the start of the loop.

The 256 byte CPU RAM holds workspace registers, global variables, a 32-byte buffer used for scrolling horizontal strips of the screen, and the array of moving objects for each sprite.

I've been meaning to share more progress as I go, and I hope this gives some insight into the internals - please feel free to ask more questions.

  • Like 6
Link to comment
Share on other sites

Tilda is going to need multiple joystick buttons for the sword, secondary item and menu. Question for those of you with multi-button controllers: what joystick 2 actions do you map the other buttons to? Should I make it possible to configure the joystick buttons?

  • Like 2
Link to comment
Share on other sites

Tilda is going to need multiple joystick buttons for the sword, secondary item and menu. Question for those of you with multi-button controllers: what joystick 2 actions do you map the other buttons to? Should I make it possible to configure the joystick buttons?

 

Since you've very elegantly stuck with the original bare console, I think it would be nice for a keyboard only option also. Personally I avoid the somewhat awkward ESDX and go for WASD and/or IJKL. Hope you would consider this. :)

Edited by sometimes99er
  • Like 1
Link to comment
Share on other sites

 

Since you've very elegantly stuck with the original bare console, I think it would be nice for a keyboard only option also. Personally I avoid the somewhat awkward ESDX and go for WASD and/or IJKL. Hope you would consider this. :)

Oh yes, absolutely! The current keyboard controls are WASD to move and Enter for sword. Thinking of using ';' for item, and '/' for menu, unless you have a better suggestion.

 

However, I saw Airshack using a Genesis controller and JediMatt2 using a NeoGeo controller at Fest West 2017 - I'm curious how they were wired up.

  • Like 1
Link to comment
Share on other sites

Oh yes, absolutely! The current keyboard controls are WASD to move and Enter for sword. Thinking of using ';' for item, and '/' for menu, unless you have a better suggestion.

 

However, I saw Airshack using a Genesis controller and JediMatt2 using a NeoGeo controller at Fest West 2017 - I'm curious how they were wired up.

Genesis controllers are already compatible with Atari CX40 Atari joysticks, though only one button of course. If the 7800 ProLine and CX78 controllers can work with two buttons for the TI-99/4A then there are multiple guides on YouTube and elsewhere for wiring NES and Sega Genesis controllers for use with Atari 7800. I know that both buttons somehow trigger the 2600's single fire button when used with a 2600 while somehow remaining discrete for 7800 games.

 

If it's not possible to discern between the buttons the same way the 7800 does then perhaps making impossible directional combinations triggered by an extra button could work... like Fire button is for sword, simultaneous up/down is for secondary item, simultaneous left/right is for menu. If you have to wire a controller anyway, it seems relatively easy to wire up extra switches/buttons to trigger simultaneous directional inputs with some DPDT switches.

Edited by CZroe
Link to comment
Share on other sites

  • 5 weeks later...

Would this have been possible in Turbo Forth?

I haven't dabbled in Turbo Forth at all, only have read the Forth threads on this site, so I can't really answer that... as long as Turbo Forth allows programming the VDP at a very low level, it should be possible. My goal in this project was to learn 9900 assembly, and I think I've accomplished that, so maybe it is time to learn Forth now. :) There are so many ways to get sidetracked!

Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...

Ok, time for a playable update. Combat mechanics are done, title screen and game over are added. You start with 3 hearts out of 5, fill the heart meter to use the sword beam. Tektite AI isn't done yet, so you can use them for easy loot. The unfinished menu screen can be accessed with '/' (forward slash) 'Q' key, J2Right or J2Up. Movement is still WASD or Joystick 1, and sword is Enter key, J1Fire or J2Left.

 

- Enemies have HP, and some take multiple sword hits, getting knocked back.

- Secret caves are now hidden, though without bombs or the candle, no way to open them yet.

- The overworld map compression is better, and screen palettes are changed correctly.

- The cartridge file is now called "tilda_8.bin", to no longer be confused with the TI game "Legends"

 

Have fun!

tilda_8.bin

tilda.rpk

  • Like 11
Link to comment
Share on other sites

Hmm, when I brought it up in Classic99, it loads the first screen but if I move any direction but down it scrolls up the menu screen and then locks up. Anyone else experiencing that?

 

UPDATE: Nevermind, figured it out. The joystick #2 was also configured to PC keyboard, which meant it was sending double inputs and causing some hijinks.

Link to comment
Share on other sites

Please excuse my use of 6-character identifiers and the CAPITAL coding style (the 99/4a is old, you need to shout at it)

 

No need to be sorry, as far as I am concerned; I keep coding in this way because I'm using the classic assembler in E/A and TASM on the Geneve.

  • Like 1
Link to comment
Share on other sites

 

Please excuse my use of 6-character identifiers and the CAPITAL coding style (the 99/4a is old, you need to shout at it)

 

Looks good to me ;) I follow the same convention by choice - code is in all CAPS and comments are primarily lower case. The Geneve tools allow for long labels, so when I migrated TIMXT code to the PC, xas/xdt long label extension was important to me :) I tried the color templates for a few editors and found that I prefer monochrome over the busy colors.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...