nanochess

Let me fix your title for you "Looking for someone to hombrew record me a Donkey Kong Junior Cassette game. I have the ROM data file"

I don't have had the time to look at it.

We have received the equivalent of the entries shown in the forum. Two didn't made it, but I think Faded Quest by @Kiwi was a in-progress title for his more recent entry, and @carlsson wasn't able to continue working on his Crayfish Party game.

We have 7 entries in contest!!!

We are waiting for official information from @intvsteve

And the contest is closed now!!! intvsteve will proceed to validate entries and post to judges in order to evaluate each one. We expect to have the results in one month from now! Thanks everyone!

I'll ask about this because other person is the one receiving all the entries.

That's right

This is because my ahead thinking: FLASH ERASE erases eight rows, what if you want to write fast and write each row in sequence until filling the eight rows? Better to leave the choice for the tech-savvy programmer.

DZ-Jay is right with the structure of the code. Furthermore I would do the variable saving code like this: DIM #row(96) FLASH INIT ' ... other code ... write_row: PROCEDURE #row(0)=levelnumber #row(1)=lemonnumber #row(2)=health FLASH ERASE FLASH.FIRST FLASH WRITE FLASH.FIRST,VARPTR #row(0) END read_row: PROCEDURE FLASH READ FLASH.FIRST,VARPTR #row(0) levelnumber = #row(0) lemonnumber = #row(1) health = #row(2) END

Glad you could solve it. I typically tend to have more time the Sunday, but these weekends I'm passing more time with my daughter so I had time until today to read this thread!!!

Your comment is non-sense, please stop. Every year I choose a game, typically my own, and release it for free just to return something to the community. You appear to think that everyone is tech-savvy enough to have an emulator or have a Flash cartridge, but in fact most people is happy of having a cartridge to play directly in their console. Following your logic, I shouldn't have even ported the game, as it is available the same in Spectrum, and everyone should run to download a Spectrum emulator and play the game. I've a thick skin, people like you have made programers depressed, and they simply quit the community without saying a word. A piece of advice: cease to do that, you hurt the community. In other news, I don't have received any response from the original programmers, so I don't foresee a cartridge release.

Most of the games listed in this thread have some type of sound code.

I've an MSX2 and the colors should look almost the same as MSX, so the purple color isn't right. I'll put up a picture once I load it on my Flash cartridge.

Although I ported it, I would need to ask for permission to the original authors The Mojon Twins before saying anything.

It's right. You can jump out of it, and in thinner floors it makes you to drop out of screen.

Hi everyone! Five years ago I saw this game made for Spectrum by The Mojon Twins, and I was so impressed that I asked for permission to port it. Well, life got in between, and finally Yesterday I started porting it, and here is the fully functional game freely available (as the original was also). Not only for Colecovision, but also for MSX. Enjoy it! zombie_calavera_msx_colecovision.zip

I see. You can optimize your code this way (notice the nesting): IF EXPR0 THEN if expr1 then if expr5 then statement01:statement02 else statement03 if expr2 then if expr6 then statement04:statement05 else statement06 if expr3 then if expr7 then statement07:statement08 else statement09 if expr4 then if expr8 then statement10:statement11 else statement12 END IF I understand when you say more variations, it means you add a different speed like this (and replicate code): IF speed = 0 THEN enemy_x = enemy_x + 1 enemy_y = enemy_y + 1 ELSEIF speed = 1 THEN enemy_x = enemy_x + 2 enemy_y = enemy_y + 2 END IF This can be optimized this way: enemy_x = enemy_x + speed_table(speed) enemy_y = enemy_y + speed_table(speed) ' In another part for data speed_table: DATA 1,2

You don't need to use ON FRAME to keep track of which invader to move. The basic pseudocode for this game looks like this: game_loop: GOSUB update_sprites WAIT GOSUB move_invader GOSUB move_invader_bullet GOSUB move_player_bullet GOSUB move_player GOTO game_loop Now for the move_invader procedure it is a global variable next_invader containing the number of the next invader to move, and you need to keep an array for all the invaders telling if the invaders is alive or dead. For example: c = 0 DO next_invader = next_invader + 1 c = c + 1 LOOP WHILE invader_alive(next_invader) = 0 AND c < 36 It increases the next_invader variable until an alive invader is found, or stops if the invaders array is empty (all killed then c = 36) Now because all invaders are aligned in a rectangle, you can get the x, y coordinate of the invader based on the top left of the rectangle. x = rectangle_x + next_invader % 6 * 2 ' Suppose the invaders are spaced by 2 cards y = rectangle_y + next_invader / 6 * 1 ' Suppose the invaders are one for each row. The rectangle_x and rectangle_y position is moved when all invaders have been displaced in the same direction. The direction changes when one invaders touches the side of the screen, but the change shouldn't be done until all invaders are moved (otherwise the invaders array would disalign). Use a notebook to illustrate the conditions that are required by the invaders to move, and keep track of variables. It will make it easier to implement.

My approach for fractional positioning in IntyBASIC is a variant of this. Supposing you want to preserve values from 0.0 to 9.9 on an integer variable. How you do this? Using a multiplication by 10. So for example: a = 5 * 10 + 4 ' 5 * 10 + 4 = 5.4 b = 2 * 10 + 3 ' 2 * 10 + 3 = 2.3 c = a + b ' 54 + 23 = 77 PRINT <>c/10,".",c%10 ' Separate digit and fraction And for the pixel positioning we use only the digit part (the / 10 result value). BUT WE HAVE A PROBLEM THERE!!! The CP1610 processor is not so good at processing multiplications and division. So we replace 10 by 256, because multiplication and division by 256 is done with SWAP/AND instructions (only two instructions). This means also that we need a 16-bit variable to keep the position, this way using #x and #y. Now to set a ball in the center of the screen. #x = 80 * 256 #y = 48 * 256 SPRITE 0, $0308 + #x / 256, $0108 + #y / 256, $002f * 8 + 7 ' Draw a 'O' letter in white. To get a movement on the screen we can add further two variables: #sx = 0 #sy = 256 game_loop: WAIT SPRITE 0, $0308 + #x / 256, $0108 + #y / 256, $002f * 8 + 7 ' Draw a 'O' letter in white. IF #y >= 88 * 256 THEN ' Touches floor IF #sy > 0 THEN ' Going down #sy = -(#sy / 2) ' Reboots with half acceleration ELSE #sy = 0 END IF END IF #x = #x + #sx #y = #y + #sy IF #sy > 0 THEN #sy = #sy + 32 ' Gravity acceleration ELSE #sy = #sy + 16 ' Reduce ascend END IF GOTO game_loop And then it fails because a rounding error but I'm too lazy to correct it for tonight

The last line of your working CFG file said $559a - $64fb = $f000 this means there are $0f62 words inside the $f000 segment, so you have only 158 words free there. Adding almost anything would make your program to crash. But your first segment $5000 only uses $059a words, and you don't use the $6000 segment. So you can move your ASM ORG $A000 line further ahead on your code, so you see the $5000 filled completely and automatically starts using the $6000 segment.

There are a few principles to optimize IntyBASIC programs: * If a routine is repeated several times in your program, it qualifies to become a subroutine, just check for the common parameter. * If a semi-long expression is repeated several times in your program, consider replacing it with a subroutine or a DEF FN. * If you have several IF doing comparison with constants, replace with ON GOTO or ON GOSUB * if you have tons of PRINT with strings (for example a text adventure), start considering using DATA PACKED and a printing subroutine.

Your sprite for the bullet should be deactivated by using (for example) SPRITE 1,0 (supposing your bullet is the sprite 1) If you are using any idiom where the first parameter contains $0300, it means it is checked for collisions, so when you enable it, it already made collision with its current X/Y position. Now the syntax for checking collision against background should be IF COL1 AND $0100 THEN because the background is the bit 8 of each collisiion. Remember each sprite has its own collision register COL0-COL7 and can check for collision against each other sprite. I've repeated this table before: $0001 = Against sprite 0 $0002 = Against sprite 1 $0004 = Against sprite 2 $0008 = Against sprite 3 $0010 = Against sprite 4 $0020 = Against sprite 5 $0040 = Against sprite 6 $0080 = Against sprite 7 $0100 = Against background (any pixel set to 1) To get combinations you add up these values, so $00fc means collision against sprites 2-7. PEEK and POKE can be used to access the screen, and it is the same speed as using #backtab for read and write, BUT IT IS MORE DIFFICULT TO READ. Personally I always use #backtab(c) = #d to write the screen, and #d = #backtab(c) to read from the screen. PRINT on the other hand preserves the cursor position, so it is slower and very noticeable when updating big parts of the screen. IMHO, I would use pre-shifted space invaders in 2px steps (7 GRAM for each one), and if you give a look to the original space invaders, only one invader is updated for each video frame!!! Ok, I got lenghty!!! 😱