Gemintronic

Sounds like Stephena is getting hounded by people who want free changes and are demanding about it. People don't realize this is a career and a passion. If they don't understand the passion part at least the money part is something tangible they can appreciate. As a 2600 developer I've done commissions, self published titles, collaborated and worked for free. Sometimes half a year for a handful of billable hours (compared to normal software dev). So, yeah. I feel the pain too If money was the only factor nobody would do this.

I wonder if someone could ask Stephena the billable time it would take to make a "Community Build" with requested features. Then Kickstart the funding for its development. Everyone wins. Hardware is already built and in production. UPDATE: To be clear Stephena just does the billable work - not running the Kickstarter

No surprises so far. Replaced my 64 and 32 bit copies. Below is a recent compile using AtariAge cart 64k ROM SuperChip settings. Thank you Team Stella!

Being a former software tester I can tell you things at this stage need an unnatural combination of dead end user instinct and professional developer experience to distill that feedback. I'm sure R.T. will clue us in when things are ready

Here is a multi sprite version. Quick and dirty - I just commented major changes. smoothcollisionms.bas

Pretty sure that was my contribution to the book: misreading instructions!

I must have been thinking of the RetroN x86 (Hyperkin). Sorry if my mention of free software put you on the defensive. Just having a discourse on the various possibilities.

Doubled down and bought the digital version as well as the physical. Thank you for providing listings for the examples. My PDF readers don't always copy-and-paste code properly

Whatever happened to the whispers/whimpers of a PC DOS emulation station? Seems they could use the same tactic of using free versions of emulation and OS (i.e. Bochs and FreeDOS).

Nah, this ain't work putting on your plate. That Atari BASIC conversion sounds amazing! I've tried to port QuickBASIC code to bB and failed several times. Perhaps someday I'll ask for tips converting between BASIC dialects.

@Random Terrain: Short answer is I don't know. I can see a slight slowdown when wall sliding. Something in my brain or my bB setup is making this slowdown less pronounced for me. The ball is still using simple move into and then warp out of playfield collision - at least some of the time. That could explain the slow down. I'm all for someone improving the ball movement/collision code and still using the "player0 at last ball collision-less coordinate" technique. @Lewis2907: The basic premise works for multi-sprite. The nasty change is missiles and the ball are only one pixel high. This might mean you have to use, say, a missile for the top and the ball as the bottom collision detector. The amount of ROM or extra memory shouldn't effect the way this works. If it does please tell me. By the way this is my answer to your code request with that multi sprite collision demo I showed you in another topic.

This is a smooth collision demo using the ball. This has advantages and disadvantages compared to other techniques. Just thought I'd offer up another option. UPDATE: R.T. found there's still some drag when wall sliding. If anyone wants to take a stab at improving this I'm all ears! A problem: The 2600 registers collisions where two graphical objects draw over eachother. This can lead to a flickering effect when the sprite is repeatedly placed and displaced from the collision point. As well simply reverting to the last known free x/y coordinates can leave the player feeling stuck unless they manually reverse direction and continue. A solution: Use the ball as a collision detector and mask the rebound effect with the player sprite. Alternate which directions are strictly checked for collisions every other frame. This allows for smooth wall sliding. Example controls: FIRE to show ball over sprite to see the ball hides the rebound effect. LEFT/RIGHT/UP/DOWN to move player/ball combo. Secondary points of interest: Use of binary digits in counter to alternate frames. Use of constants that make colors human readable and easily swappable for PAL values. Clearing of 8 boolean flags by setting the containing variable to 0. Using boolean flags so each collision type need only call collision() routine once per main loop. Setting ballx/bally to the same value on the same line for leaner result come compilation time. smoothcollision.bin smoothcollision.bas Multi-Sprite version here: http://atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=587763

Big place and you're not being specific. It's a specific question though. By the time you get out of work someone else in the world may post a Coleco game for sale.

Without seeing the links and the sellers.. But, in general that is what eBay flippers do. They speculate and buy early then wait until something is out of stock. The NES scene asks for pictures of the boards before sale. But, does that work for repros of new games? All the boards are usually from a very few sources.

Is using the playfield as an extra color for cards part of those extra "graphic touches"?

It's always worth asking. That being said, my strategy would be to consider moving to 7800bas and/or checking out how other people using DPC+ made their title screens. Alas, all I could find for DPC+ examples with large title screen graphics is this: http://atariage.com/forums/topic/233403-mappy-tia-music-demo-enjoy/

I think there's also some memory initialization problems with the Flashback and batari BASIC games. I vaguely remember Mr SQL bringing it up. I should try to look up the post with the fix. Maybe we can combine fixes

Sounds like the general opinion is that this project is not a "blank sheet". I think the original poster should take that feedback to heart. As I'm trying to learn IntyBASIC I realize that a common library of user functions and game templates may be useful. Maybe you should start from a blank slate.. again?

Yeah, sorry for the more bad grammar. I was destroyed yesterday staying up testing a new 2600 game for a contract. Reading through the tutorial gets me excited as I realize how much more resources the Inty has comparatively

http://www.lulu.com/shop/oscar-toledo-gutierrez/programming-games-for-intellivision/paperback/product-23728176.html Unfortunately, sometimes I must detach from the keyboard. Nothing beats having some reading for when that happens

I only got into batari BASIC after VisualbB came out (late 2007/early 2008). Grew up with robust IDEs and it's been just about a requirement ever since. batari BASIC lets you focus on game design rather than agonizing over the graphical kernel. As noted inline assembly and custom add-on kernels can be integrated as needed. Fortunately, many canned kernels come standard in bB allowing multiple virtual sprites, multicolored sprites and colorful, resizable playfields. RevEngs title screen kernel makes high resolution intro screens a snap. batari BASIC can work with AtariAge boards up to 64k ROM with SuperChip RAM. batari BASIC can support a format up to 256k ROM with SuperChip RAM. This is all without serious hardware assist.. I'd look into DPC+ for further enhancements Techniques to utilize genesis gamepads, I2C flash storage and voice are available. UPDATE: Please note that some people LOVE to "agonize" over the graphical kernel and enjoy the game of chess that is cycle counting. That is a totally valid and awesome viewpoint. It makes Boulderdash, Draconian and demo scene intros possible

Those dingle dangles that receive bluetooth and output to a headphone jack are pretty cheap nowadays.

It really depends on your background. I grew up with BASIC and "4GL" languages so C would work better for me. The idea being use a high level language for the general framework and insert inline assembly for speed when absolutely needed.

Is it? You end up with a Socks the Cat situation where being a business they can't answer that question well enough to non business partners - especially this early in the process. Then people harp on that as signs of wrongdoing and it goes on and on..

I guess the first test would be to play back a .wav file to your landline phone and attach that to a StarPath