Jump to content

Photo

Bug Report Thread


309 replies to this topic

#301 orange808 OFFLINE  

orange808

    Star Raider

  • 54 posts

Posted Sat Sep 15, 2018 3:27 PM

I have a fresh install of bB and Visual Basic on this Win 10 machine (no previous installations to pollute my registry). I followed the instructions. I have the latest versions. I am familar with coding and Windows. The environment variables aren't an alien concept and they are right. Running as admin. So, when I look at the DPC+ examples, they run well enough. But, if I add a set romsize command, they all break. I tried multiple examples. I can change the romsize on Tinkernut all I want. Any suggestions?

#302 orange808 OFFLINE  

orange808

    Star Raider

  • 54 posts

Posted Sat Sep 15, 2018 3:30 PM

Also, will add that this is an Intel x64 machine. Not an AMD or the new ARM x86 Windows emulation. Not an exotic environment.

#303 RevEng OFFLINE  

RevEng

    Bit Player

  • 5,179 posts
  • Location:bottom of the stack

Posted Sat Sep 15, 2018 3:36 PM

bB DPC+ is only 32k. You can't change the romsize.

#304 orange808 OFFLINE  

orange808

    Star Raider

  • 54 posts

Posted Sat Sep 15, 2018 5:38 PM

bB DPC+ is only 32k. You can't change the romsize.

​Fair enough.  I found the documentation to be somewhat ambiguous about this.  It declares that the romsize is automatically set for you, but I didn't understand that sentence was implying that the romsize could not be changed at all.

​How about the multikernel framework with multiple DPC+ 32k parts?

​Edit:  Apologies.  Answered my own question.  That won't work.  The DPC+ kernel alone is too big to fit inside "containers" of 4k.


Edited by orange808, Sat Sep 15, 2018 5:49 PM.


#305 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,966 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Sep 15, 2018 6:52 PM

Be sure to refresh the bB page.



#306 bogax OFFLINE  

bogax

    Dragonstomper

  • 791 posts

Posted Tue Oct 2, 2018 9:41 AM

Not really a bug

 

I am frequently frustrated by having constant macro parameters treated as immediate values.

Not really sure how to deal with that.

How hard would it be to perhaps escape a constant to suppress emission of the "#" ?

(best I could think of)



#307 Karl G ONLINE  

Karl G

    Dragonstomper

  • 795 posts

Posted Mon Dec 3, 2018 1:04 PM

There is a display problem with the rightmost digit of the score that can be exposed with a wide enough score font that I've reproduced on Stella and real hardware.  Here's a simple example with the "husky" font with the score = 100.  The problem goes away if the player objects are positioned one more pixel to the right (HMP0 = #$D0 and HMP1 = #$E0).

 

Screen Shot 2018-12-03 at 2.03.43 PM.png

 

Attached File  husky.bas   139bytes   24 downloads

 

Attached File  score_graphics.asm   68.45KB   25 downloads

 

Attached File  husky.bas.bin   4KB   25 downloads



#308 freshbrood OFFLINE  

freshbrood

    Star Raider

  • 81 posts

Posted Tue Dec 4, 2018 6:36 PM

Is there a way to get rid of the "waterfall effect" when using colored sprites and a colored playfield in the standard kernel?

 

If it were static I wouldn't mind, but it moves and ripples as the player objects move. 



#309 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,894 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Wed Dec 5, 2018 5:25 AM

Request:

This optimization I do that the bB compile passes should. 

It is faster assembly and uses less ROM.

 

Can the compile stage find (between anything more complex than “=“) and put all the same value variables together regardless if they are on one line or four, and output more efficient & ROM saving assembly like this?

 

This:

Player0x=0: r=0 s=0 t=0

 

Compiles to this:

lda #0
sta Player0x
sta r
sta s
sta t

 

———

 

And this same thing:
Player0x=0
r=0
s=0
t=0

 

Compiles to this:
lda #0
sta Player0x
lda #0
sta r
lda #0
sta s
lda #0
sta t

 

 

Another example is this one line compiles more efficiently over one value each line:

DF0FRACINC=255: DF1FRACINC=255: DF2FRACINC=255: DF3FRACINC=255: DF4FRACINC=255



#310 Karl G ONLINE  

Karl G

    Dragonstomper

  • 795 posts

Posted Sun Feb 17, 2019 9:50 AM

The multisprite kernel seems to have a problem with the "noscore" option - the timing seems to be off when the score is disabled.  I confirmed this with a simple program that just does a drawscreen loop as well as the 9 objects example on RT's site.

 

attachicon.gifmulti.bas

 

attachicon.gifmulti.bas.bin

 

 

I have a fix for this issue.  The problem happens because a "rts" is skipped when "noscore" is enabled.  The original code for noscore in the Multisprite kernel is this:

 ifconst noscore
 jmp skipscore
 endif

I've changed it as follows, which fixes the issue:

 ifconst noscore
 pla
 pla
 jmp skipscore
 endif

Here's a patched version of the kernel for those who need the fix in the meantime:

 

Attached File  multisprite_kernel.asm   18.17KB   7 downloads






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users