[Coco] Re: MINIHOG Demo Here Now!

[Chris Spry]

Thanks Robert.  BTW, I've already fixed the getting stuck on the wall bug,
it's the others that are giving me a hard time figuring out what's going on.
I know what's causing the ghost effect on scroll and it has to do with the
timing of the vertical retrace.  The closer it is to clearing and redrawing
mini AFTER the retrace (in time), the more likely you will get a ghost.  I
save the retrace for the scrolling, because if I don't the screen jitters
from time to time and it looks UGLY.  The ghost wasn't a problem actually,
until I programmed a sync to make the program run at a certain frame rate.
When the program runs faster than the sync, it halts until it reaches it and
then continues.  That's when the ghosting happens on the scroll.  I can't
place the undrawing and redrawing in any other parts or else you'll notice
(Mini will start blinking and you get bad sprite flicker).  I hope to come
up with something to solve this issue.

Anyway back to your comments.  Considered the SSP. More than once. Like the
idea, but that'd mean everyone who has MiniHog would need a SSP to hear
music and sound PLUS would need to have a modified one for high speed.  I
can't slow the program down any more for the SSP and would need it to
operate at high speed.  If I can't get the ideas that Roger has given me for
sound to work, this may be my alternate solution however.  I read over the
SSC specs and the buffer space it has to store programming info for the
sound is very minimal actually.  I wouldn't be able to fit an entire song in
there for a level.  However, on every sync it could feed the SSP more info
from memory and keep it going without a break.  Memory isn't an issue with
this program, it's getting all I can get out of the CPU without effecting
game performance.  I still have plenty of extra memory for music, levels,
etc, what have you.  It's why it requires 512k.  Right now the memory
outside the normal 128k is being used to store level and object information,
a screen dump for the pause, continue marker info and the music data.  It's
also used when preparing the level (converting the data to work with the
scroller routine). The 128k (really 64k) within is being used for the
program, the font and the sprite graphics.

Thanks for the support!

-Chris

----- Original Message ----- 
From: "Robert Emery" <theother_bob at yahoo.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Friday, July 30, 2004 2:34 PM
Subject: Re: [Coco] Re: MINIHOG Demo Here Now!


> --- Chris Spry <bugster at cedarcomm.com> wrote:
> > Yeah, that part isn't programmed yet (getting hurt and detecting when
you
> > fall off a cliff), so when that happens, funky stuff will happen since
the
> > coordinate values for mini are off the charts.  As for the music, that's
> > still being debated.  I will have sound effects for sure, but for music
> > that's where it gets hard since the CoCo doesn't have a separate chip
for it
> > (just a 6-bit DAC driven straight from the CPU).
>
> Hey Chris,
> consider doing the 3 voice music and maybe advanced sound effects via the
> Speech Pak. Normal SFX and less/no music without it. This would probably
> require a high-speed modified SSC, but that's a *very easy* fix.
>
> The SSC allows you to remove some load from the CPU and probably save
space in
> terms of stored music data, plus I think it would enhance your game in
> *novelty* terms too. SSC games are rare/lame.
>
> Your demo ROCKS by the way! I'm blown away already! Great work!
>
> Bob
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco