Jump to content





Reached 50th sprite + split codes + limited library

Posted by Serguei2, in Uncategorized, Programming Colecovision, My brawler game 11 February 2019 · 70 views

I just reached 50th sprite for my brawler game.
 
Attached Image
 
14 more to go and I'll run out of sprites. OUCH!  :o
 
I never thought a brawler game would take so many sprites.
 
--------------------------------------------------------------------------------------------------
 
I checked the 10years, a program included with the compiler. There are three c files.
 
The main program, the cake and the sound.
 
I always work on one file only because it's easy for me to work with but it must have reason to split files.
 
--------------------------------------------------------------------------------------------------
 
In the PROGRAMMING COLECOVISION GAMES manual, page 44, it's written,
 
''This modified version of Marcel's ColecoVision library is optimized to produce smaller games by using
 ColecoVision BIOS functions and no support for : spinner, 3rd fire button, 4th fire button and less sprites.''
 
No wonder why I can't use Fire 3 and 4 in my program.
 
Maybe if I can use unmodified library to use.
 
 
 






That's just the coleco.h library.  FIRE3 and FIRE4 is available for getput.h on page 27.  I personally use both getput.h and coleco.h.

 

Keep in mind, colecovision hand controller don't have fire3 or fire4 button.  That only on the Super Action Controller.

  • Report

Ok. Not all Colecovision owners have a Super Action Controller either.

 

For complexe gameplay, I use the keypad instead.

  • Report

To answer some of your questions.  Two reason I split source code if the source code is taking very long time to compile, I move the offending code to another source code, like enemy behavior for Challenger, so I can focus programming the main source code, which takes a minute. I only compile the enemy behavior code if I need to make a change. Another reason is bankswitching. I have 8 source codes in the folder to build a 128KB game.  Each bank is 16KB. 

And for need to have more sprites. You can redefine the sprite pattern on demand at a cost of cycles.  I experimented having 2 bank of sprites loaded to VRAM.  All I had to do is to bankswitch to another VRAM bank for the sprites. 

For example: http://atariage.com/...arbage-pick-up/

Beach Clean Up switch vram bank to 0x3000 when he picks up an item, then switch bank to 0x3800 when he drop an item.  So it can take up 16 slots instead of 32 slot, so I can add additional sprite graphics.  The sprite graphic other than the player are duplicated.  It's like how NES CHR-ROM worked. In screen_mode_2_text(); There's only 1 color table, which is at 0x2000.  So address 0x2800, and 0x3000 are not used by the VDP.  So you can stash your data or addition graphic there.

  • Report

To answer some of your questions.  Two reason I split source code if the source code is taking very long time to compile, I move the offending code to another source code, like enemy behavior for Challenger, so I can focus programming the main source code, which takes a minute. I only compile the enemy behavior code if I need to make a change. Another reason is bankswitching. I have 8 source codes in the folder to build a 128KB game.  Each bank is 16KB. 

And for need to have more sprites. You can redefine the sprite pattern on demand at a cost of cycles.  I experimented having 2 bank of sprites loaded to VRAM.  All I had to do is to bankswitch to another VRAM bank for the sprites. 

For example: http://atariage.com/...arbage-pick-up/

Beach Clean Up switch vram bank to 0x3000 when he picks up an item, then switch bank to 0x3800 when he drop an item.  So it can take up 16 slots instead of 32 slot, so I can add additional sprite graphics.  The sprite graphic other than the player are duplicated.  It's like how NES CHR-ROM worked. In screen_mode_2_text(); There's only 1 color table, which is at 0x2000.  So address 0x2800, and 0x3000 are not used by the VDP.  So you can stash your data or addition graphic there.

 

Thanks for the tips and for your patience. It's very helpful.

 

The offending and the enemy and the challenger thing is hard to me to understand. But if splitting files makes the compiler faster, I understand that. 

 

Splitting files to make games bigger than 16k is fine too, even if Colecovision can handle games to 32k without bankswitching, I think.

 

Maybe it's time for me to re-read Colecovision programing manual if I missed something.

 

If I need help, I'll drop a line in the forum.

 

After I worked on my game so far, I'm on the right track.

  • Report

February 2019

S M T W T F S
     12
3456789
10111213141516
1718192021 22 23
2425262728  

Recent Entries

Recent Comments

0 user(s) viewing

0 members, 0 guests, 0 anonymous users

Search My Blog

Latest Visitors