bB wish list

[RevEng]

8 minutes ago, splendidnut said:

So this DPC+ thing would be "somewhat" reasonable then? 

 

You could require the user to prefix the DPC+ variable access with "DPC->" or something similar.

 

Sure, but you're doing that to tell the user that they should avoid using it except whenever absolutely necessary, at which point it's lost utility over the stack functions. In that case the abstraction only serves to fool the coder into thinking accessing DPC->variables is the exact same as regular variables.

 

[+splendidnut]

I have no horse in this race.  I'm just going along with the idea that some users are asking for a different abstraction to access extra "RAM".  Yes, at the end of the day, DPC+ ram access mainly works best/fastest when treated like a queue/stack.  And that's probably the best abstraction to use for accessing it.  But, it's always nice to have other abstractions available too.  The whole point of using any language other than Assembly language is for the abstractions they provide. 

 

Addendum:

 

I'm mainly here, because I enjoy these kinds of discussions.

[Mr SQL]

37 minutes ago, splendidnut said:

Actually, you can take advantage of the same var being read/modified/written to.  So it could be done like this:

LDX		#memIndex
STX		DF0LOW
LDA		DF0DATA
clc
adc #3
STA		DFOPUSH

Granted, for more complicated expressions, it would have to be as you wrote.

 

Always a good question to ask.  The language is called Basic.  All depends on how "basic" you want to make the language for the users. 

 

Great questions and ideas on this thread!  

 

One school of thought is that everything should be under the hood to keep BASIC as BASIC as possible when adding new features.

 

Another is to expand functionality with enhancements from other languages.

 

There are some interesting observations on both perspectives in this 1977 BYTE article that have been applied in large scale in industry and academia and continue to polarize perspectives in programming language design:

[RevEng]

Yes, they want it to act exactly as local memory. Of course they do. They just won't be happy when their game runs out of cycles and rom partway through the design, at which point they'll be posting in the forums asking why they've run out of rom and cycles. Then we'll be telling them that they shouldn't access DPC memory like regular memory.

[+splendidnut]

Well, you are abstracting away cycle counting.  Stop doing that!   Lol.

[+splendidnut]

My advice to @bogax

 

It really sounds to me like you should just jump over the cliff and fully use assembly language.  Especially since you are asking for an IF CARRY construct.

[bogax]

On 3/6/2021 at 2:53 PM, splendidnut said:

My advice to @bogax

 

It really sounds to me like you should just jump over the cliff and fully use assembly language.  Especially since you are asking for an IF CARRY construct.

Yes and no

 

I suppose my ideal would be an assembler with syntax similar to bB where appropriate.

Something that would facilitate the abstractions with out having them get in the way.

Something slightly "higher level" than the usual assembler macros.

 

And speaking of cycle counting, wouldn't it be nice if the language could report byte count or tote up cycles for you

(but that's not something I'd expect to see in bB. on the other hand it might be worth while if the purpose of bB is to ease you into assembly)

Edited March 9, 2021 by bogax

[orange808]

It would be nice if the general "4k limit" on sprite and background data was officially lifted in DPC+.  It can already be bypassed, but it's not particularly user friendly.  There might be a way to change a sprite/background data definition and allow programmers to specify a specific bank.  

[orange808]

For cycle counting, it might convenient to have Stella do it.  Maybe read a memory location to reset the cycle count and read another location to dump the current cycle count to a log.  It would obviously consume some resources in game development, but it would be convenient for programmers.

[RevEng]

bB won't be able to do accurate cycle counts. It doesn't "know" a particular location is zp or otherwise while it's generating assembly code for dasm.

 

Like orange808 suggests, stella would be better. Or dasm, but that's less useful than stella since it's a static analysis.

[+Gemintronic]

11 hours ago, bogax said:

And speaking of cycle counting, wouldn't it be nice if the language could report byte count or tote up cycles for you

(but that's not something I'd expect to see in bB. on the other hand it might be worth while if the purpose of bB is to ease you into assembly)

 

I think the Jaguar BASIC used to use BCX to take BASIC and turn it into C.

http://bcx-basic.sourceforge.net/

 

I could swear some people are working with CDFJ and C.  Maybe something could be jury rigged from that combination..

https://atariage.com/forums/topic/297759-part-1-cdfj-overview/

[Mr SQL]

11 hours ago, bogax said:

I suppose my ideal would be an assembler with syntax similar to bB where appropriate.

Something that would facilitate the abstractions with out having them get in the way.

Something slightly "higher level" than the usual assembler macros.

 

And speaking of cycle counting, wouldn't it be nice if the language could report byte count or tote up cycles for you

(but that's not something I'd expect to see in bB. on the other hand it might be worth while if the purpose of bB is to ease you into assembly)

Bytecount is really useful and can be done through the IDE or DASM:

 

[+Karl G]

On 3/6/2021 at 12:51 PM, Gemintronic said:

Seamless/integrated support for playfield collision in built in collision function

Does this not work for the Multisprite kernel? It should, and I can think of no technical reason that it shouldn't.

 

On 3/6/2021 at 12:51 PM, Gemintronic said:

It seems like off screen sprites still effect flickering on on-screen sprites at times.  I wonder if designating Y location 255 could tell the graphic kernel to stop processing a sprite and optimize itself accordingly

I experienced this one when I did my QT Space Debris demo for the Multisprite kernel. The bottom ship would flicker when it was near the bottom of the screen. I'll look into it.

 

On 3/6/2021 at 12:51 PM, Gemintronic said:

Find the CPU time for variable height ball/missiles.  I'd gladly sacrifice playfield and sprite resolution for this.

This one is highly unlikely, I'm afraid.

 

On 3/6/2021 at 12:51 PM, Gemintronic said:

Slipstream playfield background/foreground color support into the standard kernel.

I'm not sure what you mean by this one, as these options exist for the standard kernel. Did you mean the Multisprite kernel? I believe there's a hacked version of the Multisprite kernel out there that does background color changes, at least.

 

On 3/6/2021 at 12:51 PM, Gemintronic said:

Special title screen mode with asymmetrical playfield and disabled sprites.  Maybe triggered by pfheight=0

That sounds more like a job for a separate kernel, e.g. the Titlescreen kernel, which I'm pretty sure also works with the Multisprite kernel.

 

On 3/6/2021 at 12:51 PM, Gemintronic said:

Fix the color bleeding when sprites move vertically through a multi color background.  I know this is currently only a feature in an unofficial extension.

I'm not familiar with this one. Could you give more details?

[+Gemintronic]

Here is an example of playfield background bleeding.  Same thing happens in the Flappy Bird clone here: https://atariage.com/forums/topic/222161-flappy-my-1st-released-game/

I'm using the modified kernel files from that Flappy Bird post.

 

In my example just move the virtual sprite around to see how it effects the background.

 

playfieldbleed.bin

[+Karl G]

10 hours ago, Gemintronic said:

Here is an example of playfield background bleeding.  Same thing happens in the Flappy Bird clone here: https://atariage.com/forums/topic/222161-flappy-my-1st-released-game/

I'm using the modified kernel files from that Flappy Bird post.

 

In my example just move the virtual sprite around to see how it effects the background.

Huh. Does this just happen with that modified kernel, or does it happen with the base multisprite kernel as well? If the latter, do you have an example of this that includes the basic source so I can try to see what's going on?

[+Gemintronic]

10 hours ago, Karl G said:

Huh. Does this just happen with that modified kernel, or does it happen with the base multisprite kernel as well? If the latter, do you have an example of this that includes the basic source so I can try to see what's going on?

It happens in the modified multi sprite kernel used in Flappy Bird. Thought it would be easier to point to the Flappy Bird source than present awful, work-in-progress code.

 

I guess I was glomming on too many fever dreamed concepts.  In a perfect world I'd wish that multi colored playfields be integrated into the multi sprite kernel.  Also, the glitchy effects when virtual sprites pass vertically through said playfield.  It is not a bug in bB.  Just an unintended effect in the modded multi sprite kernel Flappy Bird uses.

 

 

 

 

playfieldbleedproj.zip

[bogax]

One thing I would really like to see in bB

Is some way to control bB's emission of "#" in macro parameters

RevEng "fixed" it for somebody and now bB sticks "#" all kinda places I don't want them

(although to be fair, they don't seem to do any harm. DASM seems to ignore extraneous "#"
and the fix does fix what it intended to I think)

[bogax]

A version of on goto that uses a jmp indirect and doesn't use the stack