nanochess

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

Just post it again, and state that it replaces your previous submission.

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.

If the mallet was swing you jumped over the joystick movement code, but also over the time counter for the Byrons, so these stopped moving.

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

Capacitors aren't used for joystick pins. I would suggest measuring the joystick pin against the chip pin with a multimeter set to 20 kohms to see if the signal reaches the chip. Also clean with isopropilic alcohol and a brush the connector solder points, over time solder paste can become conductive.

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

Thank you also! I'll include this patch in future versions of CVBasic so it is compatible with Sega SC-3000.

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.

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.

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.

Sorry for late question. Wasn't missing Thunder Soldier from this poll?

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.

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

It feels good to save a Colecovision