Jump to content

Photo

The Legend of Tilda


68 replies to this topic

#51 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,104 posts

Posted Mon May 15, 2017 8:16 AM

I'm familiar with that site, a lot of good captures of graphics! It's not always complete though.

#52 PeteE OFFLINE  

PeteE

    Star Raider

  • Topic Starter
  • 54 posts
  • Location:Beaverton, OR

Posted Mon May 15, 2017 10:49 AM

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.



#53 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,104 posts

Posted Mon May 15, 2017 3:13 PM

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.



#54 PeteE OFFLINE  

PeteE

    Star Raider

  • Topic Starter
  • 54 posts
  • Location:Beaverton, OR

Posted Mon May 15, 2017 6:24 PM

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


#55 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,104 posts

Posted Mon May 15, 2017 7:42 PM

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



#56 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,358 posts
  • Location:Denmark

Posted Mon May 15, 2017 10:24 PM

FYI: the hybrid mode with 3 pattern tables and 1 color table doesn't have any issue with sprites. This only takes up 8K compared to 12K for full bitmap mode and you only have to duplicate the patterns - not the colors.



#57 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,104 posts

Posted Mon May 15, 2017 10:51 PM

I thought it wasn't possible to do one color table without reducing the number of patterns? Interesting...

#58 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,358 posts
  • Location:Denmark

Posted Mon May 15, 2017 11:01 PM

I thought it wasn't possible to do one color table without reducing the number of patterns? Interesting...

 

I have used this mode multiple times: Titanium, Bouncy, etc. Just set VR3 to >9F and VR4 to >03. 



#59 PeteE OFFLINE  

PeteE

    Star Raider

  • Topic Starter
  • 54 posts
  • Location:Beaverton, OR

Posted Sat May 20, 2017 12:36 AM

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.



#60 PeteE OFFLINE  

PeteE

    Star Raider

  • Topic Starter
  • 54 posts
  • Location:Beaverton, OR

Posted Sat May 20, 2017 11:47 PM

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?



#61 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,852 posts
  • Location:Denmark

Posted Sun May 21, 2017 2:37 AM

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, Sun May 21, 2017 2:38 AM.


#62 PeteE OFFLINE  

PeteE

    Star Raider

  • Topic Starter
  • 54 posts
  • Location:Beaverton, OR

Posted Sun May 21, 2017 9:49 AM

 

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.



#63 CZroe OFFLINE  

CZroe

    Chopper Commander

  • 220 posts
  • Location:Newnan, GA, USA

Posted Sun May 21, 2017 10:17 AM

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, Sun May 21, 2017 10:21 AM.


#64 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,157 posts
  • Location:Beaverton, OR

Posted Mon Jun 19, 2017 5:36 PM

I basically wire button a to player 1 fire, button b to player 2 fire.

Then other buttons to player 2 up, left, down, right.

-M@

#65 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,157 posts
  • Location:Beaverton, OR

Posted Mon Jun 19, 2017 5:42 PM

Sinphaltimous recently planned out and shared rewiring sega gamepads: 

 

There was a whole thread about it : http://atariage.com/...utton-gamepads/

 

The resulting design: http://atariage.com/...ject-available/

 

-M@



#66 PeteE OFFLINE  

PeteE

    Star Raider

  • Topic Starter
  • 54 posts
  • Location:Beaverton, OR

Posted Mon Jun 19, 2017 7:09 PM

Thanks Matt, I saw your image post in that thread which was exactly what I was looking for.

#67 courtesi96 OFFLINE  

courtesi96

    Star Raider

  • 91 posts

Posted Thu Jun 22, 2017 7:57 AM

Would this have been possible in Turbo Forth?



#68 PeteE OFFLINE  

PeteE

    Star Raider

  • Topic Starter
  • 54 posts
  • Location:Beaverton, OR

Posted Thu Jun 22, 2017 9:14 AM

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!



#69 PeteE OFFLINE  

PeteE

    Star Raider

  • Topic Starter
  • 54 posts
  • Location:Beaverton, OR

Posted Wed Jul 26, 2017 10:54 AM

Title screen :)

Attached Files






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users