Jump to content

nanochess

+AtariAge Subscriber
  • Posts

    7,027
  • Joined

  • Last visited

  • Days Won

    21

Posts posted by nanochess

  1. On 4/17/2024 at 6:16 PM, Jess Ragan said:

    On a related note, can you check for tiles near or colliding with a sprite? I presume VPEEK would be the way to go for this.

    Yes, the most common detection is in one direction, for example, for bullets.

     

    	x = (sprite_x + 7) / 8	' Getting the center of the sprite
    	y = (sprite_y + 7) / 8
    	c = VPEEK($1800 + y * 32 + x)	' Read character.

     

  2. On 4/15/2024 at 1:23 PM, big_guitar said:

    A note on the Apr 2 build, the d-pad north-related direction actions will also fire the #1 keypad on the 2nd (opposite) controller

    and south-related actions will fire #2 keypad on the 2nd controller, in addition to handling the related stick directions for the 1st controller. 

    I think that's what you meant to assign to L3/R3 (#1/#2), but somehow the d-pad actions are performing double duty and hitting the 2nd controller in the process.

    Using the swap function (select button) does as one might assume, north/south actions perform #1/#2 on first controller while also directions on 2nd controller.

    The analog sticks don't have the issue.  No issues with d-pad east/west actions (exact right/left), only d-pad north or south related actions (6 of the 8 directions available).

    Good to have the triggers though as */#, frequently used L2 to start the game over.

    I've gone again over this. Remapped the right analog stick as keypad numbers. This time I think I got right L3 and R3 as 0 and 5.

     

    coolcv_retroarch_mac_pi.zip

    • Thanks 1
  3. 6 hours ago, OriginalJohn said:

    In the cv basic code, is there any way to code something that resembles a timer, like counting frame iterations?   Also, in another thread if I'm not mistaken, someone made mention of collision detection which is native to the bios.   Is there a better way than using the players x,y coordinates vs sprite x,y coordinates?    Last one, if one were to program something like a donkey kong clone, what would you think would be the best way to give points when the player jumps over the sprite??

     

    Aside from the questions, I've been having a whole lot of fun experimenting with CVBasic and am working steadily towards a making a game :)   Thanks for this!

     

    The FRAME variable is a 16-bit variable that is updated each time a video frame happens.

     

    There is no VDP collision support because it is barely useful as it only detects sprite vs sprite collision but cannot distinguish sprites. The better way is doing a comparison of player coordinates against enemy coordinates.

     

    A Donkey Kong clone? Maybe you have seen this (soon to be published) but basically it would be enough to determine the current platform of both the player and the sprite, and if the player is jumping, and the sprite is in the same X-coordinate, it has jumped successfully over it and it can score.

     

  4. Wow! It looks pretty cool.

     

    You already coded the game like separated state machines, so that's excellent for game pace.

     

    The MalletSwing label should be located just above the TimeForTimer label. That's the cause the Byrons don't animate when the mallet is swing. Or alternatively, the GOTO MalletSwing statement should jump instead to TimeForTimer

     

     

    • Like 1
  5. 15 hours ago, Jess Ragan said:

    We've reached a slight impasse, it seems. CONT1 can't be used to read diagonals, at least not by saying things like IF CONT1.LEFT AND CONT1.UP... for up and left. I can read the individual directions by addressing CONT1 directly, but this presents its own problems... pressing fire in conjunction with one of the directions adds 64 to the total, and could complicate matters slightly. I'll have to brainstorm and see what I can do to work around this.

    The CONT1.UP is only meant to return a non-zero value if the joystick direction is upwards.

     

    However, this is meant to allow the generation of the smallest possible code, as CVBasic only applies an AND instruction to the controller port value, also the AND logical operator is bitwise.

     

    So if you need to test for two directions, you need to do this: IF CONT1.UP <> 0 AND CONT1.LEFT <> 0 THEN ' Upper-left

     

    I've made an example.

    TEST12.BAS

  6. Wow! It looks pretty cool :)

     

    I could suggest a DATA table having the #hole_offsets for each of the 9 holes, starting from zero. And a DIM array state to hold the state of each of the 9 holes.

     

    I could further suggest a draw_hole procedure receiving a variable c, containing the number of hole to draw, and it would choose how to draw the hole based on the state array.

     

    Then your offset would be #c = #hole_offsets(c), you would have a ON array_state(c) GOTO draw_1,draw_2 and you could do PRINT AT #c adjusting by offset.

     

    I couldn't resist to put some screenshots taken with CoolCV.

     

    image032.png.43fc2f4f791125f7c66d5ad4f41f715e.png  image033.png.b2e4c1f0d21a07ad5cf315f2aade851d.png

    • Like 1
  7. 9 hours ago, aotta said:

    Thank you @nanochess, now it's clear to me that vpoking at $2xxx addresses change the whole character color, not the color of character at screen "+X" position! So, i suppose that for having a single word hilighted within a text, i had to define a second char set and use it when needed, right? maybe i'll have to NOT the charset in different position as you ORred the char for bolding font in your example.

     

    About SC-3000 joystick, you're right again: i made a rough patch adding this code before using "count1":

      c=cont1
      while c=0
    	wait 
    	asm di
    	asm ld a,$92
    	asm out ($df),a 
    	asm ld a,7
    	asm out ($de),a
    	asm in a,($dc)
    	asm ld ($a000),a
    	asm in a,($dd)
    	asm ld ($a001),a 
    	asm ld a,$92
    	asm out ($df),a 
    	c=cont1  
    	print at 32*23+20,c 
     WEND

    Strangely, it works with keys "1,Q,A,Z,"Jap" and "," (the Row 0 in keyboard matrix) even i set 7 (the joystick row) in $de command as suggested in SC-3000 manual. But for sure i missed something, i'll continue testing.

    Thank you again for your work and your support!

    I just read the available hardware information on Sega SC-3000.

     

    You were almost right.

     

    Remove your ASM code, and at the start of your program use this:

     

    	ASM LD A,$92
    	ASM OUT ($DF),A
    	ASM LD A,$07
    	ASM OUT ($DE),A

     

    This is because in the 8255 each time you set the mode (port $DF) all latches are reset, so you always end with row 0. After setting mode, I only set the line register (port $DE), and everything should work just right.

     

    Please test and if it works, I'll add this code snippet to future cvbasic_prologue.asm files for SG-1000 mode.

     

     

  8. 8 hours ago, aotta said:

    I know i'd learn how to use the VRAM tables, but it's first time i'm programming a Sega console (thanks to CVBasic) and i'm lost in trying to highligth (change color reversing it) a text line in mode 0...

    Is it possible to have a "PRINT AT nn COLOR" like in Intybasic, or something similar? I'm getting crazy VPOKing around $2000 with no success 😅

     

    And, just as note, CONT commands don't work on SEGA SC-3000 (may be because he use keyboard key to duplicate joystick command, so use some different coding?) 

    To reverse the whole alphabet (uppercase A-Z) you would use something like:

    FOR #c = $2000 + $41 * 8 TO $2007 + $5A * 8
        VPOKE #c, $0f
    NEXT #c

     

    This is for rows 0-7, for rows 8-15 change $2000 and $2007 to $2800 and $2807, and for rows 16/23 change $2000 and $2007 to $3000 and $3007 respectively.

     

    Notice the $41 is the ASCII code for letter A, and $5a is the ASCII code for letter Z.

     

    For SC-3000 this Sega computer has a port to select the joysticks because it has a keyboard, I'll try to put a initialization code at the start once I remember how to select the joystick.

     

  9. Technically the TMS9928 Video Processor has sprites with different priority. However, this isn't very useful in games with many sprites at the same time.

     

    In the most recent CVBasic compiler, the sprite routine does flickering so all sprites are visible (although alternating video frames). This means that you cannot depend on a sprite covering another, so for multicolor sprites you need to separate the pixels with different colors so no pixel overlays another.

     

    A trick I used in Zombie Near where the player has a suit color and a face color, is having the face sprite with the face defined in the bottom part of the sprite, this way the face doesn't overlay the body, and doesn't count against the limit of 4 sprites in the same line.

  10. I just noticed that cvbasic_prologue.asm could be optimized to save 140 bytes (and a few more in SG1000), and also accelerated LDIRVM (so mode setup and graphic loading will look faster now, Pletter stays the same).

     

    Finally, in cvbasic_epilogue.asm the LFSR wasn't being advanced in each video frame like in IntyBASIC, so I made it to get programmers more randomness.

     

    Updated as v0.4.4, I was lazy so I didn't recompile the binaries, CVBasic still says v0.4.3

     

    • Like 2
  11. 3 minutes ago, Jess Ragan said:

    (shrugs) Sure, here you go. Do note that I'm going to be stingier with my code when it starts resembling a game, though.

     

    So, as a hypothetical. Can I define graphics in a title screen (preferably written as an external program), then re-define them for the content of a game later? A title screen could be more elaborate if I could dedicate all of the ColecoVision's VRAM to it.

    antiqueovision.bas 8.6 kB · 0 downloads bellafonte.bas 12.78 kB · 0 downloads

    Yes, you can do it.

     

    When you need to reset the graphics context you only need to do MODE 0

     

  12. 2 hours ago, aotta said:

    I'm doing my first (very basic) tests with CVbasic for Sega SG-1000, it works fine with emulator but i found an issue when using the rom code on a real hardware: the "wait" command (i think translated with HALT cpu code) hangs the console and freeze.

    I don't know if is it a bug or i missed something....   

    I think I've a bug, I missed a IM 1 instruction at the START: label in cvbasic_prologue.asm.

     

    Please test this: (just replace the file)

     

    cvbasic_prologue.asm

  13. 41 minutes ago, slydc said:

    A new update of CVbasic ? You're the man Oscar! ;) And the animation of Jess, really great! ;)

     

    Well i have done a small slideshow of 5 pictures and this is the second version as the first one there was a different color screen in between the pictures but now that's corrected.

    It's not much but it's a start, hope some of you will like it. :)

     

     

    slideshow02.rom 16.31 kB · 1 download

    Cool! 8)

     

  14. 1 hour ago, Jess Ragan said:

    TMScolor is a real time saver, I'll tell you h'what.

     

    So! I just made a thing. It's not a game, but there's animation, so that's a step in the right direction. The ROM should run in anything that can play ColecoVision games. (Also, phew. Even with TMScolor, this took some time.)

    antiqueovision.rom 3.16 kB · 1 download

    Awesome animation!

     

    👏👏👏

  15. 1 hour ago, Jess Ragan said:

    Hot damn! Super Game Module support, too? What's that going to give developers? 128K of RAM and the extra sound channels of the MSX?

    24K of RAM to get you also ADAM compatibility and SOUND 5-9 gets you the SGM sound channels.

     

    I forgot to initialize the SGM, so in the meanwhile, you should start your SGM programs with:

     

    SOUND 5,,0
    SOUND 6,,0
    SOUND 7,,0
    SOUND 9,,$B8

     

    Or use this updated cvbasic_epilogue.asm

     

     

    cvbasic_epilogue.asm

    • Like 1
×
×
  • Create New...