21 replies to this topic

[sometimes99er]

Demo download at sometimes.planet-99.net

- - - - -


A few fresh sprite patterns for my next demo ...

Edited by sometimes99er, Mon Jun 11, 2018 10:16 PM.

[sometimes99er]

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, Sun Nov 6, 2016 4:23 AM.

[Opry99er]

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

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

[sometimes99er]

Now, I went straight ahead and did an assembler version.

 

 

Edited by sometimes99er, Sat Nov 19, 2016 4:40 AM.

[retroclouds]

Very cool and I like the background fish

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, Thu Mar 3, 2011 5:46 AM.

[sometimes99er]

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.

[sometimes99er]

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

Edited by sometimes99er, Sat Nov 19, 2016 4:42 AM.

[sometimes99er]

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.

  

[Ksarul]

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, Sat Nov 19, 2016 6:26 AM.

[save2600]

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

 IMG_0029.JPG   29.32KB   3 downloads  IMG_0030.PNG   18.85KB   4 downloads

[Sinphaltimus]

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.

bubbc.bin
bubbles.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.

[OLD CS1]

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

IMG_0029.JPG IMG_0030.PNG

 

Man, I used to clean up at that game.

[sometimes99er]

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

 

  

 

[Ksarul]

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.

[Asmusr]

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.

[OLD CS1]

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.

[Tursi]

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!

[sometimes99er]

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

 

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, Sun Nov 20, 2016 3:54 AM.

[sometimes99er]

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.     

[sometimes99er]

Man, I used to clean up at that game.

Did you get a good score or what is work related ?
 

[sometimes99er]

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.

[sometimes99er]

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.