Jump to content

Recommended Posts

Okay, once the idea settled, this was fast. Trying, as good as I can with XB, to avoid more than 4 sprites horizontally. 7 sprites are distributed vertically, no vertical overlap. Then another 7 sprites, - and so on. Each set of 7 sprites are basically a separate plane or layer. Each plane can have it's own vertical motion and changes in that vertical motion, but it has to be the same for all 7 sprites in a set. Horizontal motion can be individual.

100 CALL CLEAR::CALL SCREEN(5)::CALL MAGNIFY(3)
200 CALL CHAR(36,"071820464C9880808080804040201807E01804020201010101010912220418E")
210 CALL CHAR(40,"00030C102326404040402020100C030000C0300804040202020224440830C")
220 CALL CHAR(44,"0000030C10132620202010100C0300000000C030080804040404280830C")
230 CALL CHAR(48,"00000003040812101010080403000000000000C02010080808081020C")
300 FOR A=0 TO 3::FOR B=0 TO 6::CALL SPRITE(#B+1+A*7,36+A*4,16,B*16+1,RND*240+1,-32/(A+1),SGN(RND-.5)*2)::NEXT B::NEXT A
400 GOTO 400
Edited by sometimes99er

Share this post


Link to post
Share on other sites

Man, that looks fantastic!!! It's so deceptive and slick!

 

Great job buddy! And thanks for providing the code. =)

  • Like 1

Share this post


Link to post
Share on other sites

Very cool and I like the background fish :cool:

 

Is the 4-sprite limit in place when you ran the demo?

 

Considering there are so many sprites on screen, I guess it would make a good candidate for testing a sprite-flicker routine.

Edited by retroclouds
  • Like 1

Share this post


Link to post
Share on other sites

Is the 4-sprite limit in place when you ran the demo?

Yes, with both XB and Assembler versions. Idea and design avoid more than 4 sprites horizontally, so 4-sprite limit or not, it still looks the same.

 

;)

Share this post


Link to post
Share on other sites

This one should reveal what's going on.

 

100 CALL CLEAR::CALL SCREEN(5)::CALL MAGNIFY(3)
200 CALL CHAR(36,"071820464C9880808080804040201807E01804020201010101010912220418E")
210 CALL CHAR(40,"00030C102326404040402020100C030000C0300804040202020224440830C")
220 CALL CHAR(44,"0000030C10132620202010100C0300000000C030080804040404280830C")
230 CALL CHAR(48,"00000003040812101010080403000000000000C02010080808081020C")
300 FOR A=0 TO 3::FOR B=0 TO 6::CALL SPRITE(#B+1+A*7,36+A*4,16,B*16+1,a*64+16,-32/(A+1),0)::NEXT B::NEXT A
400 GOTO 400

 

 

Parameter 5, x-position changed to separate sprite "stacking". Parameter 7, x-velocity, set to zero, so it stays in a "vertical column".

 

icon_smile.gif

Edited by sometimes99er

Share this post


Link to post
Share on other sites

Here's an update to the assembler / cartridge version. Added a few buttons and some music. Fits the FlashROM99 without modification - put the file on the card and it should be good to go. No need for 32K Memory Expansion.




:)

 

  • Like 5

Share this post


Link to post
Share on other sites

I love the fact that all of your programs are designed for console-only use. That lets anyone with a TI try them out. :)

Edited by Ksarul
  • Like 2

Share this post


Link to post
Share on other sites

Here's an update to the assembler / cartridge version. Added a few buttons and some music. Fits the FlashROM99 without modification - put the file on the card and it should be good to go. No need for 32K Memory Expansion.

 

attachicon.gifbubbc.bin

attachicon.gifbubbles.rpk

 

:)

 

 

That's very cool. One of these days I'm going to have to wrap my head around TI music production and advanced sprite handling.

  • Like 1

Share this post


Link to post
Share on other sites

I love the fact that all of your programs are designed for console-only use. That lets anyone with a TI try them out. :)

 

Thanks.

 

I do have ideas for stuff that will definitely need bank-switching and a few that will probably also need the memory expansion. Back then most of the 2.8 million machines sold was the TI-99/4A (not the TI-99/4 or V2.2). And probably more than 9 out of 10 were in play without any memory expansion. So I guess I might be a sucker for making something cheap and low budget (8K ROM), that people could have bought in cartridge format for tenner. Uh, nostalgia ...

 

;)

 

 

Share this post


Link to post
Share on other sites

Note--just because you use bank switching in a game does not mean that you can't build it to work in a console-only mode. You just have to be careful to set up the main loop and your variables in the first bank, using the VDP memory and the scratchpad to keep everything running properly. Lots of old-school cartridges used two banks, but you could use even more using the current, larger cartridge schemes.

  • Like 1

Share this post


Link to post
Share on other sites

Another model that would have worked equally well back then is to limit your code to 8K, which isn't unreasonable, and store all static data (up to 40K) in GROM.

  • Like 1

Share this post


Link to post
Share on other sites

Another model that would have worked equally well back then is to limit your code to 8K, which isn't unreasonable, and store all static data (up to 40K) in GROM.

 

ISTR this is the approach used by Parker Brothers. A good solid way to do it: you can still code your game in fast assembly, be used in the v2.2 consoles (GROM headers,) and not have to bank switch to get to your data.

  • Like 1

Share this post


Link to post
Share on other sites

Note--just because you use bank switching in a game does not mean that you can't build it to work in a console-only mode. You just have to be careful to set up the main loop and your variables in the first bank, using the VDP memory and the scratchpad to keep everything running properly. Lots of old-school cartridges used two banks, but you could use even more using the current, larger cartridge schemes.

Bank switching doesn't affect your variables - the RAM doesn't switch. So you can access your variables from any place in your code and rest assured that whether in scratchpad or VDP, they will be right where you left them! :)

  • Like 1

Share this post


Link to post
Share on other sites

Looks good, but thought this was going to be about the arcade game by Williams. :lol:

 

Yeah. :)

 

I remember looking at crisp pictures and reading about Bubbles in the US magazine Electronic Fun with computers and games. Excellent magazine, and luckily available in Greve Strand, a suburb of Copenhagen.

 

Never saw the real thing, but got to play it in MAME. It's a surprisingly well done down-to-earth simulation for it's time, opposed to many other well known coin-ups like the somewhat similar Robotron 2084.

 

Opposed to Robotron, Bubbles has slippery controls, of course intentionally, but maybe that lets it down a bit.

 

Love the graphics. For long Bubbles has been a candidate for going on my list. This may still happen.

 

;)

 

Edited by sometimes99er
  • Like 1

Share this post


Link to post
Share on other sites

That's very cool. One of these days I'm going to have to wrap my head around TI music production and advanced sprite handling.

 

Thanks. :)

 

Music. There is a handful of players and a few editors. ePSGMod can import MIDI tracks, though I think you have to prepare the MIDI with one note/finger per channel. There's also a MOD converter. ;)

 

Sprites. In 1979 the 9918 (TI-99/4) was actually more than on par with arcade coin-ups of the time. Whoa. :thumbsup: :thumbsup: :thumbsup:

  • Like 1

Share this post


Link to post
Share on other sites

Note--just because you use bank switching in a game does not mean that you can't build it to work in a console-only mode. You just have to be careful to set up the main loop and your variables in the first bank, using the VDP memory and the scratchpad to keep everything running properly. Lots of old-school cartridges used two banks, but you could use even more using the current, larger cartridge schemes.

 

Bank switching doesn't affect your variables - the RAM doesn't switch. So you can access your variables from any place in your code and rest assured that whether in scratchpad or VDP, they will be right where you left them! :)

Yes.

 

It's more the Atarisoft limitation or specs I put on myself or mimic. So it's 8K or 16K ROM. With a future option of going to a max of 32K, as set by the FlashROM99.

 

Making demos and games without the 32K Memory Expansion is of course a challenge (nothing major). I did actually have the standalone 32K back in the day, but target was more the 4K Mini Memory. And then most TI-99/4A consoles went through life and to the trash without any 32K. - So I intentionally target the market of millions - just for fun and nostalgia.

 

;)

  • Like 1

Share this post


Link to post
Share on other sites

Another model that would have worked equally well back then is to limit your code to 8K, which isn't unreasonable, and store all static data (up to 40K) in GROM.

 

Yes. I did use that approach with a picture viewer back in 2008 using 24K GROM. I'll stick with the cheaper ROM bank switching though.

 

ISTR this is the approach used by Parker Brothers. A good solid way to do it: you can still code your game in fast assembly, be used in the v2.2 consoles (GROM headers,) and not have to bank switch to get to your data.

 

Yes. The vast majority of consoles sold were not v2.2, so I'll stick with ROM only. If one would want it, it should be fairly easy to make a short GPL program that launches any ROM-only game / demo.

 

:)

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   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...