Jump to content
  • entries
    469
  • comments
    324
  • views
    399,412

Reached 50th sprite + split codes + limited library

Serguei2

202 views

I just reached 50th sprite for my brawler game.

blogentry-1196-0-39881100-1549930714_thumb.png

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.




4 Comments


Recommended Comments

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.

Share this comment


Link to comment

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

 

For complexe gameplay, I use the keypad instead.

Share this comment


Link to comment

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/forums/topic/286613-new-years-beach-party-garbage-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.

  • Like 1

Share this comment


Link to comment

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/forums/topic/286613-new-years-beach-party-garbage-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.

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...