Jump to content
  • entries
    657
  • comments
    2,699
  • views
    899,712

Speech prep finished


SpiceWare

1,605 views

I've freed up enough RAM so I'll be able to add back in the speech routines. Part of it was freed up by changing the sprite variables from INT (4 bytes) to UNSIGNED CHAR (1 byte). The routines can handle 24 sprites, and there are 9 different values stored for each sprite (such as X, Y, Image ID, Animation Frame, etc), so the original RAM usage was 864 bytes. After the change that only took 216 bytes. The rest was freed up by moving variables from the Display Data area into the Frequency table area (for speech I only need a few frequency table entries).

 

An issue with sprite corruption appeared after changing the variables to UNSIGNED CHAR. The problem occurred whenever a sprite had what used to be a negative value(just above the top of the screen) became a positive value (-1 is considered 255 when using UNSIGNED CHAR). In this screenshot, the humanoid had just shifted off the top of the screen. CHAR can be used as a signed value but then it's range would be -128 to 127, which isn't enough positive values to cover the screen. So I changed the Y to SHORT INT (2 bytes), which allows Y to be from -32768 to 32767. This increased the sprite data storage to 240 bytes(from 216).

blogentry-3056-0-81867400-1332612836.png

 

There is a tradeoff in switching from INTs to UNSIGNED CHARs(and SHORT INT). The ARM code's ROM usage increases. However, it only increased by 100 bytes. Additional ROM usage does mean extra code is in there, so the routines will most likely be slightly slower than before.

 

Originally sprites that were partially offscreen were not drawn at all, this was mostly noticeable when Otto would appear and disappear as he bounced at the top of the screen. I've updated the sprite driver to handle clipping at the top and bottom of the screen.

blogentry-3056-0-42436800-1332612582_thumb.png

 

I also made a few changes in how the Right Difficulty switch is used. Before setting it to A would fill the room with the maximum number of supported robots. It still does, but now it's only checked when you hit RESET instead of at the start of each room. Besides controlling the robot, it also disables the lives decrement logic in the Humanoid Died routines. This lets you play forever - I added that so it'll be easier to test for when screen jitter starts (so I'll be able to address performance issues). The score is now shown in red to let you know unlimited lives/max robots is in effect.

blogentry-3056-0-70830500-1332613165_thumb.png

 

Sprite animation routines have also been added back, with some limited animation.

 

ROM

frantic_20120324.bin

 

Source

Frantic20120324.zip

7 Comments


Recommended Comments

Thanks. They're not as fancy as they were before the reboot, but they do make it more interesting that static images sliding around.

 

Last night I spent reviewing the stand alone speech routine as it's been so long since I wrote it that I needed to remember how it worked. Tonight I'm going to add some on-screen info to get time info (ticks of TIM64T) on now long the current speech routines take after changing it to use MAM1( to prevent ARM crashes). After that I'll rewrite the routines to fill the audio buffer over multiple frames, hopefully so it'll take at most just 1 tick of TIM64T per frame.

 

Once that's done I'll migrate the routines back into Frantic. If that goes smoothly, I then want to figure out what Tjoppen's done with ADPCM. He said he was able to pack 2K of 4 bit samples down to just 512 bytes using 1-bit ADPCM encoder(there's also a 64 byte table, but I think I'd only need 1 table that's used by all samples, not table one per sample). I currently pack 2K down to 1K of bytes by storing 2 samples in 1 byte, so using ADPCM should let me almost double the number of samples I can use.

Link to comment

I don't know much about ADPCM, but compressing the speech down so much sounds impressive. If it works out, I'll be tempted to use speech in my own games :)

 

How much space is remaining now? It doesn't look like there is too much left to do, other than the title screen and a bit of polishing?

 

Chris

Link to comment

$1536 (5430) ARM/Speech/Graphics

$549 (1353) Bank 4

$24d (589) Bank 5

$0 Display Data RAM

$? Frequency

 

I currently have ASG spanning banks 0-3 plus half of bank 4. That can be adjusted as needed. No speech data is in there yet. The only animation graphics in there are the ones currently in use.

 

The latter half of bank 4 has the tables that point to the graphics (graphics can shift w/out affecting the C code, but the tables can't). I also plan to put the menu routines in there as I don't think they'll fit in bank 5 anymore.

 

Bank 5 probably has some extra space as there's a couple ALIGN 256s in there for the reposition kernels.

 

I can overlap the DD RAM with ROM data (bank "6" of the ROM holds the initial state of DD RAM). Variables (sprite data streams, 2K speech buffer, etc) get zeroed out during init, so they can be used to store samples, graphics, etc.

 

Likewise the Frequency data is 1K of RAM overlapped by 1K of ROM (first 1K of bank "7"). When using C the Frequency Data is only 512 bytes (the 2nd half is used for C run-time variables). I think I can use the full 1K of ROM for extra storage. I believe I've already used about half the 512 bytes of RAM, but don't have any diagnostic messages in there to tell me.

 

As for what's left:

  • menu, should go in fairly quickly as it just needs to be ported over from before the reboot.
  • Speech
  • logic for Special Room objects
  • I figured out how to do 2 channel sound + sampled speech, haven't implemented it yet. Basically whenever there's speech only 1 channel is used for sound but the rest of the time it can use the speech channel for sound effects
  • optimization (later levels jitter)
  • robot movement animation
  • smart missiles (I might drop this idea due to space and optimization)
  • I'm sure there's others :ponder:

Link to comment

Sounds good - I'm looking forward to seeing this completed. There have been far too many homebrew 7800 titles recently - we need to get the 2600 homebrew releases back on track :)

 

Chris

Link to comment

I'm planning to resume work Frantic sometime next month (April) as I'm a bit burned out on Atari projects due to Space Rocks, Chun-Li, and that other project.

Link to comment
Guest
Add a comment...

×   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...