+Random Terrain Posted September 13, 2010 Share Posted September 13, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 13, 2010 Share Posted September 13, 2010 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
jbaudrand Posted September 13, 2010 Share Posted September 13, 2010 256Ko.. I wish we can access that.. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 13, 2010 Author Share Posted September 13, 2010 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. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted September 14, 2010 Share Posted September 14, 2010 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. Quote Link to comment Share on other sites More sharing options...
+batari Posted September 14, 2010 Share Posted September 14, 2010 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 14, 2010 Author Share Posted September 14, 2010 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. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted September 15, 2010 Share Posted September 15, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+batari Posted September 15, 2010 Share Posted September 15, 2010 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. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted September 16, 2010 Share Posted September 16, 2010 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.