Looking for a post by batari about wriggling sprites

[+Random Terrain]

I think it was between 2007 and 2009, but I could be wrong. I doubt that batari created the thread, but he posted about new features that would possibly be coming in a future update. If I remember correctly, he talked about a few things, but one of the things that stood out to me was sprites that could wiggle or slither left and right like a snake, but he must have used other words because no matter what I use, I can't find his post.

 

If I remember correctly, batari said each row of the sprite would be able to move left and right separately from each other. Does anyone remember seeing his post or know better words to use in the search box?

 

 

Thanks.

Edited September 13, 2010 by Random Terrain

[RevEng]

I think you're talking about this one: http://www.atariage.com/forums/topic/122024-64k-bb-games/page__view__findpost__p__1483436

Edited September 13, 2010 by RevEng

[jbaudrand]

256Ko.. I wish we can access that..

[+Random Terrain]

I think you're talking about this one: http://www.atariage.com/forums/topic/122024-64k-bb-games/page__view__findpost__p__1483436

Thanks! No wonder I couldn't find it. None of the words I tried are in that post.

[+Gemintronic]

Someone should make a feature request to the Grand Batari Master himself. Wriggling or being able to offset sprite graphics would be cool. I could see creating a vertical sheet of enemy graphics and offsetting the values so they appear to be separate objects. In some cases that trick could be used instead of the multi-sprite kernel.

[+batari]

IIRC, I think I had trouble getting the "wiggling sprites" to fit properly with all of the assembly directives in the standard kernel, and doing something like a vine would have required a ton of data - i.e. a table for every possible frame, as opposed to Pitfall which calculated the vine within the kernel. I tried to implement a calculated vine like that but could not make it work. I'll look into it again someday.

 

As for the 256k Superbanking, well, the hardware never got produced. But as for larger games, I plan to add that ability to DPC+ when I get it integrated into bB which should work with Harmony or Melody with an added EEPROM chip.

 

I will need to set some practical limit, however. Although I have seen EEPROMs up to 8 MB in size, Harmony has a 512k EEPROM, of which more than half is unused, so 256k might be a good choice. Note that this 256k can't be used for code, but only data, like sprite or playfield data.

[+Random Terrain]

Thanks for the update.

 

 

Note that this 256k can't be used for code, but only data, like sprite or playfield data.

I bet that would make MausGames pee his pants:

 

http://www.atariage.com/forums/topic/163112-bataribasiccom-planned-updates/page__view__findpost__p__2015621

I have enough trouble fitting a decent amount of sprites in the same bank as the kernel and whatever else gets stuffed in the same bank . . .

 

After we have 256k for sprite and playfield data, his troubles should be over.

[+Gemintronic]

Note that this 256k can't be used for code, but only data, like sprite or playfield data.

 

I hope this goes for plain old data statements too. I could see making game interpreter code that would crunch through data statement "instructions" placed in that wonderful 256k area. Otherwise I could make do with "code playfields" using the playfield pixels as data for the game. Not very elegant though.

Edited September 15, 2010 by theloon

[+batari]

I probably won't support regular data statements directly due to the overhead with reading the EEPROM. Sprites are probably fine as the kernel setup routines will read all of the sprites needed for the screen in one shot.

 

However, I may be able to support sdata. sdata works a little differently as it's set up separately and accessed sequentially, but this setup is much more conducive to the way DPC+ and the EEPROM works.

[+Gemintronic]

However, I may be able to support sdata.

 

sdata would be very cool as VisualbB uses it for music. It seems game assets are the focus of 256k support so it would fit in with that theme.