WIP clowns and balloons made with IntyBasic

[+DZ-Jay]

I'm afraid the AY-3-8914 doesn't have these discrete values.

 

The software envelopes for instruments are already provided by the music tracker included with IntyBASIC v0.9 and can be altered editing the intybasic_epilogue.asm file

 

The envelope feature is more useful to simulate other complicated instruments like harmonic, violin and trumpet, putting a high frequency with a sawtooth envelope in one channel along with mixing with at least other channel.

 

Technically the envelope can be emulated almost completely with software (except the higher frequencies)

 

For IntyBASIC is very useful because you can start the envelope and forget about it, you don't need to keep a counter to increase/decrease volume, for example, for explosion sounds, helicopter-style sounds, sea wave sounds, sirens, little effects, etc.

Hmm... I see that I did not make myself clear. Let me try again.

 

There is absolutely no reason why a high-level language like IntyBASIC must be just a thin veneer over the hardware complexities. In fact, this is anathema to a high level language.

 

Why not simulate envelope generators in software as part of the IntyBASIC sound sub-system?

 

That way you can offer discrete envelopes by channel, rather than having to depend on the limitations of the PSG.

 

I mentioned as an example Arnauld's tracker, which does this. I proposed that a similar envelope generator could be offered in IntyBASIC, in software, for sound effects.

 

dZ.

[+nanochess]

Hmm... I see that I did not make myself clear. Let me try again.

 

There is absolutely no reason why a high-level language like IntyBASIC must be just a thin veneer over the hardware complexities. In fact, this is anathema to a high level language.

 

Why not simulate envelope generators in software as part of the IntyBASIC sound sub-system?

 

That way you can offer discrete envelopes by channel, rather than having to depend on the limitations of the PSG.

 

I mentioned as an example Arnauld's tracker, which does this. I proposed that a similar envelope generator could be offered in IntyBASIC, in software, for sound effects.

 

dZ.

I see your point.

 

I've been severe about this in IntyBASIC, there are many beautiful things that can be done with software, but at the same time these use the scarce cycles of CP1610.

 

Also there are many beautiful things that could be useful only for one or two programmers, also I've refrained of implementing these.

 

I've preferred to keep the language simple "not so far of processor" instead of taking away control from programmer, this way you know that if you game is slow is because of your programming and not because the compiler is eating away important processor cycles with support routines seldom used.

 

At the end the language is fast enough so programmers can implement their own software envelopes.

[+cmart604]

Just for the record, I'd still really like to see this game come out, I think it would be a lot of fun to have this on the Inty. Just sayin.

[+DZ-Jay]

I see your point.

 

I've been severe about this in IntyBASIC, there are many beautiful things that can be done with software, but at the same time these use the scarce cycles of CP1610.

 

Also there are many beautiful things that could be useful only for one or two programmers, also I've refrained of implementing these.

 

I've preferred to keep the language simple "not so far of processor" instead of taking away control from programmer, this way you know that if you game is slow is because of your programming and not because the compiler is eating away important processor cycles with support routines seldom used.

 

At the end the language is fast enough so programmers can implement their own software envelopes.

 

I understand, and I try to keep the same balance of speed, flexibility, and extensibility in my own framework. However, consider that software envelopes are an optional feature: not something that needs to run continuously, taking precious cycles away when not in use.

 

 

If you don't think this is possible with software envelopes, that's fine.

As I build my own framework, I encounter the same decisions as you: do I really want to spend precious cycles and memory on this feature? If it is not a necessary feature, then I make sure it can be implemented in a way that will work for those who want it, but don't get in the way of those who don't. I think software envelopes are important enough for sound effects and music, since the hardware envelope generator does not support per-channel wave shaping.

 

In my opinion, IntyBASIC is a great and powerful tool, but for it to be truly useful and approachable to more people, it needs to encapsulate more functionality and provide more abstractions.

 

-dZ.

Edited October 20, 2014 by DZ-Jay

[freewheel]

I'm torn on this. One thing I absolutely adore about IntyBASIC is that it does feel pretty "close to the metal", at least performance-wise. I've run into a few (documented) oddities, like how using MUSIC statements severely limits your audio choices. But beyond that it doesn't feel like it has the overhead of a high level, or worse interpreted language (which of course it isn't). It's a nice and simple way to program ASM without actually worrying about ASM. It's the kind of HLL I dreamed of as a kid (and an adult), to be honest.

 

But it does lead to some required trickery when you want to get creative. A few fancy routines would be nice, but we'd want to make sure there are comments like "this is gonna KILL your cycles" or what have you. There's already substantial overhead from the basic included stuff (can't make a game under 3.5KB from what I can tell) but that's fine, ROM is cheap. But cycles are not Audio is definitely an area where some extra help could be nice. I'm finding it tricky to do what I want in audio without POKEs and such. I have no idea how to implement this in BASIC mind you.

[+DZ-Jay]

Just for the record, I am not proposing adding anything to IntyBASIC that will "kill your cycles." I think there are ways to implement high-level constructs and abstractions in optimized ways. This is the reason why they should be part of the language: to avoid having the programmer re-invent the wheel or implement a common feature too far removed from the metal itself.

 

-dZ.

[+nanochess]

I'm torn on this. One thing I absolutely adore about IntyBASIC is that it does feel pretty "close to the metal", at least performance-wise. I've run into a few (documented) oddities, like how using MUSIC statements severely limits your audio choices. But beyond that it doesn't feel like it has the overhead of a high level, or worse interpreted language (which of course it isn't). It's a nice and simple way to program ASM without actually worrying about ASM. It's the kind of HLL I dreamed of as a kid (and an adult), to be honest.

 

But it does lead to some required trickery when you want to get creative. A few fancy routines would be nice, but we'd want to make sure there are comments like "this is gonna KILL your cycles" or what have you. There's already substantial overhead from the basic included stuff (can't make a game under 3.5KB from what I can tell) but that's fine, ROM is cheap. But cycles are not Audio is definitely an area where some extra help could be nice. I'm finding it tricky to do what I want in audio without POKEs and such. I have no idea how to implement this in BASIC mind you.

 

Don't worry, the SOUND statement gives you full access to the PSG chip, you don't need pokes.

 

I'll try of course to do more things around sound. Though no promises.

 

Just for the record, I am not proposing adding anything to IntyBASIC that will "kill your cycles." I think there are ways to implement high-level constructs and abstractions in optimized ways. This is the reason why they should be part of the language: to avoid having the programmer re-invent the wheel or implement a common feature too far removed from the metal itself.

 

-dZ.

 

Perfectly understood. I'm pretty glad many people, including you, are writing programs and/or checking IntyBASIC capabilities.

 

And I really try to find ways to implement useful features that apply to these real world games as people knows, I've been improving IntyBASIC based on these efforts so thanks for every game, because almost every one got me a trigger for a new IntyBASIC feature.

 

BTW, please check my IntyBASIC v1.0 wish list http://atariage.com/forums/topic/230986-intybasic-compiler-v10-wish-list-and-contrib-dir/