Karl G

Super cool! This may be the first CRPG ever where water isn't a completely impenetrable barrier.

How about this: Top and bottom enemies use virtual sprites Side enemies use real player0 and player1 sprites Player uses a virtual sprite So far no flicker should happen. I would then use KK's suggestion to flicker the missiles at a constant rate (show two one frame, and the other two the next frame), and the flicker shouldn't be that huge of a deal if it is only the missiles.

That's the thing about game development: The bugs tend to be much more entertaining than with any other sort of development (e.g. pacemaker firmware development).

So, not that anyone has asked, but in case anyone was wondering, the Linux binary version of A7800 works fine on the Steam Deck without any issues. Just don't try to install it to /usr/local because of the read-only file system, but it runs fine from a home directory. I made an executable script in the a7800-linux directory to launch the emulator, and then added that script to Steam so I could launch it in game mode as well. E.g.; #!/bin/bash ./a7800 a7800 -now -cart Download.a78 Mind you, a Linux-compatible frontend and, some user configuration to change the console controls to map to controller buttons instead of keyboard keys would make the experience better, but games load and play just fine on the Steam Deck from what I have seen so far.

I think I owe you a beer or something. I've been grumpy about the unreliability of this reference as well. Thanks for making it available!

It's lazy detection alorithms that end up disproportionately affecting Indie devs. I wouldn't hesitate to let it through.

Of all of the "impossible on the 2600" ports that Champ Games has done, this is still the one that I find the most impressive.

The last update from him in this thread said the plan is to have all games built by the end of this month, and then to start shipping them out in chronological order. So, assuming that goes according to plan, those of us still waiting will presumably see our orders sometime in July.

I haven't gotten any of the email updates in a long time, even though my email hasn't changed. When was the last one? Maybe my spam filter has started eating them for some reason.

Wow! This is a pretty major update. I am curious about the details of this. What kind of cases would not work before that should work now? I know people have been warned against using defs in bB. Do you think these improvements can be ported back to bB?

As a dev, I wouldn't want to make a game that would only be playable to a small subset of people who have the console. That being said though, there are adapters for both DNES and Genesis controllers to use the full range of buttons, and there are 7800 games that have made use of them without requiring those controllers to play the game (e g. Attack of the Petscii Robots comes with the SNES adapter). These could be used for 2600 homebrew titles as well,if desired.

The second button on a 7800 controller can't be made to work with the 2600, but two buttons on a Genesis controller can be made to work. I personally wouldn't recommend a homebrew that uses a second button without a reasonable workaround for users using a standard controller. Plugging in a second joystick just for one button doesn't seem reasonable to me.

Sounds fun and challenging. I'm looking forward to trying it out. 🙂

Ahh, I see. I'm guessing that inline ASM won't work either, then? Another thing that comes to mind is the ability to customize the score graphics.

I would think that being able to have the functionality of the standard lives/statusbar minikernel would likely be important for many projects. There are a number of others that see a lot of use as well, though, Offhand I can think of playerscores, the mitmap minikernel, and the text minikernel, etc. Also, would there be any special consideration for jumping into and out of other kernels compared to doing so from one of the existing bB kernels? The big one that comes to mind here is the Titlescreen Kernel.