Jump to content
  • entries
    657
  • comments
    2,692
  • views
    898,045

Playable


SpiceWare

2,379 views

Animation routines aren't in place yet, but we now have a playable build.

 

I always liked the Stealth Mode, so I've added that back in. It's currently controlled by the Right Difficulty switch. When enabled, all robots will initially be visible for 1 second. After that any robot that shoots will be visible for 1/2 second. If a robot is destroyed, all remaining robots will be visible for 1/2 second.

 

In the Frenzy version you can shoot out the solid walls - this can be handy for creating an exit to the room. Flickering walls will eventually reflect the shots. Special Room objects are in place, though only the Big Otto room does anything extra (and it's extremely primitive in this build).

 

blogentry-3056-0-29090400-1391898875_thumb.png

  • RESET = start game
  • SELECT = return to "menu" (rainbow screen)
  • Left Joystick - move humanoid. Move to edge of room to trigger room change.
  • Left Difficulty, style: B = Berzerk Rooms, A = Frenzy Rooms
  • Right Difficulty, stealth Technology: B = Off, A = On

ROM

frantic_20140208.bin

frantic_20140208rnd.bin

 

Source

Frantic20140208.zip

Frantic20140208rnd.zip

12 Comments


Recommended Comments

Do you think you'll eventually be able to have a few different robot destruction animations that the program will be able to choose from using controlled randomness so it won't always have the same pattern?

Link to comment

Thanks!

 

Hadn't considered multiple explosions before. What's there is just something I'd whipped up as a placeholder due to switching the explosions from using 2 sprites to using a single 2X sized sprite :ponder:

 

If I leave it with 4 frames, and set up 2 different images of each frame, I should be able to randomly pick a frame which would result in 16 possible explosion sequences.

  • Like 1
Link to comment

New ROM and source added with revised explosion routines. For testing purposes I just rotated the existing graphics 180 degrees.

  • Like 1
Link to comment

Yep - that fancy explosion espire8 did was from after I dropped the speech routines due to the drop in ARM performance caused by disabling cache (done to work around the ARM bug that kept crashing the game). Eliminating all those digitized samples freed up a bunch of space that I reallocated for graphics so we could have more elaborate animation.

 

I'm planning to add back the speech routines as I learned a number of performance improvements while working on Space Rocks and Stay Frosty 2. One example was I'd been defining C variables using RAM that was allocated in the 6507 code like this:

#define FRAME (*(volatile unsigned char *)(0x40000C00 + 0x98 ))

 

By changing it to this the code runs significantly faster (and takes less ROM to boot!)

#define FRAME (*(unsigned char *)(0x40000C00 + 0x98 ))

 

I'd defined it using volatile as the original code from batari used it (this was back in 2010 when we were designing DPC+ after my DPC experiments) so I thought it was required. While working on Stay Frosty 2 GroovyBee figured out that we didn't need it, so I did a mass find/replace to delete all occurrences of volatile. That one change freed up over 1KB of ROM.

That fancy explosion took up 26 images, each 22 bytes high (572 bytes of ROM). The explosion was 13 frames in length and drawn by placing 2 sprites next to each other for the increased width. The current explosion has 8 frames, so it only needs 176 bytes of ROM.

 

The other issue with that explosion is the programming was more complex as I'd have to search for an unused sprite for the right side (the left side used the sprite that was drawing the robot) and then update 2 sprites for the explosion sequence. Eliminating that extra complexity helps to make sure I'll have CPU time left for the speech processing. Another issue with the 2-sprite explosions was it made the flicker noticeably worse - especially during chain-explosion sequence that would take out a cluster of robots.

Link to comment

Re: volatile

 

That is a weird behavior, I wouldn't have expected that adding the volatile keyword would've increased ROM size like that, especially since removing it didn't appear to have any effect. I wonder if this is just an issue with your particular compiler? It would be interesting to know what is going on here, since your original usage of volatile was appropriate (reading memory that could be changed outside of your code).

Link to comment

That's why it wasn't needed, Nothing else can change that RAM while my code is running.

 

Why it shrank ROM usage is easy, every time it was used it had to load a fresh copy from RAM, so it couldn't keep the value handy in a register.

Link to comment

The volatile keyword is typically used to flag variables / addresses which can be changed by something other than the CPU (i.e. shared RAM) or a variable / address where a read doesn't return the most recently written value (e.g. a memory-mapped PIA). It basically tells the compiler "you can't cache this value in a register, always read/write to RAM".

Link to comment

That's why it wasn't needed, Nothing else can change that RAM while my code is running.

 

Perhaps I misunderstood what you are doing here -- I thought this was a value that the 6507 code was possibly changing and you were reading it from the ARM side, which is exactly the sort of thing you need volatile for.

 

Are you sure you're not just getting lucky with the optimizer? Perhaps the loads are happening too infrequently for it to end up in a register long term and thats why you can leave it out without a problem. If this is something you read once per frame (haven't looked at the actual code in this case), you can probably get away with not having the volatile keyword.

Link to comment

Just like the ARM can't access the TIA chip, the 6507 can't access the ARM's RAM. To make changes in that RAM the 6507 makes a request to the ARM chip via the DPC+ registers.

 

When the ARM is emulating the DPC+ hardware, it's in a very tight loop that doesn't time for anything else. When the 6507 requests the ARM to run the game logic, it does so by writing a value to DPC+ register CALLFUNCTION. When this occurs, the ARM puts a NOP operation onto the cartridge's database, in order to idle the 6507, because the ARM can't emulation the DPC+ hardware while its running the game logic.

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