Gemintronic

Technically a fail. I got to the last boss monster in Athena and could withstand hours of battle. Turns out there were hidden items in various levels that you must pick up or else the final boss was straight up [email protected]

For the 2600 I created a conversion of Drunken Pooper. Basically, your player shoots downward trying to hit an erratically moving toilet below. The toilet moves faster as you successfully hit it. Despite the simplicity it covers most aspects you need for almost any bigger project including collisions, scoring, basic enemy AI, sound effects and background display. This would be a good example if you want to jump into a complete game straightaway. I personally made several experiments that tested each mentioned aspect before trying a single cohesive game.

Sometimes (especially with the multi sprite kernel) you just have to eyeball it. Sprite and virtual sprites can appear skewed from their x/y values. I usually end up making a simple "game" that moves a particular sprite around and use the score for tracking the coordinates. In my latest multi sprite attempt I found x = 20 to be a good wrap around value for medium stretched sprites. x = 140 to be the good wrap point at the opposite end. Sometimes you have to just brute force place a sprite and see if it displays properly. Of course, this is not the best advice and it's explained poorly. But, sometimes dumb, annoyingly manual methods get the job done.

I could be wrong since it's been a LONG time since I checked into MorphOS. But, I think it has a 68k Amiga emulator that runs the software. So, it's like double-clicking on an Atari 2600 ROM when you have Stella installed. You still have to pay for a one time, THAT machine specific activation of MorphOS otherwise it time bombs and slows to a crawl after a certain amount of time.

Don't have any cameras set up in the office. But, I ran both ROMs on an Atari 7800 using a plasma TV over RF. Both work. He'll need more testing input though. Each TV has more or less tolerance for rolling the screen.

@SpiceWare Naw, not being clever. Due to poor research and worse assembly skills I have failed to find a snippet of code that (without an ARM chip or Melody board) reports if the system is running PAL or NTSC. Ideally I could take a plain old 32k ROM board and run PAL/NTSC detection code at startup. Put the results into a memory area that corresponds to a batari BASIC variable and let the canned kernel carry on. Unfortunately, not everyone that offers to publish my games uses Melody boards. That being said I'm only assuming the routines to mentioned are only Harmony/Melody specific. Definitely need to do more research!

Only used BD as my first point of reference for your scheduling methods. Thank you for the explanation!

I barely understand my question here. So, it'll be ill defined and badly worded In Boulderdash my impression was you needed to figure out a system to manage events (like rocks falling) and do as much as you can until CPU time ran out then schedule them for the next frame. Do you do something similar here and does your overall threading strategy/management change going from assembly to C?

I've had people reject PAL60 builds because their older PAL TV just leaves static white noise at the bottom where the PAL60 graphic kernel stops drawing. But, yeah. I wish everyone would just let me make PAL60 games since I haven't found any auto detect code for region differences. 😛

There is a modified multi sprite kernel that supports a multi colored background used in this flappy bird demo: It has its quirks. One of which is that your player sprites can cause the background color to spill over to other rows depending on the y position. So, you have to program around that and it usually involves very chunky vertical movement (to skip lines that would cause the background color to bleed). Also, one background theme per game. You could *probably* get around that by making a multi kernel game using RevEngs multi kernel framework.

I vaguely remember CD ROM drives being expensive at the time. Cheaper game production means nothing if the hardware investment is too risky for the consumer. No. I suspect the weak link was in development libraries and support for third party developers. Same as always. But, that is my hot take. Could very well be off my meds. Again.

Just a heads up on those swanky M1 Mac and/or Windows 10 ARM users: I got it to work after a few tries. As usual no definite steps just a "what worked in the last attempt" explanation. First problem was some versions of Windows 10 ARM don't install .net 3.5. You can force the issue by making it revert to a known working Windows 10 ARM build as documented at Parallels: https://kb.parallels.com/125526 Once you have .net 3.5 installed try copying an earlier version of VisualbB to your batari BASIC folder. I used version 544 downloaded here: https://atariage.com/forums/topic/123849-visual-bb-10-a-new-ide-for-batari-basic/ Launch VisualbB and set the usual settings (disable the web page stuff, set NTSC or PAL, select a mono-spaced font etc..) and then close down VisualbB. Download the latest version of VisualbB and overwrite the files in your batari BASIC folder. Basically, we just wanted the older working VisualbB to correctly integrate its settings into the registry. The newer VbB has problems either related to permissions or the registry branches that get created for compatibility. If you're using Parallels to get Windows 10 ARM working I'd suggest doing all this VERY first thing after creating the virtual machine. I suspect that also goes for bare bones Windows 10 ARM machines as well.

I actually found that 91 instead of 92 when adjusting the height gives a smoother vertical scroll for the starfield. Tried to use HMBL instead of the missiles but that seems to mess with displaying the ball. Can't have everything with a glitch Here's a picture using missile1x + 91 and alternating between missile1height 0 and 255 to effectively dim the stars - making player1 brighter by comparison.

In my experience Win 10 likes to run from certain brands and models of flash drives. SanDisk Cruzer Ultra series working the best for me. Well, they do have NVME based USB drives and those naturally kick butt.

For an upcoming sega genesis game I'm thinking of running some checks that will only work on boards from a trusted vendor I've known for years. Has that been done for 2600 carts?