On Feb 10, 7:54 pm, "Jason Burgon" <jayn...@[EMAIL PROTECTED]
> wrote:
> If you need 50 abstract methods for something that plays a music file to
> sound hardware, then you've got the design wrong. I would guess that
10-20
> might be required.
I'm imagining methods like this (per output device channel)
SetVolume
SetFrequency
SetInstrument
SetInstrumentEnvelope
SetInstrumentEOPlayBehavior {ie. looping, ping-pong, etc.}
....stuff like that. 50 is an exaggeration, but it's the principle I'm
thinking of.
> > I'm afraid it does on my target platform --
>
> Jim, programming is hard enough as it is, without tieing one arm and
both
> legs behind you back! ;-) The original IBM PC was crap even by the
standards
> of the day. My home-brew 1MB RAM, 3Mhz 6809 based computer could run
rings
> around one.
I'm not so sure about that, unless it takes your homebrew less than 4
cycles per memory fetch, which is the original IBM PC's only Achilles
heel. My 8088 may have been hog-tied with an 8-bit memory bus but
I've got 16-bit registers and a functional MUL/DIV ;-)
I am hesitant to mention my target platform early in the conversation,
because most people go "why bother with that pile of crap" and I never
get answers :-(
> (1) You're using the wrong compiler - As much as I love TP7/BP7, it does
not
> produce fast code.
That's why I use inline asm for the im****tant parts.
> (2) Why torture yourself by trying to get it to work on a 4.7MHz piece
of
> junk?
The challenge! Someone challenged me 4 years ago to play full-motion
color video with sound on it (4.77MHz 8088 with CGA) four years ago.
I met the challenge! You can see for yourself, along with the
presentation I gave that explains how it works and the thought
processes involved:
http://www.oldskool.org/pc/8088_Corruption
To be fair, this is also an entry in an informal programming contest.
But I am also doing it for fun, of course.
> If either:
>
> (1) The source TSong song data has a common format, or
> (2) The TSong can process the data into a standard format before sending
it
> off to the TPlayerDevice to get played,
>
> then the TSong can simply pass a pointer [and a few other things
possibly,
> such as its length] to the TPlayerDevice.Play method. The player can
then
> access the data directly - no calls required. In a multithreaded
> environment, the TSong would probably want locking somehow to prevent it
> being destroyed or its song data from being modified.
That is doable; thanks for the advice.
Okay, my last hurdle is something stupid that I can't find in the BP7
manuals: I have a field like this in my object:
TPlayer = object
notesHz[0..maxNotes*IBN] of word; {audible frequency of each note
plus all IBN intervals}
....
....where IBN is a const outside of the object. (It needs to be, since
the number of (I)ntervals (B)etween (N)otes is something that both the
song object needs, so it can validate effect input, and also the
player object, since it needs to set those intervals in Hz.) However,
the compiler is stopping on it with "Error 3: Unknown identifier.".
Why?? I can't add a const inside of an object, so does this mean
objects can't refer to constants?? I'm baffled by this.
I know I can get around it with something stupid, like getmem'ing the
memory for the table with only the space I need, and using an array
pointer that goes to 65535 or something, but that's really
inelegant... Any ideas?
|
